The concept of docker is to run a compressed image into a container which servers the purpose and then container can be removed, leaving no trace of the data generated during the course of its runtime. This exact case is referred as ephemeral container.
The docker is traditionally non-persistent data storage and retains only the data originally from its image build creation, It provides the facility to integrate the volume mounts to a running container for data storage and manages the persistence issue to a certain extent.
We have realized the ability to store the data on volumes and then make them available to the container runtime environment to satisfy the needs.
As per the practice the docker volumes are mounted to docker image in runtime via the command line arguments which are demonstrated as show below.
This implementation of the docker volumes provides the running container a volume binding capability and this is method in docker volumes can be broadly categorized into two abilities which are listed as follows.
(1) The volume mapping from the host to the target container, This is like directory mapping between the Host and the container which happens during its runtime.
(2) A permanent volume name that can be shared among container and it even persists if the container is deleted and the same volume can be again mounted to another docker container.
The storage options offered by docker are for persistent storage of files and ensures it in cases of docker container restarts and removal of the container.
The example for the host bind volume mapping is as follows:
# docker run -v src:target --name=container-name docker-image -d
The syntax of docker directory mount:
# docker run -it -v /usr/local/bin:/target/local --name=docker-container-with-vol ubuntu:latest /bin/bash
We will invoke a container by mounting the host path to an target container path and mount the host directory to nginx-html /usr/share/nginx/html.
[vamshi@node01 ~]$ docker run -d --name my-nginx -v /home/vamshi/nginx-html:/usr/share/nginx/html -p 80:80 nginx:1.17.2-alpine
34797e6d8939e42bc8cfe36eed4b60521355edadc2fa6c74a26fe4172384575c
Now we log into the container and verify the contents
[vamshi@node01 ~]$ docker exec -it my-nginx1 sh
~ # hostname
34797e6d8939
~ # df -h /usr/share/nginx/html
Filesystem Size Used Available Use% Mounted on
/dev/sda1 40.0G 16.1G 23.9G 40% /usr/share/nginx/html
From the df -h output from the container shows the path /usr/share/nginx/html as mount point.
Checking the contents of the webroot directory at /usr/share/nginx/html inside the container.
~ # cat /usr/share/nginx/html/index.html
<H1>Hello from LinuxCent.com</H1>
This is the same file which we have on our host machine and it is shared through the volume mount.
We verify using the curl command as follows
~ # curl localhost
<H1>Hello from LinuxCent.com</H1>
We can also mount the same directory with as many containers as possible on our system and it can be an effective way of updating the static content being utilized within our containers.
This is a bind operation offered by docker to mount the directory to a container.. This information can be identified by inspecting the docker command as follows:
Here is the extract snippet from the docker inspect container my-nginx1 :
{
"Type": "bind",
"Source": "/home/vamshi/nginx/nginx-html",
"Destination": "/usr/share/nginx/html",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
As we can see the Type of mount is depicted as a bind here.
The formatter can also used with the filtering options in json format
[vamshi@node01 ~]$ docker container inspect my-nginx1 -f="{{.Mounts}}"
[{bind /home/vamshi/nginx-html /usr/share/nginx/html true rprivate}]
The Dockerfile VOLUME expression
Using the Persistent docker volumes.
We now focus our attention to the Docker volume mounts, which are isolated storage resources in docker and are a persistent storage which can be reused and mounted to the containers.
The VOLUME can be used while writing a Dockerfile, it creates a docker image with the volume settings and then mounts to the container when it is startedup.
We use the expression in dockerfile volume.
VOLUME [ "my-volume01" ]
We now build the image and lets observe the output below.
Step 1/4 : FROM nginx-linuxcent
---> 55ceb2abad47
Step 2/4 : COPY nginx-html/index.html /usr/share/nginx/html/
---> c482aa15da5a
Removing intermediate container a621e114a01d
Step 3/4 : VOLUME my-volume01
---> Running in ac523d6a02f0
---> 72423fe5f27d
Removing intermediate container ac523d6a02f0
Step 4/4 : RUN ls /tmp
---> Running in 8fc1fbc0f0bb
---> 0f453e3cfff1
Removing intermediate container 8fc1fbc0f0bb
Here the volume is mounted at the path /my-volume01 based on absolute path from /.
Here my-volume01 will be mounted to /my-volume01 inside the container path
/ # df -Th /my-volume01/
Filesystem Type Size Used Available Use% Mounted on
/dev/sda1 xfs 40.0G 15.1G 24.9G 38% /my-volume01
The information can be extracted by inspecting the container as follows:
# docker container inspect nginx-with-vol -f="{{.Mounts}}"
[{volume 7d6d92cffac1d216ca062032c99eb105b120d769331a2008d8cad1a2c086ad19 /var/lib/docker/volumes/7d6d92cffac1d216ca062032c99eb105b120d769331a2008d8cad1a2c086ad19/_data my-volume01 local true }]
If you would like the volume to be mounted to some other path then you can declare that in Dockerfile VOLUME as below:
VOLUME [ "/mnt/my-volume" ]
The information can be extracted from the docker image by inspecting for the volumes.
"Image": "sha256:72423fe5f27de1a495e5e875aec83fd5084abc6e1636c09d510b19eb711424cc",
"Volumes": {
"/mnt/my-volume": {},
}
The volumes defined in the Dockerfile VOLUME expression will not be visible with the docker volume ls as they are present within the scope of specific docker container. But will be displayed with anonymous hash tags in the output, But they can be shared among other docker containers. We will look at sharing the docker volumes in the following section.It is also important to understand that once the volume is explicitly deleted then its data cannot be recovered again.
Using the container volume from one container and accessing them in another container.
This option is beneficial during the times when a container access and the debug tools are disabled, and you need to view the logs of the container and run analysis on it.
Using the volume from the container and mounting it to another container for auditing purposes.
We have now created a container called view-logs which uses the volumes from another container called ngnix-with-vol
docker run -d --name view-logs --volumes-from nginx-with-vol degug-tools
Best Practices:
The view-logs container can have a set of debug and troubleshooting tools to view the logs of other app containers.
Creating a Volume from the docker commandline:
The docker volume resource has to be initialized first and can be done as follows:
Command to create a docker volume:
# docker volume create my-data-vol
[vamshi@node01 ~]$ docker volume inspect my-data-vol
[
{
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/my-data-vol/_data",
"Name": "my-data-vol",
"Options": {},
"Scope": "local"
}
]
We can use this volume and then mount this to a container as we mounted the host volume in earlier sections.
We will be using the persistent volume name and then mounting the docker volume to a container bind volume name to the target container path..
These options have a specific changes in syntax and has to be specified exactly while running the mount operation.
Below is the syntax:
docker run –volume :</path/to/mountpoint/> image-name.
We have now the docker volume available and mounting it to the target container path /data as follows:
# docker run -d –name data-vol –volume my-data-vol:/data nginx-linuxcent:v4
2dfa965bbbc79a522e9c109ef8eee20bf47e2b61062f3b3df61d4eb677de4506
Verification:
The docker volume can be listed by the following command
Check the mount information with docker volume inspect.
Here is an extract from the docker inspect container
"Mounts": [
{
"Type": "volume",
"Name": "my-data-vol",
"Source": "/var/lib/docker/volumes/my-data-vol/_data",
"Destination": "/var/log/nginx",
"Driver": "local",
"Mode": "z",
"RW": true,
"Propagation": ""
}
As we can see the Type of mount is depucted as a Volume here.
Conclustion:
We have seen the practices of mounting the hostpath to to target container path is a bind operation and the dependency it creates is the host affinity, which is binded to particular host and has to be avoided if you are dealing with more dynamix data exchange between containers over a network. But it is very useful if you have host-container data exchange.
The Option with Volumes is very dynamic and has less binding dependency on the host machines, They can be declared and used in two ways as demonstrated in the before sections. !st being the explicit volume creation and another is the Volume creation from within the Docker build.
The explicit docker creation and then binding provides the scopt of choosing a mount point inside the container after the image is built.
The Dockerfile’s VOLUME expression can be used to automatically define the volume name and the mount point desired and has all the same techniques of volume sharing for data exchange in run time.