コンテナの書き込みは永続保存ではない
コンテナの中で作ったファイルは、コンテナの書き込み可能な層に保存されます。しかしコンテナを削除すると、その層も一緒に失われます。データベースのファイルやアップロード画像をコンテナ内だけに置くと、作り直したときに消える可能性があります。
削除するとデータが消える例COMMAND
docker run --name temp alpine sh -c 'echo lost > /data.txt'
docker rm -f temp
docker run --rm alpine test -e /data.txt; echo $?実行結果OUTPUT
1最後の1は、別のコンテナには/data.txtが存在しないことを表します。必要なデータは、コンテナのライフサイクルと別に管理します。
バインドマウントでソースコードを共有する
ホストのディレクトリをコンテナ内へマウントする方法がバインドマウントです。現在のディレクトリのindex.htmlをNginxの公開ディレクトリへ読み取り専用でマウントしてみます。
ホストのHTMLを表示するCOMMAND
docker run -d --name bind-web -p 8080:80 \
--mount type=bind,src="$PWD",dst=/usr/share/nginx/html,readonly \
nginx:alpineWindows PowerShellでは$PWDの扱いが異なるため、Docker Desktopの案内に合わせて絶対パスを指定します。バインドマウントは編集したファイルをすぐ反映しやすく、開発中のソースコードに向いています。一方、ホストのパス構成に依存するため、チームで共有する設定には注意が必要です。
名前付きボリュームを使う
Dockerが管理する保存領域を名前付きボリュームと呼びます。ホスト上の具体的なパスを意識せず、データをコンテナの外へ分離できます。
ボリュームを作って利用するCOMMAND
docker volume create study-data
docker run --rm --mount source=study-data,destination=/data \
alpine sh -c 'echo saved > /data/message.txt'
docker run --rm --mount source=study-data,destination=/data \
alpine cat /data/message.txt実行結果OUTPUT
study-data
saved2つ目のコンテナは1つ目とは別ですが、同じstudy-dataをマウントしているためファイルを読めます。docker volume lsで一覧、docker volume inspect study-dataで詳細を確認できます。
保存方法を使い分ける
- コンテナの書き込み:一時ファイルや再生成できるキャッシュ向け
- バインドマウント:開発中のソースコードや設定をホストと共有
- 名前付きボリューム:データベースなど、コンテナを作り直しても残したいデータ向け
ボリュームを使ってもバックアップが不要になるわけではありません。重要なデータはバックアップと復元を実際に試し、docker compose down -vのような削除操作がどこまで影響するかを理解してから実行します。