Before running the full stack, let's talk a little bit about how images depend on each other. Docker is designed so that images can share common parts instead of duplicating them. This saves disk space, and avoids downloading the same files multiples times. It relies on a simple principle: an image is a filesystem packaged in a file. An image inherits from another image (or nothing, for root images); this means that a new image contains all the files of its parent image. New files are the only ones being stored in the new image. With this principle, only the differences from parent images must be stored on each image. Moreover, many different images can share the content of common parent images.
Technically, this is implemented on top of an overlay filesystem (also called an onion filesystem). The following figure shows the principles of an overlay filesystem:
An image is composed of the files present in several other layers. Each upper layer can add new files, replace existing ones, or mark files as deleted. In Figure 11.6, the base image contains the files bar and buz. The second layer image adds the biz file.
Finally, a third layer adds the foo file , removes the biz file, and modifies the buz file. A core principle of Docker images is that they are immutable: once they are created, they cannot be modified. Should this be the case, they cannot be shared between other images. So, when the biz file is removed, it cannot be removed from the second layer. Instead, a specific metadata file is written to indicate that this file does not exist. Also, due to the immutability property of an image, when the buz file is modified, nothing is done on the file of the first layer; instead, the file is copied to the third layer and then modified.
Finally, the final image exposes a filesystem with three files, where the buz file has been modified compared to the root image.
It is important to understand the immutability property of images. It implies that any file written in an image during the build process stays present in the image, even if it is deleted in another image. In fact, layers are not only created for each image, but for each RUN command. This means that credential files should never be manipulated when building Docker images, otherwise they will be present in one layer used by the final image.