Around Go: containers · 3 MIN READ

Container storage: bind mounts, volumes and permissions

Choose a mount for configuration or persistent state and inspect it without deleting data.

A container writable layer usually disappears when its instance is removed. A bind mount maps a host path; a named volume has a lifecycle managed by the container runtime. These local examples use a dedicated fixture and Redis to demonstrate the difference.

Mount a configuration file read-only

A bind mount exposes a host path to the container. --mount makes source, destination and read-only intent explicit. The example assumes ./config.json already exists and the API accepts a -config flag; adapt that flag to your own program.

bash

docker run --rm --name go-api-config \
  --mount "type=bind,source=$PWD/config.json,target=/etc/go-api/config.json,readonly" \
  go-api:dev -config /etc/go-api/config.json

Read the code

Unlike some -v forms, --mount reports a missing source instead of silently making a directory. The image must let its configured user read the file. On macOS, file sharing also crosses the container VM boundary.

Give disposable Redis a separate data volume

Create a dedicated named volume and mount it at Redis data storage. Append-only persistence records writes into that volume; it does not create an off-host backup. The port remains private to this container unless you publish it separately.

bash

docker volume create go-lab-data
docker run -d --name go-lab-redis \
  --mount type=volume,source=go-lab-data,target=/data \
  redis:8-alpine redis-server --appendonly yes
docker exec go-lab-redis redis-cli SET example hello

Read the code

Use an unused container name. SET changes only this exercise Redis key. The volume survives removal of the container; persistence and restore procedures still need testing against the selected Redis version.

Remove an instance without deleting its stored data

Inspect mounts to confirm storage identity, then stop and remove only the Redis instance. The volume remains available for a later explicitly configured container. Avoid prune or rm -v as a casual repair for a service that owns important state.

bash

docker inspect --format '{{json .Mounts}}' go-lab-redis
docker stop go-lab-redis
docker rm go-lab-redis
docker volume inspect go-lab-data

Read the code

The final command should still find the named volume. A missing container is expected after rm. Delete the exercise volume later only when you intentionally no longer need its data and have checked its exact name.

TAKE THIS WITH YOU

Container replacement, volume deletion and backup are separate operations. Use explicit mount paths, account for the service UID and verify storage identity before changing the lifecycle of stateful workloads.

Check your understanding

What normally happens to a named volume after docker rm without volume-removal flags?

Go to the source

Progress stays in this browser. No account needed.