As we are aware, the container's read–write layer is temporary, and is destroyed when the container is removed. However, there are use cases wherein you will have to preserve the application data beyond the life cycle of the container. For instance, a Docker registry container holds all the images that are pushed to it. If this container is deleted, then we will lose all the images that it was holding. Perhaps, we can resort to the container's commit flow to preserve the data, but it will bloat the image and complicate the container deployment process. The recommended alternative is to persist the application data outside of the container's filesystem, using volumes or a bind mount. We will discuss bind mounts in the next recipe.

Docker volumes are a special directory in the Docker host, and are created and managed by Docker itself. We can mount these volumes to our container and have the application store its data to the volume. The Docker volumes are either named or anonymous. Functionally, the anonymous volumes are the same as named volumes; however, the anonymous volume name is randomly generated. Docker also supports the volume plugin to address advanced storage needs, which is outside the scope of this book.

In this recipe, we will demonstrate data persistence using one named volume and two containers.