Docker Volumes: Making Containers Remember Things 🧠

Usually, we store application data inside the container and life feels good until something goes wrong. What if the container crashes? What if it gets deleted? Or what if it collapses under heavy load? In all these cases, the data inside the container vanishes like it never existed. And honestly, we’re bad at remembering which container stored what. That’s when the intelligent hero enters the scene Docker Volumes.

What Docker volumes do ?

Docker Volumes store container data outside the container, so no matter what happens crash, delete, or restart our data stays safe.

Typically we have 2 volumes

• Named Volume or Docker volumes

• Bind mount

Named Volume

Named volumes are managed entirely by Docker. Docker creates and manages the storage location automatically, and we cannot specify a custom host path for named volumes. By default, Docker stores volumes under /var/lib/docker/volumes/myvolume/_data

We can assign any name we want to a volume, and if we don't provide a name, Docker will create one automatically.

Volumes are typically attached when we create a container, not afterward. Any data written inside the mounted container path is stored in the volume, and any existing data in the volume is accessible inside the container. Even if the container is deleted, the data in the volume stays safe. Volumes can also be created and defined using a Dockerfile or Docker Compose.

Let’s Create some Volumes 🫙

Install Docker on your EC2 and change the hostname to docker

sudo yum install docker -y && sudo -i 
hostnamectl set-hostname docker && sudo -i
systemctl start docker

To create a new volume

docker volume create mynewvolume

To list the volumes present in your server

docker volume ls

To demonstrate we need to create a container so let’s write a docker file for nginx

FROM nginx
COPY .  /usr/share/nginx/html
RUN echo "This is my docker file"

Build the docker file for the image

docker build -t myimage:v1 .

Run the image to create a container, and attach the volume while creating the container.

 docker run -itd --name myContainer -p 1111:80 --mount source=myvolume,destination=/rama/mycode myimage:v1

Inspect the container and verify if volume mounted or not

docker inspect myContainer

To create a volume while the container is being created

docker run -itd --name myContainer2 -p 2222:80 -v myVolume2:/rama2/mycode myimage:v1

To delete a volume

docker volume rm myVolume2

To inspect a volume

docker inspect myvolume

To delete unused volumes

docker volume prune

To create a volume anonymously (without specifying a name), Docker assigns a random name for the volume.

docker run -itd --name myContainer -v/rama/code myimage:v1

Bind mount volume

Bind mounts are another type of Docker volume.
Unlike named volumes, Docker does not manage the storage location for bind mounts. Instead, we manually choose a host (EC2/server) directory, and Docker mounts that directory into the container.

So whatever is stored inside the container path is actually stored directly on the host machine path.

To create a bind mount volume

docker run -d --name mycontainer -v /home/ec2-user/mydata:/usr/share/nginx/html nginx

• /home/ec2-user/mydata → Host (EC2 server) path

• /usr/share/nginx/html → Container path

Real-Time DevOps Use Cases 🌍

Conclusion

Docker Volumes are essential for managing data persistence in containerized applications. By keeping data outside the container, they ensure your data stays safe and accessible, even if the container crashes, is deleted, or restarted. Whether you use named volumes managed by Docker or bind mounts for manual control over storage locations, Docker Volumes offer flexibility and reliability. They are especially useful in real-time DevOps situations, where persistent storage is crucial for databases, application logs, and other important data. Using Docker Volumes can greatly improve the resilience and efficiency of your containerized applications.

If you found this guide useful, please like ❤️, comment, and share your thoughts or questions. Stay tuned for the next part, where we'll explore advanced Docker concepts and practices.

Thank you,
Yours, Rama Grandhi