<story><title>Building Containers Without Docker</title><url>https://blog.alexellis.io/building-containers-without-docker/</url></story><parent_chain><item><author>darksaints</author><text>You&amp;#x27;ve got a statically compiled, fully contained executable. Why would you need to wrap that in the overhead of a container?</text></item><item><author>ImJasonH</author><text>Shameless plug: if you just need to build a container that runs a Go program, you can&amp;#x27;t do it much simpler than with &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;google&amp;#x2F;ko&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;google&amp;#x2F;ko&lt;/a&gt;&lt;p&gt;`ko publish` does a `go build` and stuffs it in a base image, it even supports multi-arch images with `--platform=all`.</text></item></parent_chain><comment><author>justincormack</author><text>Go binaries are not entirely self contained. Even when fully statically linked (and there are several options to still use libc features) they use the certificates from the filesystem and a fee other files. So if you want full control you should ship these too.</text></comment>
<story><title>Building Containers Without Docker</title><url>https://blog.alexellis.io/building-containers-without-docker/</url></story><parent_chain><item><author>darksaints</author><text>You&amp;#x27;ve got a statically compiled, fully contained executable. Why would you need to wrap that in the overhead of a container?</text></item><item><author>ImJasonH</author><text>Shameless plug: if you just need to build a container that runs a Go program, you can&amp;#x27;t do it much simpler than with &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;google&amp;#x2F;ko&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;google&amp;#x2F;ko&lt;/a&gt;&lt;p&gt;`ko publish` does a `go build` and stuffs it in a base image, it even supports multi-arch images with `--platform=all`.</text></item></parent_chain><comment><author>weitzj</author><text>Because you want to run it on docker or Kubernetes.&lt;p&gt;For example if you were to have a desktop program as a single binary but you could tweak its installation process. You would need some kind of configuration interface on what parameters to tweak like MSI.&lt;p&gt;So Docker or even Kubernetes yaml files are the “installation files”, which otherwise your static Go binary would lack or would be provided as either a README.md or your own custom configuration format, which you have to document.&lt;p&gt;Sure enough the single Go binary is nice and I use this often for some cli tools, but if you integrate your tooling with other people and have to communicate, it makes it easier to agree on a common language (not programming language), but “configuration&amp;#x2F;deployment “ language, so that when you talk about: “this is a port”, everybody in the team can look up what “a port” is.</text></comment>