Sometimes, applications need to share access to data or persist data after a container is deleted. Databases, user-generated content for a web site and log files are just a few examples of data that is impractical or impossible to include in a Docker image but which applications need to access. Persistent access to data is provided with Docker Volumes.
check volume persistence
Create an independent volume and Inspect it.
docker volume create --name DV_apple #it allows you to create a volume without relating to any particular containers.
Create a container and attach it with the volume ---> Write sth to the voulme--->Exit. Note that If /dv_apple exest, the content in it will be hidden. --rm means remove the container when exiting the container.
Where it the greetings.txt? It's here
Create a new container and attach it with the same volume--->Read the same content from the volume--->Exit
VICTORY! Volume persistence is verified.
Note:
(1)-v /path:/path/in/container VS -v path:/path/in/container
the former loads a host dir while the latter loads a volume.
(2)volume can only be removed(use docker volume rm vol_name) if all containers referred to it are removed(not stopped).
(3)you can’t mount a host directory(-v /path:/path/in/container) from Dockerfile because built images should be portable while a host directory wouldn’t be available on all potential hosts.
what if /path/in/container has data?
The answer is the data will be copied into the volume. Lets see
After exiting, we start a new container that attach DV_orange
We see that DV_orange has a copy of the contents of the base image's /var dir. To further check, see
share data among multiple containers
So far, we've attached a volume to one container at a time. But often, we'll want multiple containers to attach to the same data volume. This is relatively straightforward to accomplish, but there's one critical caveat: at this time, Docker doesn't handle file locking. If you need multiple containers writing to the volume, the applications running in those containers must be designed to write to shared volume in order.
First, create container con1:
Then, create container con2:
Finally, restart con1 and check mix_msg.txt:
NOTE:
(1)The other way to avoid data corruption is to let all the other containers only have the read-only right for the shared volume.
(2)Any changes in /path will reflect in /path/in/container realtime, and any changes in /path/in/container will reflect in /path realtime.
Mount a shared-storage volume as a data volume
In addition to mounting a host directory in your container, some Docker volume plugins allow you to provision and mount shared storage, such as iSCSI, NFS, or FC. Here we use flocker plugin which is a volume plugin that provides multi-host portable volumes for Docker, enabling you to run databases and other stateful containers and move them around across a cluster of machines.
docker run -d -P --volume-driver=flocker -v my-named-volume:/webapp --name web training/webapp python app.py #with flocker volume driver we create a shared volume named "my-named-volume" and mount it to /webapp
you may also use the docker volume create command, to create a volume before using it in a container: