Getting Started with Container Volumes and Persistent Storage

This post is part of a series on core cloud native concepts, challenges, and best practices, organized into short, manageable exercises and explainers. These lessons assume a basic familiarity with the Linux command line and a Unix-like operating system — beyond that, you don’t need any special preparation to get started.

Table of Contents

1. What is a Container?
2. Creating, Observing, and Deleting Containers
3. Build Image from Dockerfile
4. Using an Image Registry
5. Volumes and Persistent Storage ←You are here

Persistent storage for containers

When technologists talk about why containers are useful for large-scale enterprise applications, they will often describe containers as “ephemeral” — a word that means short-lived, here and then gone.

At this point, we should have a firmer sense of why the ephemerality of containers is useful — we can quickly and very efficiently spin up a container as needed, only transferring data for image layers not shared by other containers. This quality enables many of the systems we now describe as “cloud native,” including container orchestrators like Kubernetes.

But in the midst of all this transiency, there is a complication: most applications store persistent data for later use. Even simple websites — which can be built on static web servers with no need for persistent storage — are often created with content management systems like WordPress, and those content management systems use databases to save user logins, draft posts, and other data.

If we want to containerize an application such as WordPress, we need a way to create a persistent data store that is independent of any given container, so our ephemeral containers — created and destroyed as needed — can access, utilize, and update the same data.

With Docker, those persistent data stores are called volumes. By default, volumes are directories located on the host filesystem, within a specific directory managed by the Docker engine — but they can also be defined in remote locations such as cloud storage.

What about bind mounts?

Docker provides another way for containers to access data on the host filesystem: bind mounts. This allows the container to read and write data anywhere on the host filesystem. This can be useful for experimentation on your local machine, but there are many reasons to prefer volumes for general usage: they are manageable with the Docker command line interface, they have a more precisely defined scope, and they are more suited to cloud native architectures. For these reasons, we will focus on volumes here.

A given volume may be mounted to multiple containers at once, in either read-write or read-only mode, and will persist beyond the closure of a particular container. If you’re using Docker Desktop on macOS or Windows, you will find that volumes have their own management tab.

Now let’s try creating a volume and mounting it to multiple containers.

Exercise: Opening the first volume

You can follow a version of this lesson’s exercise in the video below.

To follow the text-based tutorial, read the rest at the Mirantis blog.