Mastering Docker Volumes: Essential Guide to Container Data Management

While working with Docker, I observed that four key pillars form the foundation of Docker's architecture: Images, Containers, Volumes, and Networks. In this blog, we’ll dive deep into one of these pillars — Docker Volumes — which are essential for data persistence in containerized environments.
📦 What Are Docker Volumes?
Docker Volumes are the recommended mechanism for persisting data created and used by Docker containers. Unlike data stored in a container's writable layer, which disappears when the container stops or is removed, volumes allow data to exist outside the container’s lifecycle.
A volume is like an external storage device connected to your container. When you write data inside the container, Docker redirects it to the mounted volume. This ensures that the data survives container restarts or even deletions.
🧠 Analogy: Think of containers like whiteboards used during meetings. Once the meeting ends (container stops), the whiteboard is wiped clean. Docker volumes, on the other hand, are like notebooks — they retain all important notes (data) long after the meeting is over.
🔧 Why Use Docker Volumes?
Here are a few practical reasons why Docker volumes are preferred over other storage methods like bind mounts or temporary container storage:
Data Persistence: Keeps your data safe even when containers are removed.
Portability: Volumes can be backed up, restored, and moved easily.
Isolation: Volumes are managed by Docker and are isolated from the host machine.
Flexibility: You can mount the same volume across multiple containers, enabling data sharing.
🛠 Real-World Use Case: Sharing Data Across Containers
In production environments, it’s common to run multiple containers for the same service (like load-balanced web servers or microservices). Managing consistent data or configuration across all containers can be challenging.
Docker volumes solve this issue efficiently:
You can mount the same volume to multiple containers.
Any updates made by one container will be instantly reflected in the others.
This ensures synchronization of files, configurations, or logs across all running instances.
⚠️ Production Tip:
While volumes simplify data sharing, always ensure you understand your application's data consistency needs. Improperly handled shared volumes can lead to race conditions or file lock issues in concurrent environments.
Common commands in volumes:
To create a volume:
Copy
docker volume create volume-name
To see the list of volumes:
Copy
docker volume ls
To see the full details about volume:
Copy
docker volume inspect volume-name
To delete a volume:
Copy
docker volume rm volume-name
NOTE: We can’t remove the volumes which are attached to containers. It should be free from container.
To delete multiple volumes:
Copy
docker volume rm volume-name volume-name volume-name
To delete unused volumes:
Copy
docker volume prune
Practical implementation of volumes:
Lets create a volume and mount it to container:
Copy
docker volume create swiggy
Now i have created a swiggy volume
To inspect the volume:
Copy
[root@ip-172-31-13-80 ~] docker volume inspect swiggy
[
{
"CreatedAt": "2025-01-25T08:17:45Z",
"Driver": "local",
"Labels": null,
"Mountpoint": "/var/lib/docker/volumes/swiggy/_data",
"Name": "swiggy",
"Options": null,
"Scope": "local"
}
]
Now we can see the mountpoint: /var/lib/docker/volumes/swiggy/_data
Lets mount it to container:
Copy
docker run -itd --name cont1 --mount src=swiggy,destination=/myapp ubuntu
Now the container will be created, inside the container /myapp folder will be there. Lets go to container check it.
Go to container:
Copy
docker exec -it cont1 bash
Now we will enter into the container, we can see myapp folder is there.

Lets add some files and folders inside the myapp folder
Copy
cd myapp
touch file{1..4}
mkdir devops{1..3}
ls

Now exit from the container and check the swiggy volume, the data is present on volume.
Go to volume path
Copy
cd /var/lib/docker/volumes/swiggy/_data/
now check the files:

Even if we add some files here, then the data will replicate inside the container.

Now lets go to container1 and check the files present in myapp folder.

NOTE: So we can clearly observe that the data is replicated between container to host. we can mount our volumes to multiple containers to replicate the same process.
Host to Container:
Bind mounts have been part of Docker since the beginning. They help us to link a file or folder from our Docker host to the container’s file system. If the file or folder doesn’t already exist in the container, Docker will create it automatically when we start the container. Any changes you make to that file or folder on our Docker host will show up in the container, and any changes made inside the container will show up on our Docker host.
However, this can create security risks. For example, if something inside the container changes a file, that change will also affect the file on our Host. So, you need to be careful when using bind mounts.
Bind mounts are especially useful during development. You can link your code folder to the container, so when you update your code, the changes will appear in the container immediately. This saves time since you don’t have to rebuild the image every time you make a change.
Practical implementation of Bind mounts:
lets create a folder in Dockerhost
Copy
mkdir zomato && cd zomato
now create some files
Copy
touch index.html app.py style.css requirements.txt

Now lets create the container inside the same directory:
Copy
docker run -itd --name cont2 -v "$(pwd)":/appcode ubuntu
Now lets get into the container and check the same files
Copy
docker exec -it cont2 bash
cd appcode

Now lets create some files inside the container, that will replicate in Dockerhost on the same zomato folder

now lets exit from container and check in docker host

So here also the data is replicated on between host to container. We can create multiple containers from same path to replicate the data to containers.
In the above 2 models, we observed that data replication is like a 2 way [host to container, container to host]. This can create security risks. For example, if something inside the container changes a file, that change will also affect the file on our Host. So, we need to restrict by preventing the changes on container we need to create readonly volumes.
Read Only Volumes
We can make a volume read-only so that the container can read from that volume and can not write. It can be used if you have any security concerns depending upon the requirement of the application. These volumes will create while creating the container only
command to create a container with read only volume:
Copy
docker run -itd --name mustafa -v uber:/app:ro ubuntu
In the above command, uber is the volume that will created on host, and /app is the path where we mounted inside the container. ro represents the readonly volume.
Now lets enter into the container and add some data on /app folder, we will get permission denied error.
Copy
docker exec -it mustafa bash
cd app

see, we cant write the data from container, but if we write the data on uber volume in docker host, it will replicate here.
Sharing the volumes from container-container
we can share the volume from one container to another container while creating.
Copy
docker run -itd --name devops --privileged=true --volumes-from=mustafa ubuntu
In the above command, we can see the volumes from mustafa container is going to share with devops container.
Creating a volume using Dockerfile
Not only with the commands, we can also create the docker volumes with Dockerfile
Copy
FROM ubuntu
VOLUME [/mycode]
If we build the above Dockerfile and run the image, automatically a container and a random volume will be created. Now the volume will present inside the volume, when ever we run the image, automatically this volume will creates.
Examples of docker volumes
Example-1:
create a volume
Copy
docker volume create paytmgo to that volume path
Copy
/var/lib/docker/volumes/paytm/_data/add some code in that volume

Now lets create a container by mounting the volume
Copy
docker run -itd --name freelancer -p 1234:80 --mount src=paytm,destination=/usr/local/apache2/htdocs/ httpdNow lets access the application using 1234 port

- We can share this volume to any container.
Example-2:
Create a folder on Docker host
Co
mkdir testapp && cd testappKeep the code inside the folder

Now create a container from the same folder
Copy
docker run -itd --name cont99 -p 1122:80 -v "$(pwd)":/usr/share/nginx/html/ nginx
Now lets access the application using 1122 port

Example-3:
We can directly create a container and volume first
Copy
docker run -itd --name app-container -p 2233:80 -v mydata:/usr/share/nginx/html nginxIf we access the app using 2233 port, we will get only nginx page

Lets add the data on mydata volume
Copy
cd /var/lib/docker/volumes/mydata/_data/make some modifications on index.html file and refresh the browser

Conclusion
Docker Volumes are a powerful tool for ensuring data durability, consistency, and portability in containerized systems. Whether you're developing locally or deploying to production, understanding how to use volumes correctly can make your Docker workflow far more reliable and scalable.
Stay tuned for the next post in this series, where we'll explore another foundational concept — Docker Networks.
Comments
Join the discussionNo comments yet. Be the first to comment.