Skip to main content

Mastering Docker Volumes: Essential Guide to Container Data Management

Updated 8 min readMarkdown

Docker Volumes: With Real-Time Examples

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 paytm
    
  • go 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/ httpd
    
  • Now 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 testapp
    
  • Keep 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 nginx
    

    If 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.

No comments yet. Be the first to comment.

More from this blog