Understanding Docker Volumes and Bind Mounts

Please note that these are notes for my own learning and may contain inaccuracies.

Premise: What is Docker Volume Persistence (Bind Mounts)?

When you launch a Docker container, it is designed to use volumes within the Docker container by default.^[1] With this setup, data inside the container is lost when the container is restarted.
To prevent this, we synchronize a folder on the host computer with a folder inside the Docker container. This is the concept of decoupling data from the container.

How to Perform Bind Mounts

If you are using Docker Compose, bind mounts are configured in the "compose.yaml" file.
Here is an example:

services:
  web:
    image: [Image to use]:[Image version]
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html
    restart: always

The volume mount is specified with the following syntax:
[Host volume to mount]:[Docker container volume]
In this example, the "html" folder located in the directory where "compose.yaml" resides is bind-mounted to "/usr/share/nginx/html" inside the Docker container.

    volumes:
      - ./html:/usr/share/nginx/html

Benefits of Bind Mounts

1. Data persists through container restarts.
   You may recreate containers using "docker compose down" and "docker compose up -d". If you use bind mounts, the mounted volume is not deleted, and the data remains available for the new container.^[2]

2. Easier management of application settings and files within the Docker container.
   When you mount a host directory for environmental settings used by a Docker container, simply changing a file in that directory will copy the settings to the corresponding directory in the Docker container. This simplifies management by separating concerns: Docker container settings go in "compose.yaml", while settings for applications running inside the container go in the mounted directory's configuration files.

Types of Mounts

There are two types of Docker mounts:

• "Bind mounts" that synchronize specific paths.
• "(Named) Volumes" where management is left to Docker.

Volumes (Named Volumes)

While bind mounts specify a directory on the host, "named volumes" only specify a folder name within Docker's designated folder on the host. Data is also persisted in this case.

Personally, I find named volumes troublesome because you have to go looking for the path when you want to change the contents. I prefer bind mounts because I can create a dedicated Docker working directory, store environment variables and directories I want to bind inside it, and manage everything just by looking at that path.

How to handle Docker containers running without bind mounts

If you are already running Docker and want to avoid losing your data, use the following method. I referred to this article:
https://www.serotoninpower.club/archives/750/#環境

Steps

1. Copy the files you want to manage inside the Docker container to a directory on the host you want to use for management.
   The file copy command is as follows:

   docker cp [Container name or ID]:[Path inside container] [Path on host]
   

2. Modify "compose.yaml" to set up the bind mount with the directory mentioned above.

3. Run "docker compose up -d" to apply the mount settings.

Since you copied the files in step 1, you can recover even if the data isn't reflected correctly in step 3. This acts as a safeguard against overwriting files with empty ones in step 3.
This can also be done by restarting the container with "docker compose down" and "docker compose up -d".

脚注

1. In reality, it seems files are created in a volume on the host where Docker is running, and data is saved there, but I will omit the specific behavior and paths in this article. Note that on Linux, it is saved in a directory on the host, while on Windows or Mac, files are saved on the virtual machine (VM) that runs when Docker itself is started.
   I referred to the following article:
   https://zenn.dev/fdnsy/articles/e2024d73ec2bda

2. Although there are commands to delete the mounted volume itself, it is recommended to establish a situation where you can restore it immediately, such as taking EBS snapshots if you are using AWS EBS volumes. For safety reasons, the commands themselves are not listed here.