STEP 6：Dockerイメージの仕組み

🎯 1. イメージとコンテナの違い

1-1. 基本的な概念

Dockerを使う上で最も重要な概念が、イメージとコンテナの違いです。
この2つは混同しやすいですが、全く異なるものです。

📦 料理で例えると…

イメージ = レシピ（設計図）
コンテナ = 実際に作った料理

1つのレシピ（イメージ）から、何個でも料理（コンテナ）を作れます。
料理を食べ終わって捨てても、レシピは残ります。
同じレシピから、また同じ料理を作れます。

1-2. イメージとコンテナの特徴

項目	イメージ	コンテナ
定義	アプリケーションの「設計図」「テンプレート」	イメージから作られた「実行環境」
状態	静的（動いていない）	動的（実際に動いている）
変更	読み取り専用（変更不可）	読み書き可能（変更可能）
数	1つのイメージから複数のコンテナを作成可能	各コンテナは独立した環境
保存場所	ディスク上に保存	メモリ上で実行（データはディスクにも）
作成方法	docker pull または docker build	docker run または docker create

1-3. 具体例で理解する

実際にコマンドを実行して、イメージとコンテナの関係を確認してみましょう。

# 1. イメージをダウンロード（1つのイメージ）
docker pull nginx

        📝 コマンドの意味
        docker pull ：Docker Hubからイメージをダウンロードするコマンド
nginx ：ダウンロードするイメージ名

    

# 2. この1つのイメージから3つのコンテナを作成
docker run -d –name web1 -p 8001:80 nginx
docker run -d –name web2 -p 8002:80 nginx
docker run -d –name web3 -p 8003:80 nginx

# 3. イメージの数を確認（1つだけ）
docker images | grep nginx

REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest a6bd71f48f68 2 weeks ago 187MB

# 4. コンテナの数を確認（3つある）
docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a1b2c3d4e5f6 nginx “/docker-entrypoint.…” 10 seconds ago Up 9 seconds 0.0.0.0:8001->80/tcp web1 b2c3d4e5f6a7 nginx “/docker-entrypoint.…” 8 seconds ago Up 7 seconds 0.0.0.0:8002->80/tcp web2 c3d4e5f6a7b8 nginx “/docker-entrypoint.…” 5 seconds ago Up 4 seconds 0.0.0.0:8003->80/tcp web3

✅ 確認ポイント

イメージは1つだけなのに、コンテナは3つあります。
1つのイメージから、何個でもコンテナを作成できることがわかります。

1-4. イメージとコンテナの関係図

【イメージとコンテナの関係】

          Docker Hub（インターネット上のリポジトリ）
                    ↓ docker pull
    ┌─────────────────────────────────────┐
    │  ローカルマシン                       │
    │                                     │
    │   ┌─────────────────┐               │
    │   │  nginx イメージ   │ ← 読み取り専用  │
    │   │  （設計図）        │   のテンプレート │
    │   └─────────────────┘               │
    │        ↓  ↓  ↓  docker run         │
    │   ┌────┐ ┌────┐ ┌────┐             │
    │   │web1│ │web2│ │web3│ ← 実行中の   │
    │   │8001│ │8002│ │8003│   コンテナ   │
    │   └────┘ └────┘ └────┘             │
    │                                     │
    └─────────────────────────────────────┘

・コンテナを削除しても、イメージは残る
・イメージを削除すると、新しいコンテナは作れない
・既存のコンテナは、イメージを削除しても動き続ける

1-5. コンテナを削除してもイメージは残る

この関係を実際に確認してみましょう。

# コンテナを全て停止・削除
docker stop web1 web2 web3
docker rm web1 web2 web3

# コンテナは0個になった
docker ps -a | grep nginx

# 何も表示されない（コンテナは全て削除された）

# でもイメージは残っている
docker images | grep nginx

REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest a6bd71f48f68 2 weeks ago 187MB

💡 重要なポイント

コンテナを削除しても、イメージは残ります。
イメージが残っている限り、いつでも新しいコンテナを作成できます。
これがDockerの大きなメリットの一つです。

🧱 2. レイヤー構造の理解

2-1. レイヤーとは？

Dockerイメージは、複数の「層」（レイヤー）が重なってできている構造を持っています。
これがDockerの効率性の秘密です。

🎂 ミルクレープで例えると…

ミルクレープは、薄いクレープ生地とクリームが交互に重なってできていますよね。

1層目：クレープ生地
2層目：クリーム
3層目：クレープ生地
4層目：クリーム
…

Dockerイメージも同じように、命令ごとに層が重なってできています。

2-2. レイヤー構造の具体例

Nginxイメージがどのようなレイヤーで構成されているか見てみましょう。

【Nginxイメージのレイヤー構造】

┌─────────────────────────────────────┐
│ Layer 6: CMD [“nginx”, “-g”, …]   │ ← 起動時のコマンド
├─────────────────────────────────────┤
│ Layer 5: EXPOSE 80                   │ ← ポート公開の宣言
├─────────────────────────────────────┤
│ Layer 4: Nginx設定ファイル            │ ← 設定ファイル
│          /etc/nginx/nginx.conf       │
├─────────────────────────────────────┤
│ Layer 3: Nginxバイナリ               │ ← アプリケーション本体
│          /usr/sbin/nginx             │
├─────────────────────────────────────┤
│ Layer 2: 必要なライブラリ             │ ← 依存関係
│          libssl, libpcre, zlib       │
├─────────────────────────────────────┤
│ Layer 1: Debian（ベースOS）          │ ← 土台となるOS
│          /bin, /usr, /etc, /lib      │
└─────────────────────────────────────┘

→ これらが重なって「nginx」イメージになる
→ 各レイヤーは読み取り専用

2-3. docker historyでレイヤーを確認

docker historyコマンドで、イメージのレイヤー構造を確認できます。

docker history nginx

        📝 コマンドの意味
        docker history ：イメージの作成履歴（レイヤー情報）を表示するコマンド
nginx ：確認したいイメージ名

    

IMAGE CREATED CREATED BY SIZE COMMENT a6bd71f48f68 2 weeks ago CMD [“nginx” “-g” “daemon off;”] 0B buildkit… <missing> 2 weeks ago STOPSIGNAL SIGQUIT 0B buildkit… <missing> 2 weeks ago EXPOSE map[80/tcp:{}] 0B buildkit… <missing> 2 weeks ago ENTRYPOINT [“/docker-entrypoint.sh”] 0B buildkit… <missing> 2 weeks ago COPY 30-tune-worker-processes.sh … (省略) 4.62kB buildkit… <missing> 2 weeks ago COPY 20-envsubst-on-templates.sh … (省略) 3.02kB buildkit… <missing> 2 weeks ago COPY 15-local-resolvers.envsh … (省略) 336B buildkit… <missing> 2 weeks ago COPY 10-listen-on-ipv6-by-default.sh (省略) 2.12kB buildkit… <missing> 2 weeks ago COPY docker-entrypoint.sh … (省略) 1.62kB buildkit… <missing> 2 weeks ago RUN /bin/sh -c set -x … (省略) 61.4MB buildkit… <missing> 2 weeks ago ENV DYNPKG_RELEASE=1~bookworm 0B buildkit… …

✅ 確認ポイント

CREATED BY：そのレイヤーを作成したコマンド（Dockerfileの命令）
SIZE：そのレイヤーのサイズ（0Bはメタデータのみ）
サイズが大きいレイヤーは、ファイルが追加されたレイヤー

2-4. レイヤー構造の3つのメリット

1️⃣ ストレージ効率

同じレイヤーは共有される。
10個のイメージがUbuntuベースでも、Ubuntu部分は1回だけ保存。

2️⃣ 高速ダウンロード

既にあるレイヤーは再ダウンロード不要。
差分だけをダウンロード。

3️⃣ 効率的ビルド

変更されていないレイヤーはキャッシュから再利用。
ビルド時間を大幅短縮。

4️⃣ バージョン管理

レイヤー単位で変更履歴を追跡。
問題発生時の原因特定が容易。

2-5. レイヤー共有の具体例

同じベースを使う複数のイメージをダウンロードして、レイヤー共有を確認してみましょう。

# Python 3.10と3.11をダウンロード
docker pull python:3.10
docker pull python:3.11

2つ目のイメージをダウンロードする際、共通のレイヤーは「Already exists」と表示され、再ダウンロードされません。

# python:3.11をダウンロードした時の出力例 3.11: Pulling from library/python a2abf6c4d29d: Already exists ← すでにある（共通レイヤー） e1769f35a42a: Already exists ← すでにある（共通レイヤー） 33a59cfee47c: Already exists ← すでにある（共通レイヤー） 7f8c3e5b4d2a: Pull complete ← 新しいレイヤー 8ed8ab6290fa: Pull complete ← 新しいレイヤー Digest: sha256:abc123… Status: Downloaded newer image for python:3.11

💡 「Already exists」の意味

「Already exists」は、そのレイヤーが既にローカルに存在することを意味します。
python:3.10をダウンロードした時にベースのDebianレイヤーが保存されていたので、
python:3.11ではそのレイヤーを再利用しています。

📝 3. Copy-on-Write（コピーオンライト）

3-1. Copy-on-Writeとは？

Copy-on-Write（CoW）は、Dockerがコンテナ内のファイル変更を効率的に扱うための仕組みです。

📚 図書館の本で例えると…

図書館の本（イメージ）は、みんなで共有して読みます。
でも、本に直接メモを書き込むことはできません。

もしメモを書きたい場合は、そのページだけコピーして、
コピーした紙にメモを書きます。

これがCopy-on-Write：変更する時だけコピーを作る仕組みです。

3-2. Copy-on-Writeの動作

【Copy-on-Writeの動作】

① コンテナ起動時
┌─────────────────────────────────────┐
│ Container Layer（読み書き可能）      │ ← 空の状態
│ （まだ何もない）                     │
├─────────────────────────────────────┤
│                                     │
│  イメージのレイヤー（読み取り専用）    │
│  ・/etc/nginx/nginx.conf            │
│  ・/usr/sbin/nginx                  │
│  ・/var/log/nginx/                  │
│                                     │
└─────────────────────────────────────┘

② ファイルを変更する時
┌─────────────────────────────────────┐
│ Container Layer（読み書き可能）      │
│ ・/etc/nginx/nginx.conf ← コピーして │
│  （変更されたファイル）     変更！    │
├─────────────────────────────────────┤
│                                     │
│  イメージのレイヤー（読み取り専用）    │
│  ・/etc/nginx/nginx.conf ← 元のまま  │
│  ・/usr/sbin/nginx                  │
│  ・/var/log/nginx/                  │
│                                     │
└─────────────────────────────────────┘

→ イメージのファイルは変更されない
→ コンテナ固有の変更だけがContainer Layerに保存
→ コンテナを削除すると、Container Layerも削除

3-3. Copy-on-Writeのメリット

✅ ディスク効率

変更したファイルだけが複製される。
1GBのイメージでも、10バイトの設定ファイルを変更するなら、10バイトだけ追加で保存。

✅ 高速起動

コンテナ起動時にイメージ全体をコピーする必要がない。
だから数秒で起動できる。

3-4. 実際に確認してみよう

コンテナ内でファイルを変更して、その変更がイメージに影響しないことを確認します。

# 1. Nginxコンテナを起動
docker run -d –name cow-test -p 8080:80 nginx

# 2. コンテナ内でファイルを変更
docker exec cow-test sh -c “echo ‘Hello from Container!’ > /usr/share/nginx/html/index.html”

# 3. 変更を確認（ブラウザまたはcurl）
curl http://localhost:8080

Hello from Container!

# 4. コンテナを削除
docker rm -f cow-test

# 5. 新しいコンテナを起動
docker run -d –name cow-test2 -p 8080:80 nginx

# 6. 確認（元のNginxページが表示される）
curl http://localhost:8080

<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> …

💡 確認できたこと

cow-testコンテナで変更した内容は、そのコンテナにだけ影響しました。
コンテナを削除して新しく作ると、元のイメージの状態に戻ります。
これがCopy-on-Writeの動作です。

# 後片付け
docker rm -f cow-test2

🏗️ 4. ベースイメージとは

4-1. ベースイメージの概念

ベースイメージとは、Dockerイメージを作る際の土台となるイメージです。
ほとんどのDockerイメージは、何らかのベースイメージの上に構築されています。

🏠 家の建築で例えると…

ベースイメージ = 基礎・土台
追加レイヤー = 壁、屋根、内装

しっかりした土台がないと、良い家は建てられません。
同様に、適切なベースイメージを選ぶことがDockerでも重要です。

4-2. よく使われるベースイメージ

イメージ	サイズ	特徴と用途
ubuntu	約77MB	最も人気のあるLinuxディストリビューション。aptでパッケージ管理。ドキュメントが豊富で初心者向け。
debian	約124MB	Ubuntuのベース。安定性重視。多くの公式イメージがDebianベース。
alpine	約7MB	超軽量Linux。本番環境で人気。apkでパッケージ管理。セキュリティ重視。
python	約920MB	Python実行環境が入ったイメージ。Pythonアプリケーション用。
node	約900MB	Node.js実行環境が入ったイメージ。JavaScriptアプリケーション用。
scratch	0B	完全に空のイメージ。静的リンクされたバイナリ専用。Goアプリなどで使用。

4-3. イメージのバリエーション（タグ）

多くのイメージには、用途に応じた複数のバリエーションがあります。

タグの種類	説明と例
（標準版）	`python:3.10` – フル機能版。開発に便利なツールが含まれる。サイズは大きめ。
-slim	`python:3.10-slim` – 軽量版。不要なパッケージを削除。標準版の約1/7のサイズ。
-alpine	`python:3.10-alpine` – Alpine Linux版。最軽量。標準版の約1/18のサイズ。
-bookworm/-bullseye	`python:3.10-bookworm` – Debianのバージョン指定。bookworm=12、bullseye=11。

4-4. サイズ比較の実例

# サイズを比較してみましょう
docker pull python:3.10
docker pull python:3.10-slim
docker pull python:3.10-alpine

docker images | grep python

REPOSITORY TAG IMAGE ID CREATED SIZE python 3.10 abc123def456 2 weeks ago 920MB python 3.10-slim def456ghi789 2 weeks ago 125MB python 3.10-alpine ghi789jkl012 2 weeks ago 49MB

【サイズ比較】

python:3.10        920MB  ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
python:3.10-slim   125MB  ━━━━                          14%
python:3.10-alpine  49MB  ━━                             5%

alpine版は標準版の約1/18のサイズ！

4-5. ベースイメージの選び方

🔧 開発環境の場合

推奨：標準版または-slim版

理由：
・デバッグツールが含まれている
・apt/yumでパッケージ追加が容易
・トラブルシューティングしやすい

🚀 本番環境の場合

推奨：-slim版または-alpine版

理由：
・イメージサイズが小さい
・攻撃対象が少ない（セキュリティ）
・デプロイが高速

⚠️ Alpine使用時の注意点

パッケージマネージャーが異なる：apt ではなく apk を使用
標準Cライブラリが異なる：glibcではなくmusl libcを使用。一部のバイナリが動かない場合あり
シェルが異なる：bashではなくash（shで実行）

互換性の問題が起きたら、-slim版を試してみましょう。

📉 5. イメージサイズの確認と最適化

5-1. なぜサイズを小さくするのか？

⏱️ ダウンロード高速化

1GB → 100MBなら
10倍速くダウンロード

💾 ディスク節約

100個のコンテナで
容量差は歴然

🔒 セキュリティ向上

不要なパッケージが少ない
→ 脆弱性も少ない

🚀 デプロイ高速化

本番環境への
デプロイが圧倒的に速い

5-2. イメージサイズの確認方法

docker imagesコマンド

docker images

📝 コマンドの意味

docker images ：ローカルにあるイメージの一覧とサイズを表示

REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest a6bd71f48f68 2 weeks ago 187MB python 3.10 abc123def456 2 weeks ago 920MB python 3.10-slim def456ghi789 2 weeks ago 125MB python 3.10-alpine ghi789jkl012 2 weeks ago 49MB ubuntu 22.04 jkl012mno345 3 weeks ago 77.8MB alpine 3.18 mno345pqr678 3 weeks ago 7.34MB

docker system dfコマンド

Dockerが使用しているディスク容量の概要を確認できます。

docker system df

📝 コマンドの意味

docker system df ：Dockerが使用しているディスク容量を表示（df = disk free）

TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 6 2 1.366GB 1.119GB (81%) Containers 2 2 1.024kB 0B (0%) Local Volumes 3 1 256.1MB 128.5MB (50%) Build Cache 12 0 512.3MB 512.3MB

✅ 確認ポイント

TOTAL：総数
ACTIVE：使用中の数
SIZE：使用容量
RECLAIMABLE：削除可能な容量

5-3. docker inspectで詳細情報を確認

docker inspectコマンドで、イメージの詳細情報をJSON形式で取得できます。

docker inspect nginx

        📝 コマンドの意味
        docker inspect ：イメージやコンテナの詳細情報を表示
nginx ：対象のイメージ名

    

特定の情報だけを取得することもできます。

# イメージのサイズを取得
docker inspect –format='{{.Size}}’ nginx

187180953

# レイヤー数を取得
docker inspect –format='{{len .RootFS.Layers}}’ nginx

7

5-4. サイズ最適化のテクニック

イメージサイズを小さくするための主なテクニックを紹介します。
これらは、STEP 11〜14（Dockerfile作成）で詳しく実践します。

1️⃣ 軽量なベースイメージを使う# 標準版（920MB）
FROM python:3.10

# Alpine版（49MB）← 約1/18のサイズ
FROM python:3.10-alpine

2️⃣ 不要なファイルを削除する# パッケージインストール後、キャッシュを削除
RUN apt-get update && \
    apt-get install -y package && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

3️⃣ マルチステージビルドを使う# ビルド用の大きなイメージ
FROM python:3.10 as builder
RUN pip install –user …

# 実行用の小さなイメージ
FROM python:3.10-alpine
COPY –from=builder /root/.local /root/.local

4️⃣ .dockerignoreを活用する# .dockerignore ファイル
.git
.gitignore
README.md
__pycache__
*.pyc
node_modules
.vscode

💡 バランスが大切

開発環境：多少大きくても使いやすさ重視
本番環境：サイズ・セキュリティ重視で軽量化

無理に軽量化すると、デバッグツールがなくてトラブル対応が大変…なんてことも。
目的に応じて、適切なバランスを選びましょう。

📊 6. 図解で理解するDocker構造

6-1. Docker全体の構造

【Dockerの全体構造】

                      インターネット
                           │
            ┌──────────────┴──────────────┐
            │    Docker Hub               │
            │    （イメージレジストリ）      │
            │    ・nginx                  │
            │    ・python                 │
            │    ・postgres               │
            └──────────────┬──────────────┘
                           │ docker pull
                           ↓
┌─────────────────────────────────────────────┐
│  ローカルマシン                                │
│                                             │
│  【イメージ】（読み取り専用のテンプレート）       │
│   ├─ nginx:latest                           │
│   ├─ python:3.10                            │
│   └─ postgres:15                            │
│                                             │
│           │ docker run                       │
│           ↓                                  │
│  【コンテナ】（実行中の環境）                    │
│   ├─ web-server (nginx) → ポート80           │
│   ├─ app (python) → ポート8000               │
│   └─ db (postgres) → ポート5432             │
│                                             │
└─────────────────────────────────────────────┘

6-2. イメージとコンテナの関係（詳細）

【イメージからコンテナが作られる仕組み】

┌─────────────────────────────────────────────┐
│  nginx イメージ（読み取り専用）                 │
│                                             │
│  ┌─────────────────────────────────────┐    │
│  │ Layer 6: CMD [“nginx”, …]         │    │
│  ├─────────────────────────────────────┤    │
│  │ Layer 5: EXPOSE 80                   │    │
│  ├─────────────────────────────────────┤    │
│  │ Layer 4: Nginx設定ファイル            │    │
│  ├─────────────────────────────────────┤    │
│  │ Layer 3: Nginxバイナリ               │    │
│  ├─────────────────────────────────────┤    │
│  │ Layer 2: ライブラリ                  │    │
│  ├─────────────────────────────────────┤    │
│  │ Layer 1: Debian OS                   │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘
                    │
                    │ docker run
                    ↓
┌─────────────────────────────────────────────┐
│  コンテナ                                    │
│                                             │
│  ┌─────────────────────────────────────┐    │
│  │ Container Layer（読み書き可能）       │    │
│  │ ・ログファイル                       │    │
│  │ ・変更された設定                     │    │
│  ├─────────────────────────────────────┤    │
│  │                                     │    │
│  │  イメージのレイヤー（参照のみ）        │    │
│  │  ※ Copy-on-Writeで効率的に共有      │    │
│  │                                     │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

6-3. 複数コンテナでのレイヤー共有

【同じイメージから複数コンテナを起動した場合】

        ┌─────────────────────────────┐
        │   nginx イメージ             │
        │   （全コンテナで共有）         │
        │                             │
        │   Layer 6: CMD              │
        │   Layer 5: EXPOSE           │
        │   Layer 4: 設定              │
        │   Layer 3: Nginx            │
        │   Layer 2: ライブラリ         │
        │   Layer 1: Debian           │
        └─────────────────────────────┘
              ↑      ↑      ↑
              │      │      │  （参照）
        ┌─────┐┌─────┐┌─────┐
        │web1 ││web2 ││web3 │ ← Container Layer
        │固有 ││固有 ││固有 │   （各コンテナ独立）
        └─────┘└─────┘└─────┘

→ イメージのレイヤーは全コンテナで共有（メモリ効率◎）
→ 各コンテナの変更は独立（互いに影響しない）
→ コンテナを削除しても、イメージは残る

💪 7. 練習問題

練習問題 1 基礎

イメージとコンテナの数を確認してください

現在ローカルにあるイメージの数と、コンテナの数を確認してください。

【解答】

# イメージの一覧を表示
docker images

# コンテナの一覧を表示（停止中も含む）
docker ps -a

docker imagesでイメージ数、docker ps -aでコンテナ数がわかります。

練習問題 2 基礎

Pythonイメージの各バージョンのサイズを比較してください

python:3.10、python:3.10-slim、python:3.10-alpine をダウンロードし、サイズを比較してください。

【解答】

# 3つのイメージをダウンロード
docker pull python:3.10
docker pull python:3.10-slim
docker pull python:3.10-alpine

# サイズを確認
docker images | grep python

結果：python:3.10（約920MB）、3.10-slim（約125MB）、3.10-alpine（約49MB）
alpine版は標準版の約1/18のサイズです。

練習問題 3 基礎

イメージのレイヤー構造を確認してください

nginxイメージの履歴（レイヤー情報）を表示し、何層あるか確認してください。

【解答】

# nginxイメージをダウンロード（まだない場合）
docker pull nginx

# レイヤー履歴を表示
docker history nginx

# レイヤー数を確認
docker inspect –format='{{len .RootFS.Layers}}’ nginx

練習問題 4 応用

1つのイメージから複数のコンテナを作成してください

タスク：

nginxイメージから5つのコンテナを起動（ポート8001〜8005）
イメージが1つだけであることを確認
コンテナが5つあることを確認
全て停止・削除

【解答】

# 5つのコンテナを起動
docker run -d –name web1 -p 8001:80 nginx
docker run -d –name web2 -p 8002:80 nginx
docker run -d –name web3 -p 8003:80 nginx
docker run -d –name web4 -p 8004:80 nginx
docker run -d –name web5 -p 8005:80 nginx

# イメージ確認（nginxは1つだけ）
docker images | grep nginx

# コンテナ確認（5つある）
docker ps

# 全て停止・削除
docker stop web1 web2 web3 web4 web5
docker rm web1 web2 web3 web4 web5

練習問題 5 応用

Copy-on-Writeの動作を確認してください

タスク：

nginxコンテナを起動
コンテナ内でindex.htmlを変更
変更が反映されていることを確認
コンテナを削除して新しいコンテナを起動
変更が消えている（元に戻っている）ことを確認

【解答】

# 1. コンテナを起動
docker run -d –name cow-test -p 8080:80 nginx

# 2. index.htmlを変更
docker exec cow-test sh -c “echo ‘Modified!’ > /usr/share/nginx/html/index.html”

# 3. 変更を確認
curl http://localhost:8080
# → “Modified!” と表示される

# 4. コンテナを削除して新しいコンテナを起動
docker rm -f cow-test
docker run -d –name cow-test2 -p 8080:80 nginx

# 5. 元に戻っていることを確認
curl http://localhost:8080
# → “Welcome to nginx!” と表示される

# 後片付け
docker rm -f cow-test2

練習問題 6 応用

UbuntuとAlpineの違いを体験してください

タスク：

ubuntu:22.04とalpine:3.18をダウンロード
それぞれ対話モードで起動
パッケージマネージャーの違いを確認（apt vs apk）
イメージサイズの違いを確認

【解答】

# ダウンロード
docker pull ubuntu:22.04
docker pull alpine:3.18

# サイズ確認
docker images | grep -E “ubuntu|alpine”
# ubuntu: 約77MB、alpine: 約7MB

# Ubuntuを起動（bashが使える）
docker run -it –rm ubuntu:22.04 bash
# → apt update でパッケージ更新可能
# → exit で終了

# Alpineを起動（shを使う）
docker run -it –rm alpine:3.18 sh
# → apk update でパッケージ更新
# → exit で終了

違いのポイント：
・Ubuntu: apt/bash使用、サイズ大きめ、デバッグしやすい
・Alpine: apk/sh使用、超軽量、本番環境向け

練習問題 7 発展

Dockerが使用しているディスク容量を確認してください

docker system dfコマンドを使って、イメージ・コンテナ・ボリュームの使用容量を確認し、不要なものを削除してください。

【解答】

# ディスク使用量を確認
docker system df

# 詳細を表示
docker system df -v

# 停止中のコンテナを削除
docker container prune

# 未使用のイメージを削除
docker image prune

# 全ての未使用リソースを削除（注意して実行）
docker system prune

練習問題 8 発展

docker inspectで特定の情報を取得してください

nginxイメージから以下の情報を取得してください：

イメージのサイズ（バイト）
レイヤーの数
公開ポート

【解答】

# 1. イメージのサイズ
docker inspect –format='{{.Size}}’ nginx

# 2. レイヤーの数
docker inspect –format='{{len .RootFS.Layers}}’ nginx

# 3. 公開ポート
docker inspect –format='{{.Config.ExposedPorts}}’ nginx

--formatオプションでGo言語のテンプレート構文を使い、
JSON形式の出力から特定のフィールドだけを取得できます。

📝 STEP 6 のまとめ

        ✅ このステップで学んだこと
        イメージは設計図（読み取り専用）、コンテナは実行環境（読み書き可能）
1つのイメージから複数のコンテナを作成できる
イメージはレイヤー構造で、効率的にストレージと帯域を使用
Copy-on-Writeにより、変更時だけコピーが発生
ベースイメージの選択が重要（alpine vs ubuntu）
docker historyでレイヤー、docker inspectで詳細情報を確認

    

📊 今回学んだコマンド一覧

コマンド	機能
`docker pull イメージ`	イメージをダウンロード
`docker images`	イメージ一覧とサイズを表示
`docker history イメージ`	イメージのレイヤー履歴を表示
`docker inspect イメージ`	イメージの詳細情報をJSON形式で表示
`docker system df`	Dockerのディスク使用量を表示
`docker system prune`	未使用のリソースを一括削除

💡 重要ポイント

イメージの仕組みを理解すると、なぜDockerが効率的なのかがわかります。
レイヤー構造とCopy-on-Writeにより、ストレージもネットワークも効率的に使えるのです。

本番環境では、イメージサイズの最適化が非常に重要です。
軽量なイメージは、デプロイが速く、セキュリティリスクも低くなります。

🎯 次のステップの予告

次のSTEP 7では、「Docker Hubとイメージの取得」を学びます。

Docker Hubとは何か
イメージの検索方法
タグの意味（latest、バージョン番号）
公式イメージと非公式イメージの違い

Docker Hubを使いこなして、世界中のイメージを活用できるようになりましょう！

🐳 STEP 6: Dockerイメージの仕組み

📋 このステップで学ぶこと

🎯 1. イメージとコンテナの違い

1-1. 基本的な概念

1-2. イメージとコンテナの特徴

1-3. 具体例で理解する

1-4. イメージとコンテナの関係図

1-5. コンテナを削除してもイメージは残る

🧱 2. レイヤー構造の理解

2-1. レイヤーとは？

2-2. レイヤー構造の具体例

2-3. docker historyでレイヤーを確認

2-4. レイヤー構造の3つのメリット

2-5. レイヤー共有の具体例

📝 3. Copy-on-Write（コピーオンライト）

3-1. Copy-on-Writeとは？

3-2. Copy-on-Writeの動作

3-3. Copy-on-Writeのメリット

3-4. 実際に確認してみよう

🏗️ 4. ベースイメージとは

4-1. ベースイメージの概念

4-2. よく使われるベースイメージ

4-3. イメージのバリエーション（タグ）

4-4. サイズ比較の実例

4-5. ベースイメージの選び方

📉 5. イメージサイズの確認と最適化

5-1. なぜサイズを小さくするのか？

5-2. イメージサイズの確認方法

docker imagesコマンド

docker system dfコマンド

5-3. docker inspectで詳細情報を確認

5-4. サイズ最適化のテクニック

📊 6. 図解で理解するDocker構造

6-1. Docker全体の構造

6-2. イメージとコンテナの関係（詳細）

6-3. 複数コンテナでのレイヤー共有

💪 7. 練習問題

イメージとコンテナの数を確認してください

Pythonイメージの各バージョンのサイズを比較してください

イメージのレイヤー構造を確認してください

1つのイメージから複数のコンテナを作成してください

Copy-on-Writeの動作を確認してください

UbuntuとAlpineの違いを体験してください

Dockerが使用しているディスク容量を確認してください

docker inspectで特定の情報を取得してください

📝 STEP 6 のまとめ

学習メモ