Volumes and bind mount

At this point, it may seem that having a writeable container layer for each container is enough to provide state persistence for your application. Data is persisted, even if you stop and restart the same container afterward. Unfortunately, you would easily discover that containers and their writeable layers are tightly coupled and that you cannot easily share data between different containers or even new instances of the same image. A simple scenario where this becomes apparent is as follows:

1. Build a container image based on your current Dockerfile.
2. Start a new container based on this build.

3. Introduce some modifications to the writeable container layer; for example, a process inside the container modifies a file that stores data for the application.
4. Now, you would like to create a new version of your image by modifying the Dockerfile with additional instructions. At the same time, you want to recreate the container and reuse the data in the file that has already been modified in the container's writable layer.

You will realize that after recreating the container with the new image version, all of the changes that you made to the file using the application state will be gone. Apart from this, using the container layer to store data has more disadvantages:

• The writeable layer is coupled with the container host, which means it isn't possible to easily move the data to a different host.
• Layer filesystems provide worse performance than direct access to the host filesystem.
• You cannot share the writeable layer between different containers.

Docker provides two solutions for persistent storage that can be mounted into a container: volume and bind mounts. In both cases, the data is exposed as a directory in the container filesystem and will be persisted, even if the container is stopped and deleted. In terms of performance, both volumes and bind mounts access the host's filesystem directly, which means there is no layer filesystem overhead. It is also possible to share data between multiple containers using these Docker features.

Bind mounts provide a simple functionality of mounting any file or directory from the container host to a given container. This means that a bind mount will act as a shared file or directory between the host and a container. In general, it is not recommended to use bind mounts as they are harder to manage than volumes, but there are certain use cases when bind mounts are useful, especially on the Windows platform, where volume support is limited.

Volumes provide similar functionality to bind mounts but they are fully managed by Docker, which means you don't have to worry about physical paths in the container's host filesystem. You can create anonymous or named volumes and then mount them into containers. Any data in the volume will not be deleted unless you explicitly delete the volume using Docker. A very common use case for volumes is providing persistent storage for containers that are running a database instance – when the container is recreated, it will use the same volume that contains the data that was written by the previous container instance.

Now, let's take a look at how to perform basic operations on Docker volumes.