1. Running strip on go binaries is a BAD IDEA: <a href="https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47d9b971a635bfff/project/PACKAGERS.md#stripping-binaries" rel="nofollow">https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47...</a><p>Use -ldflags="-s -w" instead<p>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.<p>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<p>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.
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.<p>Even for building, a proper build system (like Bazel) is a better tool than building in Docker containers...
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.
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.<p>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.<p>[1] <a href="https://habitat.sh" rel="nofollow">https://habitat.sh</a>
I've been following this pattern by Kelsey Hightower on his blog <a href="https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07" rel="nofollow">https://medium.com/@kelseyhightower/optimizing-docker-images...</a>. I love because the end result is a small base image.
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.
Related: Anyone have experience with Go and Unikernels? Saw a dead discussion a week ago on unik (<a href="https://github.com/solo-io/unik" rel="nofollow">https://github.com/solo-io/unik</a>)<p>For security purposes, the idea of a unikernel rather than a container has been very interesting. Wanted to use them in a test soon.