4 ms·

"in the end can you really say it’s simpler than what we’ve got for free built in to golang?" In this cherry picked example with a golang binary, sure. At my j

"in the end can you really say it’s simpler than what we’ve got for free built in to golang?" In this cherry picked example with a golang binary, sure. At my job, docker has saved us probably hundreds of man-hours. We don't have to worry about complications like systemd, because I can tell a container exactly how to run. Etcetera. You can copy the golang binary into an alpine container and instead of having to maintain a server, you now have ephemeral containers that can be destroyed, spun up, scaled... There is a difference of keeping things minimal and refusing to use industry tools. There is nothing scary about docker or even kubernetes. But they do take time to learn and understand, and yes, the benefits of containerization outweigh using bespoke server setups. edit: s/systemd init scripts/systemd. We use s6-overlay instead of systemd to manage processes in containers.

enobrev 6y ago
> We don't have to worry about complications like systemd init scripts Setting up a systemd unit file (it's not even a script) doesn't even come close to the complexity of wrapping, maintaining, and potentially orchestrating software within containers. > refusing to use industry tools like systemd?
- Proven 6y ago
  systemd is Linux only, hardly an industry standard
- andrewzah 6y ago
  "Setting up a systemd unit file (it's not even a script) doesn't even come close to the complexity of wrapping, maintaining, and potentially orchestrating software within containers." I find that the complexity of managing containers is overstated. It does have costs, but the benefits of docker and containerization in general outweigh those costs. Kubernetes is significantly more complicated and is not always a good choice depending on the use case. "like systemd?" I find that systemd tries to do far too much for our needs, namely for just managing services in a container. Our images have their services manged by s6-overlay [0], but there are multiple init systems one can use. I do not see the benefit of systemd over i.e. s6 or runit, but that is tangential to this discussion. [0]: https://github.com/just-containers/s6-overlay https://github.com/just-containers/s6-overlay
blabitty 6y ago
>You can copy the golang binary into an alpine container and instead of having to maintain a server Why would you do this when a go binary doesn't need anything but the kernel? Why start with a full OS, even Alpine?
- andrewzah 6y ago
  Alpine is a common example, but you could use scratch and only copy in exactly what you need. Both of these are extremely lightweight. Having a full OS is helpful for troubleshooting issues, for starters. If one of the nodes is having an issue, it's helpful to be able to log in and examine the state of things. One pain point of docker/k8s is figuring out networking, and having a container with dns-utils installed is quite handy.

enobrev 6y ago

> We don't have to worry about complications like systemd init scripts Setting up a systemd unit file (it's not even a script) doesn't even come close to the complexity of wrapping, maintaining, and potentially orchestrating software within containers. > refusing to use industry tools like systemd?

Proven 6y ago
systemd is Linux only, hardly an industry standard
andrewzah 6y ago
"Setting up a systemd unit file (it's not even a script) doesn't even come close to the complexity of wrapping, maintaining, and potentially orchestrating software within containers." I find that the complexity of managing containers is overstated. It does have costs, but the benefits of docker and containerization in general outweigh those costs. Kubernetes is significantly more complicated and is not always a good choice depending on the use case. "like systemd?" I find that systemd tries to do far too much for our needs, namely for just managing services in a container. Our images have their services manged by s6-overlay [0], but there are multiple init systems one can use. I do not see the benefit of systemd over i.e. s6 or runit, but that is tangential to this discussion. [0]: https://github.com/just-containers/s6-overlay https://github.com/just-containers/s6-overlay

blabitty 6y ago

>You can copy the golang binary into an alpine container and instead of having to maintain a server Why would you do this when a go binary doesn't need anything but the kernel? Why start with a full OS, even Alpine?

andrewzah 6y ago
Alpine is a common example, but you could use scratch and only copy in exactly what you need. Both of these are extremely lightweight. Having a full OS is helpful for troubleshooting issues, for starters. If one of the nodes is having an issue, it's helpful to be able to log in and examine the state of things. One pain point of docker/k8s is figuring out networking, and having a container with dns-utils installed is quite handy.