7.5 Real-World Examples

Simple Database Persistence

When you run a database like PostgreSQL or MySQL in a container, the container’s writable layer is temporary. If you restart or recreate the container, all data inside that layer disappears. To keep the data, you attach a volume at the path where the database stores its files.

A typical example is a PostgreSQL container that uses a named volume. You map the internal data directory, often /var/lib/postgresql/data, to a volume name. The container can then be removed and recreated, but the volume remains and still contains all tables and records. This is especially important in development environments where you rebuild containers frequently but do not want to lose your test data after every change.

For local development, this approach gives you three benefits. You keep your database state between container runs, you can quickly reset it by removing the volume only when you choose, and you separate your database data from the container lifecycle so you are not afraid to experiment with container changes.

Local Development with Application Code

Another common real world case is mapping your application source code from your host machine into a container. You often achieve this with a bind mount, not a named volume, because you want the container to see live changes to files directly from your working directory.

For example, a web framework that supports hot reloading can detect file changes and reload the server automatically. Your editor runs on the host, your code stays in your project folder, and the container simply uses that folder as if it were its own. This pattern is popular in JavaScript, Python, Ruby, and PHP development, where frequent code edits and quick feedback are part of the normal workflow.

The separation is clear. Persistent or shared configuration files and user generated data might live in named volumes, while rapidly changing source files are typically bind mounted from the host. This gives a mix of stability for important data and flexibility for development.

Sharing Data Between Multiple Containers

Many applications consist of several containers that need access to the same files. A reporting service might need to read logs produced by a web server, or an application container and a backup container might both need access to database files.

In these scenarios, the shared directory inside the containers is backed by a single volume. Each container mounts that volume at its own path, which can be the same path or different paths as long as they refer to the same volume name. The web server writes files, the other container reads them, but neither needs to know about the host file system.

This pattern appears in backup strategies as well. Instead of connecting directly to the database over the network, a backup container might mount the same data volume as the database container. It can then create snapshots of those files or sync them to remote storage according to your backup schedule.

Configuration and Environment Specific Data

Volumes can hold configuration and runtime data that varies between environments but should not be rebuilt into the image. In a staging or production setup, you might mount a volume that contains configuration files, SSL certificates, or application specific settings.

One common pattern is to package an application image that contains only generic defaults. Then, during deployment, you attach a volume that contains the actual configuration for that environment. The same image can then be used in multiple stages, such as development, staging, and production, with each stage injecting its own configuration through volumes.

You can also use this method to manage secrets that cannot be stored in the image itself. Certain deployment platforms provide specialized volume like constructs to inject secrets files into containers. Even in simple setups, a volume that holds sensitive configuration keeps it separate from the container image, and you can rotate or update it without rebuilding or republishing the image.

Caching and Build Artifacts

Volumes are also useful for caching intermediate data or build artifacts. For instance, when building a large JavaScript project inside a container, the package manager downloads many dependencies that do not change often. If every container run starts with an empty file system, you would download them again each time, which slows down your workflow.

By attaching a volume at the directory where dependencies are stored, such as node_modules or a language specific cache directory, you keep these files between container runs. The same idea applies to compiled object files, test results, and any other expensive intermediate output that you want to reuse.

In continuous integration environments, this can significantly reduce build times. The build job mounts a volume that stores dependency caches, the job completes faster, and the volume persists for the next run. The image stays clean because it does not carry build outputs, while the volume provides the speed benefit.

Logs and Auditing

In some setups, logs are written to files inside a container. While container logging can be handled by default mechanisms, there are real world cases where file based logs are required for regulatory auditing, integration with existing tools, or special parsing.

Mounting a volume at the location where the application writes its log files ensures that the logs survive container restarts and can be collected by external agents. A log forwarder container can mount the same volume, read the log files, and ship them to a centralized logging system without modifying the primary application container.

This separation makes it easier to change how you handle logs without changing the application itself. You can add or swap log processing containers, rotate logs, and implement retention policies through volumes and external tooling.

Data Migration and Transfer

Volumes can also be used as temporary storage when migrating data between versions of an application or between different containers. A typical pattern is to run a one time migration container that reads from one volume and writes to another.

For example, when upgrading a database major version, you might mount the old data volume and a new empty volume into a migration container. That container runs the upgrade tools which read from the old volume and produce a transformed layout in the new volume. After the migration is complete, you can attach the new volume to the upgraded database container.

This approach keeps migrations repeatable and isolated. You do not modify the original data in place until you are confident in the new layout, and you can rerun the migration process by reattaching the volumes in the same way.

Combining Volumes with Orchestration Tools

In larger real world deployments, volumes are often created and attached by orchestration tools, not by manual commands. For example, a multi container application definition can declare named volumes and specify which services use them. When you bring the application up, the orchestrator creates those volumes automatically and assigns them to the appropriate containers.

This works for the patterns described above, such as persistent databases, shared data directories, and configuration volumes. The difference is that the definition is stored as code in a configuration file, so anyone can recreate the same setup on another machine. Volumes then become a first class part of your application architecture, not just an ad hoc workaround to avoid losing data.

Even though the orchestration layer adds features on top, the core behavior remains the same. Volumes provide data persistence, separation from the container lifecycle, and controlled sharing of files between containers in a consistent, repeatable way.