<p>I understand the importance of using docker to deploy an application with multiple dependencies and complex environment configuration. But for a statistically linked go binary, what value does creating a docker image add? </p>
<p>PS. I am new to Go and Docker.</p>
<hr/>**评论：**<br/><br/>dazzford: <pre><p>We containerize our binaries created with go.</p>
<p>You will most likely not need/want to. </p>
<p>Our reasons for doing it are mostly risk mitigation; we want isolation from any possible side effects from other binaries.</p>
<p>We're currently running about 35 micro services written in go on a DCOS cluster.</p></pre>inconshreveable: <pre><p>You don't need it.</p>
<p>There are a few companies with problem spaces for whom containers make things easier. More often than not, the opposite is true for the rest of us.</p></pre>thriqon: <pre><p>You get all the tooling that is available for containers, for example, it is easy to deploy a containerized application in a Kubernetes cluster.
The Docker container format also allows you to specifiy additional information on how to run your application (exact command line), which ports you offer to the outside world, if you require any storage space...</p>
<p>A statically compiled go application is like a car: It can propel itself, has no dependencies (apart from fuel...), and ops understand how to use it. But a standardized container is what people in logistics are used to.</p></pre>shoelazer: <pre><p>Thanks for the insight! </p></pre>random314: <pre><p>Consistent deployment steps. Especially when you have several containers in several different languages.</p></pre>donatj: <pre><p><a href="https://github.com/drone/drone" rel="nofollow">Drone</a> is distributed via Docker image, and configuration/initial setup is much simpler than it was before.</p></pre>CapoFerro: <pre><p>If you are using docker for other applications, consistency is nice. Also, the docker api is friendlier than ssh for running applications on remote servers. Finally, it makes bundling configuration easier, if you use a file.</p></pre>shoelazer: <pre><p>I see that when you already have the deployment process built around docker, it makes sense to just throw in the go app in a docker image as well. But, if all I need is one or more Go binaries, and there is no automated deployment pipeline to reuse? </p>
<p>While I have been thinking about it more, could the ability to use one of those tiny base images like coreos be an incentive? But I won't need docker for that, or would l?</p></pre>CapoFerro: <pre><p>For coreOS you do need docker, but honestly you don't gain much with coreOS unless you are running a large cluster of machines. The primary advantage it gives you is easy OS upgrades. I personally still use docker for simple go apps cause docker-compose is super simple deployment. For large scale deployment at work, we have Kubernetes style deployments for everything, so docker is necessary.</p></pre>shoelazer: <pre><p>Thanks! I'm going to explore docker ecosystem more. </p></pre>JoeHazzers: <pre><p>Since Go binaries are (by default) statically linked, you usually don't have external dependency issues.</p>
<p>So if you're looking to build a Docker container to make your application "easier" to deploy, I recommend taking a look at <a href="https://github.com/drone/drone/blob/master/Dockerfile" rel="nofollow">what the drone guys do</a>.</p>
<p>All you are likely to need is a set of CA certificates for secure connections and a properly-built binary.</p></pre>forexross: <pre><p>I checked the link, can you explain those build flags a little bit more?
I assume they make sense for someone coming from a C background but to someone like me from Java world that is a whole different story hence the request.</p></pre>togamans: <pre><p>I use docker for distribution and packaging, and instead of shipping binaries, I ship source code. Once we get better at CI, that might change as the build environments should be able to pump out the binaries, and upload them to prod directly.</p></pre>
