Oct 3, 2023 5 min read Containers

Data Volumes and Configuration in Containers.

Whats an application if it doesn't consume or produce data? Its definitely not meaningful. At this point, you should be asking "but aren't containers ephemeral and when they die, they take all their data files with them?".

Yes that is indeed true. They are fickle and greedy :) and don't like to share their files and generated data UNLESS of course there is some coercion (technically speaking) for them to not behave like they do.

Enter Docker Volumes.

The importance of Volumes

Run a container and execute a script in it that creates a new file.

$ docker container run --name vol-demo
alpine /bin/sh -c 'echo "Volumes are great" > demo.txt'

The script above will run an alpine image, name it vol-demo and as part of its functionality, the running container will write "Volumes are great" to a file called demo.txt.

The command will run and exit, leaving the container behind for our investigation.

We can check, using diff the difference between alpine and vol-demo.

Figure 1:vol-demo has an additional demo.txt file inside it.

If we were to remove vol-demo from our list of docker containers, the contents of demo.txt will also be lost to us forever. However, if we had some mechanism to store demo.txt, vol-demo getting lost in cyber space will not automatically mean loss of data.

Creating Volumes

Its very simple. Really. Use the script provided below and Docker will create a new Volume.

$ docker volume create demo-vol

Once the Volume is created, its name will be printed on the terminal.

Figure 2:demo-vol was created.

The default Volume driver is the local driver, which stores the data locally in the host filesystem.

But where in the filesystem?

Use

$ docker volume inspect demo-vol

and this will show you the exact location the contents of the Volume will be saved.

**Figure 3:** The data is stored in **/var/lib/docker/volumes/demo-vol/_data**.

Mounting Volumes

Mounting is a fancy word for "how do we use the Volume we just created"?

Docker Volumes can be mounted using

$ docker container run \
--name demo-vol-container -it \
-v demo-vol: /data \
alpine /bin/sh

What do all these words mean?

**Figure 4:** Mounting a Volume inside a container.

1 (& 5): A typical run command for a container which in this case is alpine
2: Names the container demo-vol-container
3: Run the container in an interactive mode
4: Remember that Volume (demo-vol) just created? Map it to the /data folder
5: Along with the name of the image to run, also tells Docker to take us inside the container to its shell.

**Figure 5:** A conceptual diagram showing Mounting a Volume to a folder.

As a result of the commands in Figure 4, the container will run and we will be taken to its shell.

**Figure 6:** At the terminal inside the running container.

We can add a file inside the container and put some content in it.

**Figure 7:** Create data files inside the **data** folder.

To confirm the files were indeed created inside data, we can use typical Linux commands.

**Figure 8:** Data files were created and we can see them inside **/data**.

Now we will delete container demo-vol-container.

$ docker container rm demo-vol-container

Did the deleting of the container also delete the Volume?

We can confirm the Volumes state using

$ docker volume inspect demo-vol

**Figure 9:** Lo and behold, the container getting removed did not result in Volume getting removed.

**Figure 10:** Conceptual description of what happens to any Volume when the container its mounted to is deleted.

The container was deleted but the Volume was not. This is great because if we were to spin up a brand new container and mount demo-vol to it, we should, in theory, be able to get to data.txt and data2.txt.

Theory is theory. Prove your statement using a practical example.

Let's spin up a new container then.

**Figure 10:** Spin up a new container using the centos:7 image.

1: Typical docker container run command
2: Name the container check-data-folder
3: Launch the container in an interactive mode
4: Remove the container once it stops running (however, the image from which the container was launched still exists)
5: We want to re-use demo-vol and want to mount it to a folder /app/data inside the new container
6: Image to use is centos:7
7: Place our cursor at the shell inside the container, as soon as it starts running

**Figure 11:** The new container's **/app/data** has a view of **data.txt** and **data2.txt**.

We can confirm the claim made for Figure 11 by checking the contents of /app/data.

**Figure 12:** The **/app/data** folder has **data.txt** and **data2.txt.**

Figure 12 confirms that demo-vol's files (data.txt and data2.txt) are accessible through the new container.

Removing Volumes

Volumes can be removed using the docker volume rm command.

$ docker volume rm <name of volume>

💡

Remember that removing a Volume destroys the containing data permanently. Docker will NOT allow us to delete a Volume that is being used by a container.

I write to remember and if in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.

Table of Contents.

The importance of Volumes

Creating Volumes

But where in the filesystem?

Mounting Volumes

What do all these words mean?

Did the deleting of the container also delete the Volume?

Theory is theory. Prove your statement using a practical example.

Removing Volumes

You might also like...

How Do I Execute Terraform Commands in a Docker Container?

How do I make a Docker Container using Terraform?

Creating and Managing Container Images.

Creating Docker Containers.

Storing Docker Images.