5 ms·

Docker has nothing to do with any of that though. There artifact is a single statically linked binary/executable, not a docker container. They can build that b

Docker has nothing to do with any of that though. There artifact is a single statically linked binary/executable, not a docker container. They can build that binary once and pass it along a deployment pipeline i.e dev, test, prod changing config parameters for each environment but the exact same code running. Systemd just like the various container runtimes supports auto restarts + logging. You can have the same alerting tools hang off your logs etc etc. The fact they are not using Docker does not mean they can't have a proper build/deployment pipeline. The fact they are dealing with a single static executable makes building a pipeline and robust deployment far simpler as they have far fewer moving pieces. If the author was deploying python, javascript, ruby apps where you don't get a static executable artifact or fat jar with all dependencies bundled then Docker would make sense.

marcus_holmes 6y ago
I've been struggling with this for years now. Every time I ask the question "why do I need Docker when Go produces static binary executables?" I get some reasonable answers, but nothing along the lines of "you can't do X without Docker". I totally grok the need when your deployable is a few hundred script files for a very specific runtime and a large set of very exact dependencies. But that's not the situation with Go. And now //embed too. Adding all my templates, static files, everything, to the binary. Ship one file. Awesome
- thraxil 6y ago
  Yeah, there isn't really anything that you just can't do at all without Docker. The question is whether it's a net positive or negative on your architecture as a whole. Eg, I deploy some Go apps using docker (basically build the executable and then build a docker image that just contains that executable). Looking at just the single application, it's pure overhead to add Docker vs just deploying the binary executable somewhere and running it. But in the overall context of my setup, since I'm running other apps as well that are written in other languages/frameworks and have different characteristics, it's a huge net positive for me to have a single uniform interface for deploying and running them. Everything gets pushed to the same container registry the same way, is versioned the same way, can handle service discovery the same way (by listening on the docker port), can do canary deploys the same way, etc. I can use docker-compose to bring up a dev environment with multiple services with a single command. I can deploy the container to Cloud Run or ECS or an equivalent if that makes more sense than running servers.
  - marcus_holmes 6y ago
    I've just being doing this process for my product now. I have a bunch of deployment scripts that control the test, build and deploy of the app. I can't run them on a Docker container (the final hurdle was that Docker can't run systemd). So my choice was to either add Docker to my production servers, or drop Docker and use Vagrant instead for localhost VM for dev. Again, I couldn't see what Docker was adding to the mix that was of value - it would be an additional layer of configuration, complexity and failure on the production servers. It wouldn't save anything if the server went down, it would complicate attempts to restart the app if that crashed, and it gives us... what? Again, I get it for Rails or Django builds (and similar) where the environment is complex and dependencies have to be managed carefully and can conflict horribly. But I just don't have that problem. And it's a real incentive to stick to the one language and not introduce any more dependencies ;)

marcus_holmes 6y ago

I've been struggling with this for years now. Every time I ask the question "why do I need Docker when Go produces static binary executables?" I get some reasonable answers, but nothing along the lines of "you can't do X without Docker". I totally grok the need when your deployable is a few hundred script files for a very specific runtime and a large set of very exact dependencies. But that's not the situation with Go. And now //embed too. Adding all my templates, static files, everything, to the binary. Ship one file. Awesome

thraxil 6y ago
Yeah, there isn't really anything that you just can't do at all without Docker. The question is whether it's a net positive or negative on your architecture as a whole. Eg, I deploy some Go apps using docker (basically build the executable and then build a docker image that just contains that executable). Looking at just the single application, it's pure overhead to add Docker vs just deploying the binary executable somewhere and running it. But in the overall context of my setup, since I'm running other apps as well that are written in other languages/frameworks and have different characteristics, it's a huge net positive for me to have a single uniform interface for deploying and running them. Everything gets pushed to the same container registry the same way, is versioned the same way, can handle service discovery the same way (by listening on the docker port), can do canary deploys the same way, etc. I can use docker-compose to bring up a dev environment with multiple services with a single command. I can deploy the container to Cloud Run or ECS or an equivalent if that makes more sense than running servers.
- marcus_holmes 6y ago
  I've just being doing this process for my product now. I have a bunch of deployment scripts that control the test, build and deploy of the app. I can't run them on a Docker container (the final hurdle was that Docker can't run systemd). So my choice was to either add Docker to my production servers, or drop Docker and use Vagrant instead for localhost VM for dev. Again, I couldn't see what Docker was adding to the mix that was of value - it would be an additional layer of configuration, complexity and failure on the production servers. It wouldn't save anything if the server went down, it would complicate attempts to restart the app if that crashed, and it gives us... what? Again, I get it for Rails or Django builds (and similar) where the environment is complex and dependencies have to be managed carefully and can conflict horribly. But I just don't have that problem. And it's a real incentive to stick to the one language and not introduce any more dependencies ;)