Docker Storage Mounts and Best Practices

kai wen ng — Sat, 25 Jul 2026 04:46:00 +0000

To avoid bloated Docker images and containers, it is a best practice to store persistent data outside the container's writable layer by using storage mounts.
Mounting allows a Docker container to access files from external storage locations. Depending on the mount type, the container can read, write, and sometimes execute files without storing them inside the container image.
Docker provides three main types of mounts:

1. Docker Volume Mounts

Docker volumes are the recommended method for storing persistent application data.
Volumes are managed directly by Docker and are independent of the container lifecycle. They can be listed using:

docker volume ls

A volume can be attached to multiple containers, allowing containers to share persistent data without recreating or copying data between containers.
Example:

docker run -v my_volume:/data my_container

Advantages:

Managed by Docker
Portable across containers
Survives container removal
Better isolation compared to directly mounting host directories

2. Bind Mounts (Host File System Mounts)

A bind mount maps a directory or file from the host machine directly into the container.
Example:

docker run -v /host/directory:/mnt my_container

The container can directly access the host directory through /mnt.

Advantages:

Allows direct access to host files
Useful for development environments
Enables live code updates without rebuilding images

Common use cases:

Mounting source code during development
Sharing configuration files
Accessing hardware devices or system resources

3. tmpfs Mounts (Linux Only)

tmpfs mounts store data directly in the host machine's RAM instead of disk storage.
Example:

docker run --tmpfs /tmp my_container

Since the data exists only in memory:

No data is written to the Docker writable layer
Data disappears when the container stops
Disk persistence is not possible

This makes tmpfs suitable for temporary or sensitive data, such as:

Credentials
Temporary files
Runtime secrets
Cryptographic keys

Advantages:

Faster access due to RAM storage
Reduces disk writes
Prevents sensitive data from being stored permanently

Limitations:

Available mainly on Linux systems
Data is lost after container termination
Limited by available memory

Using the appropriate mount type helps keep Docker images lightweight, improves data management, and provides better control over persistence and security.

Docker as Cross Compilation Platform

kai wen ng — Fri, 24 Jul 2026 12:58:26 +0000

Having various dependencies when setting up a software development environment can be frustrating, especially when dealing with legacy C/C++ systems that require specific compiler versions, libraries, and outdated operating systems.

Using Docker as a cross-compilation and development environment can significantly simplify this process.

The main advantages are:

Isolation of dependencies

Docker provides an isolated environment where required compilers, libraries, headers, and system packages can be installed without affecting the host machine. This avoids dependency conflicts and keeps the existing development environment clean.

Reproducible legacy environments

Docker allows developers to recreate older Linux distributions and software environments that match production systems. For example, an Ubuntu 20.04 container can be used to build applications that depend on older libraries or toolchains, even if the host machine is running a newer operating system.

Explicit environment definition

By defining dependencies through Dockerfiles and container configurations, the required build environment becomes clear, reproducible, and easier to maintain. New developers can recreate the same environment without manually installing every dependency.

With this approach, I created a lightweight Docker-based compilation platform for a legacy CGI C/C++ system.

The first step was creating a minimal Docker image based on Ubuntu 20.04. Required header files, compilers, development tools, and libraries were then installed inside the container.

Initially, I considered copying the entire source code and website files into the Docker image and compiling everything during container runtime. However, this approach introduced several issues:

The Docker image became unnecessarily large.
Every source code change required rebuilding the image.
The development cycle became slower due to repeated compilation and image creation.

Instead, I separated the development environment from the source code by mounting the project files into the running container.

The workflow became:

Build the Docker image containing only the required compilation environment and dependencies.
Mount the source code and website resources into the container.
Enter the running container:

sudo docker exec -it <container_name> /bin/bash

Navigate to the mounted project directory.
Run the required compilation commands:

make all

or any other installation/build command required by the project.

With this setup, the host machine does not need to contain the legacy dependencies or libraries. The Docker container provides the complete build environment, while the source code remains directly accessible from the host through volume mounting.

This provides several practical benefits:

Source code changes are immediately reflected inside the container.
No container rebuild is required after every code modification.
No Docker image recompilation is needed during development.
The legacy CGI application can be compiled and updated quickly while maintaining a clean host environment.

This approach effectively turns Docker into a portable legacy development workstation, allowing old C/C++ systems to be maintained and modified using modern development workflows.

DEV Community: kai wen ng

Docker Storage Mounts and Best Practices

1. Docker Volume Mounts

2. Bind Mounts (Host File System Mounts)

3. tmpfs Mounts (Linux Only)

Docker as Cross Compilation Platform