Dockerfile: upgrade to go 1.12.10 and reduce layer churn around packages

[nickvanw]

Description

This PR offers some improvements to the bundled Dockerfile for orchestrator, namely:

• Bumps to go 1.12.10, which includes a security update around HTTP parsing: https://groups.google.com/forum/m/#!topic/golang-announce/cszieYyuL9Q
• Slims down the usage of apk to avoid superflous calls to their registry, as well as the creation of extra layers
• Names build containers to make the process slightly more legible.

I did not create an issue as this is a proactive PR - I am happy to do any needed work, but I opted to move to a PR due to security constrains around the bump of Go versioning.

• contributed code is using same conventions as original code
• code is formatted via gofmt (please avoid goimports)
• code is built via ./build.sh
• code is tested via go test ./go/...

[shlomi-noach]

Slims down the usage of apk to avoid superflous calls to their registry, as well as the creation of extra layers

so, I did that superfluous apk calls on purpose, let me know what you make of it:

• if I need to install a new package (change the Dockerfile), and it's a single RUN apk one liner, then the entire RUN command changes, and Docker needs to rebuild the entire list of packages.
• if I need to install a new package, and I just append a new RUN apk line, Docker uses the cached image, leading to quicker development time.

WDYT?

[nickvanw]

Hey @shlomi-noach!

I figured it was done on purpose, here's why I think doing it the current way is better for the average case, and for the long term:

• Installing packages in one command saves a significant number of network round trips to the Alpine Package servers - every call to add --update pulls the fresh package lists, which creates load on their systems, more work for Docker to build, and more time.

• When package lists are static (e.g. when you're not actively changing and adding frequently), there's near-zero gain to having them in multiple commands. It creates multiple layers, which is just file system and layer churn on Docker's end. Incremental caching may be useful in development, but not for building a release asset that is deployed.

• For the non-builder image, combining the package installation to a single command creates a single layer, which reduces image file size and pull/push time for everyone who uses these images. I believe it's a safe bet that these images are used more than they're built - optimizing for the final product should be the goal of the main Dockerfile, in my opinion, as this is what users are going to run in CI and/or push and pull frequently.

Ultimately, I think combining everything to reduce layers matches the Docker best practices, optimizes for the common case of building a release asset and not a development tool, and produces the easiest to read, digest and work with Dockerfile, as it follows the accepted Docker best practices, which result in a smaller and more efficient image.

[shlomi-noach]

I believe it's a safe bet that these images are used more than they're built

That makes perfect sense.

Thank you!