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 does not increase the size of the containers using it, and the volume’s contents exist outside the lifecycle of a given container.

![](https://docs.docker.com/storage/images/types-of-mounts-volume.png)

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. ## Share data among machines ## When building fault-tolerant applications, you might need to configure multiple replicas of the same service to have access to the same files.

![](https://docs.docker.com/storage/images/volumes-shared-storage.svg)

There are several ways to achieve this when developing your applications. One is to add logic to your application to store files on a cloud object storage system like Amazon S3. Another is to create volumes with a driver that supports writing files to an external storage system like NFS or Amazon S3. Volume drivers allow you to abstract the underlying storage system from the application logic. For example, if your services use a volume with an NFS driver, you can update the services to use a different driver, as an example to store data in the cloud, without changing the application logic. ## Volume Driver ## When you create a volume using docker volume create, or when you start a container which uses a not-yet-created volume, you can specify a volume driver. The following examples use the vieux/sshfs volume driver, first when creating a standalone volume, and then when starting a container which creates a new volume. ### Initial set-up ### This example assumes that you have two nodes, the first of which is a Docker host and can connect to the second using SSH. On the Docker host, install the vieux/sshfs plugin: ```bash $ docker plugin install --grant-all-permissions vieux/sshfs ```
### Create a volume using a volume driver ### This example specifies a SSH password, but if the two hosts have shared keys configured, you can omit the password. Each volume driver may have zero or more configurable options, each of which is specified using an -o flag. ```bash $ docker volume create --driver vieux/sshfs \ -o sshcmd=test@node2:/home/test \ -o password=testpassword \ sshvolume ```
### Start a container which creates a volume using a volume driver ### This example specifies a SSH password, but if the two hosts have shared keys configured, you can omit the password. Each volume driver may have zero or more configurable options. If the volume driver requires you to pass options, you must use the --mount flag to mount the volume, rather than -v. ```bash $ docker run -d \ --name sshfs-container \ --volume-driver vieux/sshfs \ --mount src=sshvolume,target=/app,volume-opt=sshcmd=test@node2:/home/test,volume-opt=password=testpassword \ nginx:latest ```
### Create a service which creates an NFS volume ### This example shows how you can create an NFS volume when creating a service. This example uses 10.0.0.10 as the NFS server and /var/docker-nfs as the exported directory on the NFS server. Note that the volume driver specified is local. #### NFSV3 #### ```bash $ docker service create -d \ --name nfs-service \ --mount 'type=volume,source=nfsvolume,target=/app,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:/var/docker-nfs,volume-opt=o=addr=10.0.0.10' \ nginx:latest ```
#### NFSV4 #### ```bash docker service create -d \ --name nfs-service \ --mount 'type=volume,source=nfsvolume,target=/app,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:/var/docker-nfs,"volume-opt=o=addr=10.0.0.10,rw,nfsvers=4,async"' \ nginx:latest ```
#### Create CIFS/Samba volumes #### You can mount a Samba share directly in docker without configuring a mount point on your host. ```bash docker volume create \ --driver local \ --opt type=cifs \ --opt device=//uxxxxx.your-server.de/backup \ --opt o=addr=uxxxxx.your-server.de,username=uxxxxxxx,password=*****,file_mode=0777,dir_mode=0777 \ --name cif-volume ```
Notice the addr option is required if using a hostname instead of an IP so docker can perform the hostname lookup. ## Backup, restore, or migrate data volumes ## Volumes are useful for backups, restores, and migrations. Use the --volumes-from flag to create a new container that mounts that volume. ### Backup a container ### For example, create a new container named dbstore: ```bash $ docker run -v /dbdata --name dbstore ubuntu /bin/bash ```
Then in the next command, we: - 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. ```bash $ docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata When the command completes and the container stops, we are left with a backup of our dbdata volume. ```
### Restore container from backup ### With the backup just created, you can restore it to the same container, or another that you made elsewhere. For example, create a new container named dbstore2: ```bash $ docker run -v /dbdata --name dbstore2 ubuntu /bin/bash ```
Then un-tar the backup file in the new container`s data volume: ```bash $ docker run --rm --volumes-from dbstore2 -v $(pwd):/backup ubuntu bash -c "cd /dbdata && tar xvf /backup/backup.tar --strip 1" ```
You can use the techniques above to automate backup, migration and restore testing using your preferred tools. ## Remove volumes ## A Docker data volume persists after a container is deleted. 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 so when the container is deleted, instruct the Docker Engine daemon to remove them. #### Remove anonymous volumes ### To automatically remove anonymous volumes, use the --rm option. For example, this command creates an anonymous /foo volume. When the container is removed, the Docker Engine removes the /foo volume but not the awesome volume. ```bash $ docker run --rm -v /foo -v awesome:/bar busybox top ```
#### Remove all volumes #### To remove all unused volumes and free up space: ```bash $ docker volume prune ```

Course Content

Managing Docker Container

Docker Compose

Docker test

BUG 538

Docker Volume