Tech Learning Daily

イメージは「差分の積み重ね」でできている

コンテナイメージは 1 つの大きなファイルではなく、レイヤーの積み重ねである。レイヤーとは、Dockerfile の命令ごとに「直前の状態から何が増えた・変わった・消えたか」だけを記録したファイル群のことだ。FROM alpine のベース、RUN apk add で増えたファイル、COPY で置いたアプリのコード、とそれぞれが別のレイヤーになる。

レイヤーは一度作られたら読み取り専用（RO）で、後から書き換えられることはない。書き換えないと決めているからこそ、同じ内容のレイヤーをディスク上に 1 つだけ置き、複数のイメージやコンテナから安全に参照できる。docker pull で「Already exists」と表示されて一部のレイヤーがダウンロードされないのも、手元に同じレイヤーがすでにあるからだ。

コンテナを起動すると、Docker はこの読み取り専用レイヤーの山の一番上に、そのコンテナ専用の空の書き込み層（コンテナ層）を 1 枚だけ足す。コンテナ内での変更はすべてこの層に入り、下のイメージレイヤーは変わらない。10 個起動しても増えるのは 10 枚の薄い書き込み層だけなので、ディスクは 10 倍にならない。これが lead の 1 つ目の問いへの答えである。

OverlayFS ―― ディレクトリを重ねて 1 枚に見せる

では、別々に置かれた複数のレイヤーが、コンテナの中からはなぜ普通の 1 つの / に見えるのか。これを担うのが Linux カーネルの OverlayFS で、複数のディレクトリを上下に重ね、1 つのディレクトリとして見せるファイルシステムである。読み取り専用の下層を lowerdir、書き込みを受ける上層を upperdir、重ねた結果見える場所を merged と呼ぶ（workdir は OverlayFS が内部処理に使う作業用ディレクトリ）。

 container A          container B
┌────────────┐       ┌────────────┐
│ upper (RW) │       │ upper (RW) │
└────────────┘       └────────────┘
       │                    │
       └─────────┐ ┌────────┘
                 ▼ ▼
┌──────────────────────────────┐
│ layer3: COPY app/      (RO)  │
├──────────────────────────────┤
│ layer2: RUN apk add    (RO)  │
├──────────────────────────────┤
│ layer1: alpine base    (RO)  │
└──────────────────────────────┘
  lowerdir: 全コンテナで共有

ファイルを読むとき、OverlayFS は上の層から順に探し、最初に見つかったものを返す。同じ名前のファイルが上下両方にあれば、上層（コンテナ層）のものが下層のものを覆い隠す。中身を手で組み立てるなら、カーネルのドキュメントにある次の 1 行と同じことを Docker がやっている。

mount -t overlay overlay \
  -olowerdir=/lower,upperdir=/upper,workdir=/work /merged

なお Docker Engine 29.0 以降の新規インストールでは、イメージの保存は従来の overlay2 ストレージドライバではなく containerd のイメージストアが既定になり、その中で overlayfs スナップショッタが使われる。管理する主体は変わったが、OverlayFS で層を重ねるという仕組み自体は同じだ。自分の環境がどちらかは docker info -f '{{ .DriverStatus }}' で確認でき、containerd 側なら io.containerd.snapshotter.v1 と表示される。

書き込みと削除 ―― copy-up と whiteout

下層にあるファイルを初めて書き換えるとき、OverlayFS はそのファイルをまず上層へコピーし、コピーの方を書き換える。これを copy-up と呼ぶ。OverlayFS はブロック単位ではなくファイル単位で動くため、1 GB のファイルの末尾に 1 バイト追記するだけでも、最初の 1 回はファイル全体のコピーが走る。2 回目以降の書き込みはすでに上層にあるコピーへ直接行われる。権限や所有者の変更（chmod / chown）でも copy-up が起きる。

操作         upper で起きること
read  a.txt  何もしない（下層を読む）
write a.txt  a.txt を丸ごと複製して書換
rm    b.txt  b.txt の whiteout を作る

削除はさらに意外な動きをする。下層は読み取り専用なので、ファイルを本当に消すことはできない。代わりに上層へwhiteout（カーネルの実装ではデバイス番号 0/0 のキャラクタデバイス）を置き、「この名前は存在しないことにする」と OverlayFS に伝える。ディレクトリ丸ごとの削除では、上層のディレクトリに opaque（不透明）の印を付けて下層の中身を隠す。

ここで lead の 2 つ目の問いが回収できる。Dockerfile で RUN を 2 行に分けて「巨大ファイルを置く」「それを消す」と書くと、1 つ目のレイヤーには巨大ファイルが残り、2 つ目のレイヤーには whiteout が載るだけだ。消したように見えるのは重ねた結果の見え方であって、イメージにはファイルの実体が残り続ける。サイズを減らしたければ、取得と削除を同じ RUN 内で行うか、マルチステージビルドで成果物だけを最終イメージに COPY する必要がある。

# NG: 1 つ目のレイヤーに実体が残る
RUN curl -o /tmp/sdk.tgz https://example.com/sdk.tgz
RUN tar xzf /tmp/sdk.tgz -C /opt && rm /tmp/sdk.tgz

# OK: 同じレイヤー内で消すので実体が残らない
RUN curl -o /tmp/sdk.tgz https://example.com/sdk.tgz \
 && tar xzf /tmp/sdk.tgz -C /opt && rm /tmp/sdk.tgz

コンテナ層に書いてはいけないもの

書き込み層はコンテナと運命を共にする。docker rm するとコンテナ層ごと削除されるため、そこに書いたアップロード画像や SQLite のファイルも消える。また書き込みのたびに OverlayFS を経由し、大きなファイルでは初回に copy-up も挟まるので、DB のデータファイルのように書き込みの多いデータには向かない。Docker のドキュメントも、書き込みの多いデータやコンテナより長生きさせたいデータにはボリュームを使うよう勧めている。ボリュームはホスト側のディレクトリをそのままマウントするので、OverlayFS の層を通らない。

# /var/lib/postgresql/data だけ層の外（ボリューム）に出す
docker run -d -v pgdata:/var/lib/postgresql/data postgres:17

Kubernetes では、コンテナ層への書き込みは ephemeral-storage（ノードのローカルディスク上の一時領域）として計上される。kubelet が数えるのは書き込み層、emptyDir、Pod のログなどで、コンテナの書き込み層とログの合計が limits.ephemeral-storage を超えると、kubelet はその Pod を退避（eviction）対象にする。limit を書かなければ上限なしでノードのディスクを食い続け、ノード全体のディスク逼迫として別の Pod まで巻き込みうる。

resources:
  requests:
    ephemeral-storage: "1Gi"
  limits:
    ephemeral-storage: "2Gi"   # 超えると Pod が evict される

アプリがログを標準出力ではなくコンテナ内のファイルに書き続けていると、それは書き込み層に溜まり、ephemeral-storage を消費し続ける。「メモリもCPUも余裕なのに Pod が Evicted になる」とき、まず疑う場所がここである。