Docker 101: Volume & Bind Mounting
I have been working very closely with the DevOps team at the organisation I currently work at. For a guy who comes from a pen-testing background, listening to the word “Docker” day in and day out became frustrating to a point where I decided to just leave security all together for some time and get involved in the DevOps part of things.
For the past few days, I have been binge-watching Docker tutorials, understanding why is it required, what are its benefits and how it saves time and resources. After putting in the work, I have realised that dockers are here to stay for a long time and how beneficial it is for everyone from development to deployment and management.
Last week I published my third article, Docker 101: Layered Architecture & Networking. You can go back to those article and have a look at them so to be better able to understand the following article.
In my previous article about layered architecture and networking I mentioned how the docker images are created in a sequenced layered process. We discuss what are the contents of the image layer and the container layer. We cover networking and the different types of networking that is allowed in the docker platform and the need for each one of them.
Now that we have had our first look at layered architecture and networking we need to discuss one of the biggest cons of Docker and that is, Dockers are stateless. Till the time the docker is up and running everything is good and great but the moment they go down they lose all their data. In this article we will cover how to overcome this con of Docker and the method to do it.
So, the reason why we do volume mounting is pretty clear. This is to ensure that even if the Docker gets destroyed or has to be closed in any emergency condition the data is not lost and we can create a new docker container the very next instant and have all the data retained as if the container never went down in the first place.
So, without wasting any time let’s see how to do we create the persistent volume for docker to save its data at and where does this persistent volume is located on your host machine.
$ docker volume create data_volume
This command is used to create the persistent volume to which the docker if linked to and it location on the docker storage will be
/var/lib/docker |--volumes |--data_volume
Now once that you have created the persistent storage space for dockers our next step will be to link it with the docker container.
$ docker run -v data_volume:/var/lib/mysql mysql
This command helps us mount the volume in side the docker container i.e. we are linking the data being stored in /var/lib/mysql from the mysql docker to data_volume which is present at /var/lib/docker/volumes in your docker space.
The trick is here that even if we just type in the command just above us without typing the volume create command, docker would itself create the data_volume automatically for us and link the volume but it is preferred to type in both the commands rather than typing in only the docker run command.
To give you the example of what I am saying, just type in the following command
$ docker run -v data_volume2:/var/lib/mysql mysql
Docker will still run properly and will have persistent volume storage even though you haven’t created the “data_volume2” volume by yourself
I hope you are with me till now and have been able to understand that I have written here. Moving on to bind mounting let me explain why it is used in the first place. So volume mounting is used to prevent loss of data i.e. when the docker container is shut down due to whatever reason the data should not be lost and must be retained.
The main difference between bind mounting and volume mounting is that we use bind mount to create the persistent volume on the host machine and not in the docker host directory whereas volume mounting does it on the docker host and hence you need to provide the entire directory name while mounting.
$ docker run -v /data/mysql:/var/lib/mysql mysql
This is the command to link the new docker container with the persistent volume that we already have in our local system when we set up in the previous step of configuring our volume mounting.
-v is the old way of doing things, the new methodology is to use the --mount command
$ docker run \ --mount type=bind, source=/data/mysql, target=/var/lib/mysql mysql
Now that we have done mounting actions from both the docker host and docker volume. The next thing we need to understand is what is responsible for managing all this functionality inside of docker.
Dockers use storage drivers for maintaining the layered architecture, moving file across layers to enable copy and write etc. Some of the most common storage drivers are:-
While deciding which of these drivers to use we need to take into account the host OS on which we are using. The good thing is Docker will choose the best storage driver that is suited for your respective OS. As you can expect that different storage drivers will give us different performance and stability characteristics. So you will need to figure out your requirements and then decide which one suites your needs.
This article addresses one of the biggest flaws in dockers i.e. their stateless aspect and how to overcome that using the volume mount or the bind mount. We use the volume mount when we need the data to be stored persistently on the docker volume whereas we use the bind mount when we need the data from the docker to be persistently hosted on the docker host. I have more articles related to Docker that I will be publishing in this upcoming week. Stay tuned for those.
If you enjoyed it please do clap & let’s collaborate. Get, Set, Hack!
Website : aditya12anand.com | Donate : paypal.me/aditya12anand Telegram : https://t.me/aditya12anand Twitter : twitter.com/aditya12anand LinkedIn : linkedin.com/in/aditya12anand/ E-mail : [email protected]
To present you with this content I had to go through a lot of video content and lab environments.