Docker Containers and volumes
When the default disk space allocated to a container is not appropriate for the job at hand, In these cases we need storage that can persist between container deployments.
In such case we use --mount or -v option.
Volumes
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers.
While bind mounts are dependent on the directory structure and OS 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 let you store volumes on remote hosts or cloud providers, to encrypt the contents of volumes, or to add other functionality.
- New volumes can have their content pre-populated by a container.
- Volumes on Docker Desktop have much higher performance than bind mounts from Mac and Windows hosts.
In addition, volumes are often a better choice than persisting data in a container’s writable layer, because a volume doesn’t increase the size of the containers using it, and the volume’s contents exist outside the lifecycle of a given container.
If your container generates non-persistent state data, consider using a tmpfs mount to avoid storing the data anywhere permanently, and to increase the container’s performance by avoiding writing into the container’s writable layer.
We can specify the volume by using --volume or -v option.
- This option consists of three fields, separated by colon characters
(:). The fields must be in the correct order, and the meaning of each field isn’t immediately obvious. - In the case of named volumes, the first field is the name of the volume, and is unique on a given host machine. For anonymous volumes, the first field is omitted.
- The second field is the path where the file or directory are mounted in the container.
- The third field is optional, and is a comma-separated list of options, such as
ro.
docker container run --rm -it --name alpine_linux --volume "$(pwd)"/tests:/tests ubuntu:latest /bin/bash
Read only:
docker container run --rm -it --name alpine_linux --volume "$(pwd)"/tests:/tests:ro ubuntu:latest /bin/bash
Backing up data
docker run -v /dbdata --name dbstore ubuntu /bin/bash
In the next command:
- Launch a new container and mount the volume from the dbstore container
- Mount a local host directory as /backup
- Pass a command that tars the contents of the dbdata volume to a backup.tar file inside our /backup directory.
docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
When the command completes and the container stops, it creates a backup of the dbdata volume.
See how to restore volume from backup
Removing volumes
A Docker data volume persists after you delete a container. There are two types of volumes to consider:
- Named volumes have a specific source from outside the container, for example, awesome:/bar.
- Anonymous volumes have no specific source. Therefore, when the container is deleted, you can instruct the Docker Engine daemon to remove them.
To automatically remove anonymous volumes, use the --rm option. For example, this command creates an anonymous /foo volume. When you remove the container, the Docker Engine removes the /foo volume but not the awesome volume.
docker run --rm -v /foo -v awesome:/bar busybox top
If another container binds the volumes with
--volumes-from, the volume definitions are copied and the anonymous volume also stays after the first container is removed.
To remove all unused volumes and free up space:
docker volume prune