Data Volumes and Configuration

In the last chapter, we learned how to build and share our own container images. Particular focus was placed on how to build images that are as small as possible by only containing artifacts that are really needed by the containerized application.

In this chapter, we are going to learn how we can work with stateful containers—that is, containers that consume and produce data. We will also learn how to configure our containers at runtime and at image build time, using environment variables and config files.

Here is a list of the topics we're going to discuss:

• Creating and mounting data volumes
• Sharing data between containers
• Using host volumes
• Defining volumes in images
• Configuring containers

After working through this chapter, you will be able to do the following:

• Create, delete, and list data volumes.
• Mount an existing data volume...

Technical requirements

For this chapter, you need either Docker Toolbox installed on your machine or access to a Linux virtual machine (VM) running Docker on your laptop or in the cloud. Furthermore, it is advantageous to have Docker for Desktop installed on your machine. There is no code accompanying this chapter.

Creating and mounting data volumes

All meaningful applications consume or produce data. Yet containers are, preferably, meant to be stateless. How are we going to deal with this? One way is to use Docker volumes. Volumes allow containers to consume, produce, and modify a state. Volumes have a life cycle that goes beyond the life cycle of containers. When a container that uses a volume dies, the volume continues to exist. This is great for the durability of the state.

Modifying the container layer

Before we dive into volumes, let's first discuss what happens if an application in a container changes something in the filesystem of the container. In this case, the changes are all happening in the...

Sharing data between containers

Containers are like sandboxes for the applications running inside them. This is mostly beneficial and wanted, in order to protect applications running in different containers from each other. It also means that the whole filesystem visible to an application running inside a container is private to this application, and no other application running in a different container can interfere with it.

At times, though, we want to share data between containers. Say an application running in container A produces some data that will be consumed by another application running in container B. How can we achieve this? Well, I'm sure you've already guessed it—we can use Docker volumes for this purpose. We can create a volume and mount it to container A, as well as to container B. In this way, both applications A and B have...

Using host volumes

In certain scenarios, such as when developing new containerized applications or when a containerized application needs to consume data from a certain folder produced—say—by a legacy application, it is very useful to use volumes that mount a specific host folder. Let's look at the following example:

$ docker container run --rm -it \
    -v $(pwd)/src:/app/src \
    alpine:latest /bin/sh

The preceding expression interactively starts an alpine container with a shell and mounts the src subfolder of the current directory into the container at /app/src. We need to use $(pwd) (or `pwd`, for that matter), which is the current directory, as when working with volumes, we always need to use absolute paths.

Developers use these techniques all the time when they are working on their application...

Defining volumes in images

If we go for a moment back to what we have learned about containers in Chapter 3, Mastering Containers, then we have this: the filesystem of each container, when started, is made up of the immutable layers of the underlying image, plus a writable container layer specific to this very container. All changes that the processes running inside the container make to the filesystem will be persisted in this container layer. Once the container is stopped and removed from the system, the corresponding container layer is deleted from the system and irreversibly lost.

Some applications, such as databases running in containers, need to persist their data beyond the lifetime of the container. In this case, they can use volumes. To make things a bit more explicit, let's look at a concrete example. MongoDB is a popular open...

Configuring containers

More often than not, we need to provide some configuration to the application running inside a container. The configuration is often used to allow one and the same container to run in very different environments, such as in development, test, staging, or production environments. 

In Linux, configuration values are often provided via environment variables. 

We have learned that an application running inside a container is completely shielded from its host environment. Thus, the environment variables that we see on the host are different from the ones that we see from within a container.

Let's prove that by first looking at what is defined on our host:

1. Use this command:

$ export

On my macOS, I see something like this (shortened):

...
COLORFGBG '7;0'
COLORTERM truecolor
HOME /Users/gabriel
ITERM_PROFILE Default
ITERM_SESSION_ID w0t1p0...

Summary

In this chapter, we have introduced Docker volumes that can be used to persist states produced by containers and make them durable. We can also use volumes to provide containers with data originating from various sources. We have learned how to create, mount, and use volumes. We have learned various techniques of defining volumes such as by name, by mounting a host directory, or by defining volumes in a container image.

In this chapter, we have also discussed how we can configure environment variables that can be used by applications running inside a container. We have shown how to define those variables in the docker container run command, either explicitly, one by one, or as a collection in a configuration file. We have also shown how to parametrize the build process of container images by using build arguments.

In the next chapter, we are going to introduce techniques...

Questions

Please try to answer the following questions to assess your learning progress:

1. How would you create a named data volume with a name—for example, my-products—using the default driver?
2. How would you run a container using the alpine image and mount the my-products volume in read-only mode into the /data container folder?
3. How would you locate the folder that is associated with the my-products volume and navigate to it? Also, how will you create a file, sample.txt, with some content?
4. How would you run another alpine container in to which you mount the my-products volume to the /app-data folder, in read/write mode? Inside this container, navigate to the /app-data folder and create a hello.txt file with some content.
5. How would you mount...

Further reading

The following articles provide more in-depth information:

• Use volumes, at http://dockr.ly/2EUjTml
• Manage data in Docker, at http://dockr.ly/2EhBpzD
• Docker volumes on Play with Docker (PWD), at http://bit.ly/2sjIfDj
• nsenter —Linux man page, at https://bit.ly/2MEPG0n
• Set environment variables, at https://dockr.ly/2HxMCjS
• Understanding how ARG and FROM interact, at https://dockr.ly/2OrhZgx