Should I minimize the number of docker layers?

The documentation doesn't elaborate on the topic a lot. It says:

Minimize the number of layers

Prior to Docker 17.05, and even more, prior to Docker 1.10, it was important to minimize the number of layers in your image. The following improvements have mitigated this need:

In Docker 1.10 and higher, only RUN, COPY, and ADD instructions create layers. Other instructions create temporary intermediate images, and no longer directly increase the size of the build.

Docker 17.05 and higher add support for multi-stage builds, which allow you to copy only the artifacts you need into the final image. This allows you to include tools and debug information in your intermediate build stages without increasing the size of the final image.

It looks like the latest Docker versions don't solve the problem of handling many layers. They rather strive to reduce their number in the final image. Most importantly, the docs don't tell why many layers are bad.

I'm aware of the AUFS limit of 42 layers. It makes sense to keep the number of layers small for widely used images because it helps other images built on top of them fit the restriction. However, there are another storage drivers and images for other purposes.

It is also good to keep images small for an obvious reason - they take up disk space and network bandwidth. However, I don't think that chaining RUN statements and thus squashing many layers into one helps in general. In case different RUNs update different parts of the filesystem one layer and many layers together should be approximately the same in size.

On the other hand, many layers allow to make use of cache and rebuild images faster. They are also pulled in parallel.

I work in a small team with a private Docker registry. We won't ever meet the 42 layers restriction and care mostly about performance and development speed.

If so, should I minimize the number of docker layers?

Solution

I work in a small team with a private Docker registry. We won't ever meet the 42 layers restriction and care mostly about performance and development speed.

If so, should I minimize the number of docker layers?

In your case, no.
What needs to be minimized is the build time, which means:

making sure the most general steps, and the longest are first, that will then cached, allowing you to fiddle with the last lines of your Dockerfile (the most specific commands) while having a quick rebuild time.
making sure the longest RUN command come first and in their own layer (again to be cached), instead of being chained with other RUN commands: if one of those fail, the long command will have to be re-executed. If that long command is isolated in its own (Dockerfile line)/layer, it will be cached.

That being said, the documentation you mention comes from docker/docker.github.io, precisely PR 4992 and PR 4854, after a docker build LABEL section.
So this section comes after a similar remark about LABEL, and just emphasize the commands creating layers.
Again, in your case, that would not be important.