Docker growing directory

Why, collecting an image using Dockerfile, do I get a thick layer cake?

This is due to the internal Docker architecture. A docker image is simply a set of layers, each of which is a file system nugget (more precisely, a nugget that is different from the underlying file system) - in fact it is a copy-on-write file system, in which each layer is created by a separate line in Dockerfile. At that moment, when Docker needs to assemble the final file system, it simply collects the composition from these layers, and when the process running in the container needs to get the contents of file X, the assembled file system returns the contents of the file to the top of the layers containing this file; in case you need to write a file, it is written in a new layer (container layer).

This is a key moment in the infrastructure that kills many birds with one stone:

• Instant start in a new file system - despite the fact that the container is almost completely isolated environment, it does not need to copy a separate file system. The file system is collected instantly, and all changes are written to a new layer belonging to the container, and the container itself can do nothing with the overlying layers.
• Directly build the Docker image is exactly the same principle: each line of Dockerfile runs in a new layer (in a new container whose FS is assembled from previous layers), after which this layer is committed (saved), and the next Dockerfile instruction will be executed in a new the container in which the current layer will be included.
• The ability to collect different images from the same layers: conditional java: 8 weighs about 800 MB. If each image that wants to inherit from it, took 800 MB, then the place would simply survive at an incredible speed. However, the system of layers allows you to download java: 8 once and use it in all derivatives without downloading again, therefore applications on java: 8 will take up only 50-100 megabytes of space.

Each of the above layers has its own identifier - the same format as the containers. These are, of course, not very human-friendly, which is why registries (servers with images), repositories (the name of a particular image, for example, ubuntu) and tags (image version, for example 14.04) were invented. All this together (registry-repository tag) can be used to mark a certain layer in a human-friendly style, while the insides remain the same. And when you build a new image with a specific tag, you, de facto, create more layers of the file system, the last of which is marked by the specified tag. Nothing happens with the old layers - they remain in the same place where they were, because the team for creating a new image cannot mean deleting the old ones (since they may still be needed) —from there are leaks of disk space. Under certain conditions (for example, ADD and the http-address of the archive), the instruction, despite its identity, will each time generate a new layer, possibly of considerable volume - this, of course, needs to be monitored and cleaned outdated images. To delete all images without a tag, you can use the following shortcut:

 docker rmi $(docker images -qf "dangling=true") 

The last thing I want to say is that besides the images, a place can eat and so-called. volume, the cause of which I do not really understand (but, nevertheless, they are and can "hang" inside the host, even when deleting images). They also need to be cleaned from time to time, for this there is a special script .

In docker engine 1.13, you can use docker system prune . See the documentation .

 $ docker system prune WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all dangling images - all build cache Are you sure you want to continue? [y/N]