7 ms·

Guide to Writing Dockerfiles for Go Web-Apps

102 points by alberteinstein 9y ago

q3k 9y ago
I don't understand what is the advantage of using Docker in production to run Go. It can already emit static binaries, can contain embedded assets and you can cross-compile for all supported systems using xgo... Ship your binaries, drop them anywhere in the filesystem, run them however you wish and you're done. Even for building, a proper build system (like Bazel) is a better tool than building in Docker containers...
- pacala 9y ago
  Maybe you have a JSON/YAML/XML config file that, for whatever reason, is not compiled within the single Go binary.
  - q3k 9y ago
    If you're writing the software, I don't see a reason why it should exist, be shipped alongside the binary and not be modified per-server anyway. And if it is modified per server, it's your CM's responsibility, directly or via modifying startup flags.
- astockwell 9y ago
  Indeed, although I have thoroughly enjoyed xgo[1] (docker-based x-compilation) for building cross-platform binaries with packages like Sqlite folded in. [1] https://github.com/karalabe/xgo https://github.com/karalabe/xgo
- Jemaclus 9y ago
  I don't use it in production, but I do have front-end teams that need to develop against services, so it's nice to be able to have them use Docker to serve those APIs locally. That's probably the biggest productivity win in my team right now, along with just sheer reproducibility.
- tango12 9y ago
  Running in container only environments (Kubernetes) would require it to be packaged in a container.
  - pcnix 9y ago
    This is definitely seems to be the use case the blog was written for, seeing the author's background.
- c2h5oh 9y ago
  If it's pure Go and and amount of assets you want to include is not that big then the benefits are not as obvious as with Python for example, but the second you have anything CGO you're in the same boat. Static linking non-go code is somewhat flaky.
- Steltek 9y ago
  > Ship your binaries, drop them anywhere in the filesystem, run them however you wish and you're done. It's this part right here. Containers provides a uniform deployment model for all apps you need to maintain and service. The original analogy to physical shipping containers is spot on here. It doesn't matter if your Go app is "shipping ready"; what matters is that it stacks neatly and identically with all the other stuff running around on the network.
- tetha 9y ago
  I'm currently running 0 containers in production, but... containers abstract the 'anywhere in filesystem' away. There's no need to worry about conflicting file/directory names, K8 or mesos take care of that with zero effort. K8 and mesos offer both failure management and deployments / updates out of the box. For example, chef, salt and ansible offer ways to manage rolling updates and I do know some monit or runit or systemd to keep a crashing service going, but that's all centered on single nodes. With marathon, you define how many nodes you want, and how many nodes should be available during an update. If you push an update, Marathon does the rest for you. Even more, in a sufficiently sized Mesos / K8 cluster, you can ignore physical nodes over a short timestamp. A physical node dies? As long as there's capacity, your services recover. Technically, while reckless, to decomission a physical host, you can just pull the plug on that box. Your orchestration should recover within minutes. I am critical about containers, especially looking at relational databases, memcaches, rather static elasticsearch instances and such. But if you have many and/or rapidly deploying applications, good container orchestration systems to safe time and effort.
- dguaraglia 9y ago
  There's many reasons, but one of the biggest ones nowadays would be Kubernetes.
throwaway993472 9y ago
I've been using Habitat[1] for shipping all my Go applications. That way I can run the go binaries on whatever kind of infrastructure I need (containers, vms, bare metal). I can mix and match for different environments, or change my mind later without needing to repackage my application or my infrastructure automation. Ultimately at the end of the day I need to work on a team with other operations-minded developers, and shipping them a dockerfile / docker container is kind of a spit in the face, so this has been a good solution for me. [1] https://habitat.sh https://habitat.sh
c2h5oh 9y ago
1. Running strip on go binaries is a BAD IDEA: https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47d9b971a635bfff/project/PACKAGERS.md#stripping-binaries https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47... Use -ldflags="-s -w" instead 2. Production build should NOT be running glide install - you want ALL your dependencies vendored, locked and commited to your repo before you build it. Bonus: you can have your Docker image build by CI pipeline and know it's going to be exactly like the one you've got locally. 3. If you're including external resources in your container (upx in this case) via url it's common sense to verify GPG signature or, when one isn't available, at least file hash 4. If your app doesn't need things like ca-certs you don't need Alpine - you can just use "FROM SCRATCH" to only have the statically linked binary in your container slashing another 50% off the final size of container.
- alberteinstein 9y ago
  Thanks! Will try, test and update regarding points 1,2,3. My use case required ca certs but I'll mention the scratch alternative too.
- readams 9y ago
  On (2) note that checking in vendored code is not necessary for reproducible builds, as you will get the exact revision that's in your lock file for glide or dep. You will, however, massively bloat your git repo.
  - c2h5oh 9y ago
    I'll take bloat over having Github being up as a build dependency.
    - bigdubs 9y ago
      Ditto decreased build speed because of internet downloads.
    - dalore 9y ago
      Stick a cache on your build server. As long as your cache doesn't go down you can cache all the build dependencies. Then github is not a dependency anymore.
srameshc 9y ago
I've been following this pattern by Kelsey Hightower on his blog https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07 https://medium.com/@kelseyhightower/optimizing-docker-images.... I love because the end result is a small base image.
- zokier 9y ago
  I would strongly advice on using multi-stage dockerfiles instead of building binaries on host. Conveniently Docker manual has an example for Go already: https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds https://docs.docker.com/develop/develop-images/multistage-bu...
czbond 9y ago
Related: Anyone have experience with Go and Unikernels? Saw a dead discussion a week ago on unik (https://github.com/solo-io/unik https://github.com/solo-io/unik) For security purposes, the idea of a unikernel rather than a container has been very interesting. Wanted to use them in a test soon.
- jwhitlark 9y ago
  Docker Inc. bought a unikernel startup a while back. Presumably they see that as a possible endpoint.
collyw 9y ago
Question, is Docker actually a reliable way of distributing software? I have toyed with it a couple of times and all I ever got was errors about incompatible client and server versions.
- merb 9y ago
  I found it akward when running docker "standalone". However after I learned about k8s, all the things started to make sense. So my advice is, start using it. If it doesn't click at least try to use it in k8s, if you still can't grasp it you probably do not need it.
jpsim 9y ago
Someone should make a collection of these for all languages. I’d love to see an equivalent for Swift.
sigjuice 9y ago
Why is it a problem to have different versions of Go on the same machine?
- alberteinstein 9y ago
  Having two different versions is not an issue, tools like GVM helps in managing them. Docker helps in handling this easily without any extra tools. But, if something is built with a version, it cannot be easily changed without thorough testing. For e.g. when Kubernetes was built with Go 1.8 instead of 1.7, emptyDir teardown path was broken due to the change in behavior of os.Rename in Go 1.8 [1]. This bug caused other issues like the one with minikube [2] and they had to rebuild with Go 1.7 and update new binaries for already released v0.20.0 [1] https://github.com/kubernetes/kubernetes/issues/43534#issuecomment-288824459 https://github.com/kubernetes/kubernetes/issues/43534#issuec... [2] https://github.com/kubernetes/minikube/issues/1630#issuecomment-310275970 https://github.com/kubernetes/minikube/issues/1630#issuecomm...
tptacek 9y ago
Why not use GOOS/GOARCH to cross-compile, so you don't have to do the compilation step in a virtualized environment? You can build on the host and just copy the resulting binary in like all the rest of your artifacts.

q3k 9y ago

I don't understand what is the advantage of using Docker in production to run Go. It can already emit static binaries, can contain embedded assets and you can cross-compile for all supported systems using xgo... Ship your binaries, drop them anywhere in the filesystem, run them however you wish and you're done. Even for building, a proper build system (like Bazel) is a better tool than building in Docker containers...

pacala 9y ago
Maybe you have a JSON/YAML/XML config file that, for whatever reason, is not compiled within the single Go binary.
- q3k 9y ago
  If you're writing the software, I don't see a reason why it should exist, be shipped alongside the binary and not be modified per-server anyway. And if it is modified per server, it's your CM's responsibility, directly or via modifying startup flags.
astockwell 9y ago
Indeed, although I have thoroughly enjoyed xgo[1] (docker-based x-compilation) for building cross-platform binaries with packages like Sqlite folded in. [1] https://github.com/karalabe/xgo https://github.com/karalabe/xgo
Jemaclus 9y ago
I don't use it in production, but I do have front-end teams that need to develop against services, so it's nice to be able to have them use Docker to serve those APIs locally. That's probably the biggest productivity win in my team right now, along with just sheer reproducibility.
tango12 9y ago
Running in container only environments (Kubernetes) would require it to be packaged in a container.
- pcnix 9y ago
  This is definitely seems to be the use case the blog was written for, seeing the author's background.
c2h5oh 9y ago
If it's pure Go and and amount of assets you want to include is not that big then the benefits are not as obvious as with Python for example, but the second you have anything CGO you're in the same boat. Static linking non-go code is somewhat flaky.
Steltek 9y ago
> Ship your binaries, drop them anywhere in the filesystem, run them however you wish and you're done. It's this part right here. Containers provides a uniform deployment model for all apps you need to maintain and service. The original analogy to physical shipping containers is spot on here. It doesn't matter if your Go app is "shipping ready"; what matters is that it stacks neatly and identically with all the other stuff running around on the network.
tetha 9y ago
I'm currently running 0 containers in production, but... containers abstract the 'anywhere in filesystem' away. There's no need to worry about conflicting file/directory names, K8 or mesos take care of that with zero effort. K8 and mesos offer both failure management and deployments / updates out of the box. For example, chef, salt and ansible offer ways to manage rolling updates and I do know some monit or runit or systemd to keep a crashing service going, but that's all centered on single nodes. With marathon, you define how many nodes you want, and how many nodes should be available during an update. If you push an update, Marathon does the rest for you. Even more, in a sufficiently sized Mesos / K8 cluster, you can ignore physical nodes over a short timestamp. A physical node dies? As long as there's capacity, your services recover. Technically, while reckless, to decomission a physical host, you can just pull the plug on that box. Your orchestration should recover within minutes. I am critical about containers, especially looking at relational databases, memcaches, rather static elasticsearch instances and such. But if you have many and/or rapidly deploying applications, good container orchestration systems to safe time and effort.
dguaraglia 9y ago
There's many reasons, but one of the biggest ones nowadays would be Kubernetes.

throwaway993472 9y ago

I've been using Habitat[1] for shipping all my Go applications. That way I can run the go binaries on whatever kind of infrastructure I need (containers, vms, bare metal). I can mix and match for different environments, or change my mind later without needing to repackage my application or my infrastructure automation. Ultimately at the end of the day I need to work on a team with other operations-minded developers, and shipping them a dockerfile / docker container is kind of a spit in the face, so this has been a good solution for me. [1] https://habitat.sh https://habitat.sh

c2h5oh 9y ago

1. Running strip on go binaries is a BAD IDEA: https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47d9b971a635bfff/project/PACKAGERS.md#stripping-binaries https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47... Use -ldflags="-s -w" instead 2. Production build should NOT be running glide install - you want ALL your dependencies vendored, locked and commited to your repo before you build it. Bonus: you can have your Docker image build by CI pipeline and know it's going to be exactly like the one you've got locally. 3. If you're including external resources in your container (upx in this case) via url it's common sense to verify GPG signature or, when one isn't available, at least file hash 4. If your app doesn't need things like ca-certs you don't need Alpine - you can just use "FROM SCRATCH" to only have the statically linked binary in your container slashing another 50% off the final size of container.

alberteinstein 9y ago
Thanks! Will try, test and update regarding points 1,2,3. My use case required ca certs but I'll mention the scratch alternative too.
readams 9y ago
On (2) note that checking in vendored code is not necessary for reproducible builds, as you will get the exact revision that's in your lock file for glide or dep. You will, however, massively bloat your git repo.
- c2h5oh 9y ago
  I'll take bloat over having Github being up as a build dependency.
  - bigdubs 9y ago
    Ditto decreased build speed because of internet downloads.
  - dalore 9y ago
    Stick a cache on your build server. As long as your cache doesn't go down you can cache all the build dependencies. Then github is not a dependency anymore.

srameshc 9y ago

I've been following this pattern by Kelsey Hightower on his blog https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07 https://medium.com/@kelseyhightower/optimizing-docker-images.... I love because the end result is a small base image.

zokier 9y ago
I would strongly advice on using multi-stage dockerfiles instead of building binaries on host. Conveniently Docker manual has an example for Go already: https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds https://docs.docker.com/develop/develop-images/multistage-bu...

czbond 9y ago

Related: Anyone have experience with Go and Unikernels? Saw a dead discussion a week ago on unik (https://github.com/solo-io/unik https://github.com/solo-io/unik) For security purposes, the idea of a unikernel rather than a container has been very interesting. Wanted to use them in a test soon.

jwhitlark 9y ago
Docker Inc. bought a unikernel startup a while back. Presumably they see that as a possible endpoint.

collyw 9y ago

Question, is Docker actually a reliable way of distributing software? I have toyed with it a couple of times and all I ever got was errors about incompatible client and server versions.

merb 9y ago
I found it akward when running docker "standalone". However after I learned about k8s, all the things started to make sense. So my advice is, start using it. If it doesn't click at least try to use it in k8s, if you still can't grasp it you probably do not need it.

jpsim 9y ago

Someone should make a collection of these for all languages. I’d love to see an equivalent for Swift.

sigjuice 9y ago

Why is it a problem to have different versions of Go on the same machine?

alberteinstein 9y ago
Having two different versions is not an issue, tools like GVM helps in managing them. Docker helps in handling this easily without any extra tools. But, if something is built with a version, it cannot be easily changed without thorough testing. For e.g. when Kubernetes was built with Go 1.8 instead of 1.7, emptyDir teardown path was broken due to the change in behavior of os.Rename in Go 1.8 [1]. This bug caused other issues like the one with minikube [2] and they had to rebuild with Go 1.7 and update new binaries for already released v0.20.0 [1] https://github.com/kubernetes/kubernetes/issues/43534#issuecomment-288824459 https://github.com/kubernetes/kubernetes/issues/43534#issuec... [2] https://github.com/kubernetes/minikube/issues/1630#issuecomment-310275970 https://github.com/kubernetes/minikube/issues/1630#issuecomm...

tptacek 9y ago

Why not use GOOS/GOARCH to cross-compile, so you don't have to do the compilation step in a virtualized environment? You can build on the host and just copy the resulting binary in like all the rest of your artifacts.