Intro Guide to Dockerfile Best Practices

As is the case with the Docker&#x27;s best practices for Dockerfiles in the official documentation, they&#x27;re leaving out some really important details.<p>Specifically, they don&#x27;t really express how Docker packaging is a process integrating the way you build, where you build, and how you build, not just the Dockerfile.<p>1. Caching is great... but it can also lead to insecure images because you don&#x27;t get system package updates if you&#x27;re only ever building off a cached image. Solution: rebuild once a week from scratch. (<a href="https:&#x2F;&#x2F;pythonspeed.com&#x2F;articles&#x2F;docker-cache-insecure-images&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pythonspeed.com&#x2F;articles&#x2F;docker-cache-insecure-image...</a>)<p>2. Multi-stage builds give you smaller images, but if you don&#x27;t use them right they result in breaking caching completely, destroying all the speed and size benefits you get from layer caching. Solution: you need to tag and push the build-stage images too, and then pull them before the build, if you want caching to work. (Long version, this is a bit tricky to get right: <a href="https:&#x2F;&#x2F;pythonspeed.com&#x2F;articles&#x2F;faster-multi-stage-builds&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pythonspeed.com&#x2F;articles&#x2F;faster-multi-stage-builds&#x2F;</a>)

Use the experimental BuildKit Dockerfile frontend for much improved build time mounting: <a href="https:&#x2F;&#x2F;github.com&#x2F;moby&#x2F;buildkit&#x2F;blob&#x2F;master&#x2F;frontend&#x2F;dockerfile&#x2F;docs&#x2F;experimental.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;moby&#x2F;buildkit&#x2F;blob&#x2F;master&#x2F;frontend&#x2F;docker...</a><p>* You can mount build-time secrets in safely with `--mount-type=secret`, instead of passing them in. (Multistage builds do alleviate the problems with passing secrets in, but not completely.)<p>* Buildkit automatically parallelizes build stages. (Of course!)<p>* Mount apt-cache dirs in at build time with `--mount-type bind` so that you don&#x27;t have to apt-get update every single time, and you don&#x27;t have to clear apt-caches either.<p>And lots more.<p>Notice that this mostly involves capabilities that Docker already has to <i>build time</i>.

If you use multi-stage builds be aware that COPY --from also can do a chown and save image size - doing a RUN chown -R that is sometimes necassary to run stuff as a regular user <i>duplicates</i> the image size because changed metadata equals a copy for Docker.<p>Also if you dare to enable user-namespaces for Docker because, well also security - multi-stage builds fail (<a href="https:&#x2F;&#x2F;github.com&#x2F;moby&#x2F;moby&#x2F;issues&#x2F;34645" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;moby&#x2F;moby&#x2F;issues&#x2F;34645</a>)

Tip #6 (Use official images when possible) is certainly convenient when you&#x27;re just spinning up something (I use them in local docker-composes all the time), but it&#x27;s surely opening yet another security hole when it comes to prod. We&#x27;re not lacking examples where packages are hijacked (feels like it happens constantly on npm, rubygems had it just the other day...), and docker hub has already had one security breach.<p>Perhaps worth a mention in this blogpost?

For Java it’s better to use Jib Gradle&#x2F;Maven plugin from Google. It produces docker image directly and creates layers with dependencies and class files.

I&#x27;ve read several &quot;Dockerfile best practices&quot; would-be tutorials, and this one stands out as both correct, concise, well explained, and ordered from simple and important to more nuanced. To the author - great job.

Could someone explain why tip#9 is a good idea? To me it makes more sense to build the application in the CI pipeline and use Dockerfile only to package the app.<p>The post is focused on Java apps but, for example, there is a distinction on runtime and SDK images in .NET Core. If you want to build in Docker, you have to pull the heavier SDK image. If you copy the built binaries to image, you can use the runtime image. I guess there could be similar situations in other platforms too.<p>Other than that, it looks like a decent guide. Thanks to the author.

I thought about using Docker for a reproducible build environment but, in that context, found it problematic that every time a Dockerfile is built you may end up with new base images and different package versions. That&#x27;s hardly reproducible.<p>Perhaps I&#x27;m coming at this from a wrong angle.

Dockerfiles are a mostly adequate prototyping tool but are not great for generating production builds. Lack of modularity, cascading versioning &#x2F; dependency management, reproducible builds, ... every time I&#x27;ve used Dockerfiles in anger I&#x27;ve cobbled together another 60% of a build system out of bash scripts.<p>I wish Dockerfiles would just fade away into the background, and be replaced by something more similar to an archiver but with better integration with repositories and versioning metadata.

Dockerfile = docker run + docker commit + MANY unneeded limitations

Order of copying is especially important with Java (Maven&#x2F;Gradle) builds and NPM, it saves time.<p>Its also good to speed up builds with configuring them to cache artifacts in a separate layer before the build happens or you can get them to use the host machines cached .m2 &#x2F;.npm folders as a volume, however that might not work with pipelines etc. that build the docker containers.

COPY caching doesn&#x27;t work between computers.<p>This was surprising to me. I thought I could `docker pull` the layers from the registry and only re-build what had changed on my machine. But no, this doesn&#x27;t work.<p>The reason is that the docker client archives the source files, including all the file attributes like uid,gid,mtime, ... Between two computers those are bound to be different.

I highly recommend checking out <a href="https:&#x2F;&#x2F;github.com&#x2F;docker&#x2F;buildx" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;docker&#x2F;buildx</a> . It’s still in tech preview but it’s an exciting look at the future of docker-build.

What about changing the default USER in the dockerfile?

so if you want a vi in your image (the article has a vim line) you can get one (because they are occasionally useful) for a low cost by installing <i>nvi</i> instead of vim. It&#x27;s great and only a few K.

My personal best practice is to never use docker.