1) Squash your builds
\nThis is now part of default docker, but it was well worth it even before. Docker will create a new tarball for each `stage` – Each ADD, RUN, etc creates a new layer that, by default, you upload. This means if you add secret material and then delete it – you haven’t really deleted it. More commonly, it bloats your image sizes. A couple intermediate files can be a huge pain, and waste your time and bandwidth uploading.<\/p>\n
Don’t squash down to a single, monolithic image – Pick a good base point. Having a fully-featured image as a base layer is not a sin – So long as you reuse it, it doesn’t take up any more space or download time, so your lightweight squashed build can build on top of it.<\/p>\n
2) Use Multistage builds
\nYour build environment should be every bit as much a container as your output. Don’t build your artifacts in your local machine and then add them to your images – You’re likely polluting your output with local state more than you know. Deterministic builds require you to understand the state of the build machine and make sure it doesn’t leak, and containers are a wonderful tool for that. <\/p>\n
Alternatively: 1) Squash your builds This is now part of default docker, but it was well worth it even before. Docker will create a new tarball for each `stage` – Each ADD, RUN, etc creates a new layer that, by default, you upload. This means if you add secret material and then delete it – you … Continue reading Kubernetes Build best practices<\/span>
\nJust use Bazel. Bazel’s https:\/\/github.com\/bazelbuild\/rules_docker<\/a> is pretty simple to use, powerful, and generates docker-compatible images without actually running docker.<\/p>\n","protected":false},"excerpt":{"rendered":"