Docker volumes are very useful when we need to persist data in Docker containers or share data between containers.
Docker volumes are important because when a Docker container is destroyed, it’s entire file system is destroyed too. So if we want to keep this data in some way, it is necessary that we use Docker volumes.
Docker volumes are attached to containers during a
docker run command by using the -v flag
Let’s look at the docker image we created in a previous article. The
The working directory is
/var/www, and the application code is there. If we want to run an Adonis application in a container from this image and we don’t want all our files to be deleted once we stop the container, then we have several choices.
A bind mount is just mapping a directory on the host machine to a directory in the container. However, when the container is removed, it does not affect the directory.
--volume flag’s value is a path, then it is assumed to be a bind mount. If the directory does not exist, then it will be created. When we do this, the directory
/path/to/app/directory will contain the same files as
/var/www in the container.
docker run -d --name adonis \ -v /path/to/app/directory:/var/www \ stephenafamo/adonisjs:1.0.0
NOTE : If you are confused about how to use the
docker runcommand or how to run containers, then you can go through the the previous article.
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:
- Volumes are easier to back up or migrate than bind mounts.
- You can manage volumes using Docker CLI commands or the Docker API.
- Volumes work on both Linux and Windows containers.
- Volumes can be more safely shared among multiple containers.
- Volume drivers allow you to store volumes on remote hosts or cloud providers, to encrypt the contents of volumes, or to add other functionality.
- A new volume’s contents can be pre-populated by a container.
In addition, volumes are often a better choice than persisting data in a container’s writable layer, because using a volume does not increase the size of containers using it, and the volume’s contents exist outside the lifecycle of a given container.
We can create a Docker volume using the command
docker volume create volume_name
To list all the volumes, we use the following command.
docker volume ls
If we ever choose to delete a Docker volume, we do it using the command.
docker volume rm volume_name
We can also use the
--volume flag to attach a Docker volume to a container. However, instead of putting the path to the directory on the host machine as we did with bind mounts, we simply put the volume name.
docker run -d --name adonis \ -v adonis_vol:/var/www \ stephenafamo/adonisjs:1.0.0
NOTE : If we specify a volume that does not exist, it will be created
If we start a container that creates a new volume and attach it to a destination in the container that contains files, then the files in the destination are copied into the volume.
For example, in our
stephenafamo/adonisjs image, a new application will be created in the
/var/www directory if an empty volume is mounted there.
Since a Docker volume (or bind mount) can be attached to multiple containers, it may be useful for only some of the containers to be able to write to it.
To achieve this, we will need to attach the volume to the other containers in read-only mode. This is done by adding the
ro option like this;
docker run -d --name adonis \ -v adonis_vol:/var/www:ro \ stephenafamo/adonisjs:1.0.0
This works for both Docker volumes and bind mounts.
So, this covers the common uses of Docker volumes. There are also several volume drivers that allow for some more functionality. Perhaps we’ll talk about that in another article, or maybe I’ll update this later.
As always, I appreciate comments, suggestions and corrections. Thank you.