目次 — 知りたいところから読む
入力を変えて確かめる
実験パネルを開き、実行を押すとPythonを読み込みます。停止と初期値へのリセットができます。結果はこの端末内で計算します。Pythonのインストールは不要です。
下にあるローカル実行の手順は、配布ソースを再現するための任意の手順です。ブラウザ実験には不要です。
前提と読み方
前提知識 Dockerのrunとコンテナの基本。Linuxコンテナを想定する。
実装・実験 · 本文の条件と確認項目に沿って、計算例や比較表を追う。
ブラウザで保存先の寿命を確かめる
上のパネルは、保存領域の所有者とコンテナの接続を状態図で表します。Dockerの実行や実ファイルへのアクセスは行いません。 保存先と操作を変え、段階ごとの図・表を比較してください。下のDockerコマンドは、別途実環境で確かめたい場合の手順です。
毎回、同じ準備済み状態から始めます。選択した保存先の /data/note.txt に saved、コンテナの書込層の /tmp/note.txt に temporary がある状態です。イメージの /data は空で、アプリ起動時にもファイルは作りません。mountの読取専用設定は準備後に適用します。最後に別ファイル /data/probe.txt の作成を試みます。この新しい印は元のnoteを復元しません。
named volumeは既定のproject名付き alpha_data、external volumeは用意済みの固定名 shared_data、bind mountはdaemonホスト上の固定絶対パス /srv/demo-data を使います。後二つはproject変更後も同じ保存先です。volumeの独自の name、anonymous volume、tmpfs、driver設定、イメージから空volumeへの初期コピー、読取専用以外の権限、別コンテナとの共有は扱いません。
「project変更」はalphaをvolume削除なしでdownし、betaを起動する操作です。「alphaへ戻る」はさらにbetaをdownしてalphaを起動します。空の beta_data へ接続すると、alpha_data のnoteが残っていても読めなくなります。図では「残存」と「現在の接続から読める」を分けます。読取専用はmountにだけ適用し、書込層を選んだ場合は無視します。
書込層の再起動と再作成、named volumeのdownとdown --volumes、project変更と復帰、削除操作でのnamed/externalの違いを比較してください。削除のシナリオには再起動までを含みます。指標は1が「はい」、0が「いいえ」という結果で、確率や復旧保証ではありません。
規則は2026-09-20に Dockerの保存領域、volume、bind mount、Compose down、volume名とexternalで確認しました。実Engineとの実行照合ではなく、資料に基づく状態モデルです。ホスト故障やアプリ・DBの整合性は扱いません。復元Labで、保存とは別の復元確認へ進めます。
コンテナは作り直せても、データが自動的に戻るとは限らない。保存先の種類と、削除する対象の境界を理解する必要がある。本記事はDocker公式資料を確認した演習手順であり、本番のコンテナやボリュームで実験を実施したものではない。確認日は2026-09-07。
三つの保存場所
| 保存先 | 管理する境界 | コンテナを削除した後 |
|---|---|---|
| 書込層 | そのコンテナ | その層の変更は失われる |
| named volume | Dockerの独立した保存領域 | volumeを削除しなければ残る |
| bind mount | Dockerホストの指定パス | ホスト側のファイルとして残る |
単なるコンテナの停止・再起動と、削除して再作成することは違う。Volumesで寿命を確認できる。anonymous volumeは名前を自分で指定しない形式で、--rmなどによる削除条件がnamed volumeと異なるため、この演習では使わない。
演習用のnamed volumeを作る
Docker Engine、Linuxコンテナ、alpine:3.21を使う例である。Dockerのバージョンと実際に取得したイメージのダイジェストを記録する。タグは将来同じ内容とは限らない。duskcoil-lifetime-demoという名前が未使用であることをdocker volume lsで確認してから実行する。
docker volume create duskcoil-lifetime-demo
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data alpine:3.21 sh -c 'echo saved > /data/note.txt; echo temporary > /tmp/note.txt'
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data,readonly alpine:3.21 sh -c 'cat /data/note.txt; test ! -e /tmp/note.txt'
期待結果は/data/note.txtからsavedを読めて、2個目のコンテナの/tmp/note.txtは存在しないこと。最初の--rmでコンテナを削除してもnamed volumeは残る。2個目は読み取り専用で接続する。既存のサービス名や本番データへ置き換えて試す演習ではない。
bind mountはホストのどこを指すか
Bind mountsでは、パスはDocker daemonが動くホスト側を指す。リモートのDockerを操作している場合、手元のPCのファイルとは限らない。Docker DesktopでもVMとの境界を意識する。
docker inspect <コンテナ名>のMountsでType、Source、Destination、RWを確認する。見えている/dataが想定したディレクトリと違えば、アプリの設定を直す前に接続を直す。既存ファイルがあるディレクトリへマウントすると、その下のファイルが見えなくなることもある。「消えた」と「別のものが上に見えている」を区別する。
Composeの削除操作を読み分ける
docker compose downとdocker compose down --volumesは同じではない。後者はComposeで定義したnamed volumeなども削除対象にする。external volumeは別管理である。downの公式リファレンスで対象を確認する。
また、Composeのプロジェクト名を変えると、別の名前のvolumeが作られて初期状態に見えることがある。古いデータが壊れたと判断する前に、実際のvolume名を調べる。演習で作ったvolumeの後片付けは、内容が不要と確認した後にその名前だけを指定して行う。全volumeを対象にした一括削除は手順に含めない。
永続化はバックアップではない
volumeはコンテナの寿命からデータを分けるが、同じディスクの故障やアプリによる誤削除から守るとは限らない。別の保存先へのコピーと復元確認が必要である。データベースを動かしたままファイルをコピーすると整合しない場合があるため、アプリのバックアップ機能や停止・スナップショット条件を確認する。
イメージやComposeだけを保存しても、利用者の投稿やDBが戻るとは限らない。逆にDBだけあっても、必要な設定、鍵、バージョンがなければ復元できないことがある。復元先でアプリが読めるかを確認して初めて、保存の手順が具体的になる。
自分のサービスで作る台帳
各サービスについて「コンテナ内の保存先／Mountsの実体／所有者と権限／バックアップ方法／復元先／最後に復元を試した日」を記録する。まずこの台帳で保存先を確認し、自宅サーバーの復元演習へ進むと、失うと困るものを漏らしにくい。
現在の項目 · 1 / 3 · 雑記
コメント
コメントの投稿にはログインが必要です
まだコメントはありません。