Dockerを学び始めると必ず出てくる「イメージ(image)」「コンテナ(container)」「ボリューム(volume)」。
言葉だけを聞くととても抽象的で混乱しがち。
名前は知っていても、何がどこにあり、何が消えて、何が残るのかを曖昧なまま使っている人も少なくありません。
ここでは3つの違いと関係性を一気に整理します。
ここでは「はじめてDockerに触れる人」でも理解できるよう、「筋の通ったDockerの流れ」を解説します。
30秒でわかる Docker イメージ・コンテナ・ボリュームの違い
- Dockerイメージ：アプリ実行に必要なファイルや設定をまとめたテンプレート（書き換え不可）
- Dockerコンテナ：イメージをもとに動く「実行中のプロセス」（書き込みOK・削除で消える）
- Dockerボリューム：コンテナ削除後も残るデータ用ストレージ（永続化）
図解で理解する3つの関係（テレビゲームの比喩）
- イメージ＝ゲームソフト（中身は変わらない）
- コンテナ＝プレイ画面（動いている実体）
- ボリューム＝セーブデータ（電源を切っても残る）
1. Dockerイメージとは「アプリが動くための完成済みの設計図」
イメージに含まれるもの
Dockerイメージとは、アプリを動かすために必要なものを丸ごとパッケージ化した 完成済みテンプレートのようなものです。
中には以下が含まれます。
- アプリケーションのコード
- ランタイム（例：Node.js、Python など）
- 依存ライブラリ
- 環境変数
- 設定ファイル
つまり「このイメージを使えば、誰の環境でも同じ状態でアプリが動く」という保証を持っています。
イメージを変更できない理由｜読み取り専用だから
Dockerイメージは読み取り専用レイヤー（Read-Only Layer）で構成されています。
そのため、イメージ自体を直接書き換えることはできません。
もし内容を変更したい場合は：docker build
などで 新しいイメージを再ビルドする必要があります。
よく使うイメージ操作コマンド
docker pull nginx:latest # イメージを取得 docker images # イメージ一覧 docker build -t myapp:v1 . # イメージをビルド
2. Dockerコンテナとは「イメージから動く実体のプロセス」
コンテナの正体はただのプロセス
Dockerコンテナとは、イメージを基に動く実行プロセスです。
アプリが実際に動いているのは、このコンテナの中。
ポイントは以下：
- コンテナ = イメージを基に起動した実体
- 起動している間だけ動作し、停止すると状態はほぼ消える
書き込みレイヤーとは何か
コンテナが動くとき、イメージの上に一時的な書き込み可能なレイヤーが追加されます。
- ファイルの変更
- ログの生成
- 一時データ
などは、この書き込みレイヤーに保存されます。
ただし、このレイヤーはコンテナ削除とともに完全に消滅します。
そのため「データ永続化」が必要な場合は次章のボリュームが必須です。
よく使うコンテナ操作コマンド
docker run -d --name web nginx # コンテナ起動 docker ps -a # コンテナ一覧 docker stop web # 停止 docker rm web # 削除
3. Dockerボリュームとは「コンテナ削除でも消えない外部ストレージ」
データが残る仕組み
ボリュームとは、コンテナとは別にホスト側へデータを保存する外部記憶領域です。
- コンテナを削除 → 書き込みレイヤーは消える
- しかしボリュームはホスト側にあるので データは残る
つまり、データベースのデータなど「消えては困るもの」の保存に必須の仕組みです。
ボリュームの種類
| 種類 | 特徴 |
|---|---|
| named volume | Dockerが管理する永続データ領域。最も一般的。 |
| bind mount | ホスト側の特定フォルダとコンテナを直接同期。開発環境で便利。 |
| tmpfs | メモリ上に保存する高速な一時領域。再起動で消える。 |
ボリュームを使う実例
docker run -d \ -v mydata:/var/lib/mysql \ --name db mysql:8
この例では「mydata」というボリュームをMySQLのデータ保存先にマウントしています。
ボリューム関連でよく起きるエラー
- パーミッションエラー（権限不足）
- ホスト側パスの指定ミス（bind mount時）
3つの違いは「何が保存され、いつ消えるか」
| 種類 | 役割 | 書き換え可否 | コンテナ削除後 |
|---|---|---|---|
| イメージ | アプリの設計図 | × 読み取り専用 | もちろん残る |
| コンテナ | 実行される実体 | △ 書き込みレイヤーのみ | 消える |
| ボリューム | 永続データ保存 | ○ | 残る |
この仕組みを理解することで、Docker環境の設計が圧倒的にスムーズになります。
3つの違いを比較（役割・状態・ライフサイクル）
実務でどう使う？流れで理解
## 1. Dockerfile → イメージビルド docker build -t sample-app:v1 . ## 2. イメージ → コンテナ起動 docker run -d --name app sample-app:v1 ## 3. データ → ボリュームで永続化 docker run -d \ -v appdata:/usr/src/app/data \ --name app2 sample-app:v1
現場でよくある落とし穴と対策
コンテナ内に保存して消える問題
改善策：ボリュームを必ず使う。アプリの保存先をボリュームへ変更。
ボリュームのパーミッション問題
ホスト側のユーザーID・グループIDと差異が原因になることが多い。
イメージ肥大化
不要ファイル削除、マルチステージビルドの利用が効果的。
よくある質問（FAQ）
Q：イメージとコンテナの違いは？
A：イメージは動かないテンプレート。コンテナはその実行体。
Q：コンテナの中に保存したデータは残る？
A：残りません。ボリュームを使う必要があります。
Q：ボリュームを削除しないとどうなる？
A：データが蓄積し続けディスク圧迫の原因になります。
まとめ
- アプリの土台はイメージで作る
- 動作はコンテナで行う
- データはボリュームに保存する
- 書き込みは「どこに保存されるか」必ず確認する
- 永続化が必要なら必ず-vでマウントする
