3 ms·

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 c

• 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.