コンテナイメージの仕組み — メッセージ入りのひな型を動かす

ひよこ

同じメッセージを表示する環境を、何個も用意したいな。

ペンギン先生

コンテナイメージにファイルと実行設定をまとめれば、そのひな型からコンテナを作れるよ。下ではmessage.txtを表示する例を試す。動かすには対応するOS・CPUや実行基盤が必要で、どんな場所でも同じ動作を保証するものではないんだ。

ひよこ

レイヤーっていう仕組みがあるって聞いたけど、何なの？

ペンギン先生

RUNやCOPYなどによるファイルの変更を、不変の層として重ねるんだ。CMDのように起動設定だけを記録する命令はファイルの層を増やさないよ。使えるキャッシュは再利用できるけれど、同じビルド段階の途中でキャッシュが無効になると、後続の手順も作り直すんだ。

ひよこ

コンテナが動いてるときにファイルを変更したらどうなるの？

ペンギン先生

通常の書き込み可能なコンテナでは、元のイメージを保ったまま専用の書き込み層に記録するよ。Copy-on-Writeでは、元のファイルを変更するときにコピーが必要になることもある。読み取り専用の層は共有できるけれど、各コンテナの書き込み分には容量が必要だね。ボリュームへの書き込みはこの層とは別だよ。

ひよこ

イメージってどこに保存するの？

ペンギン先生

レジストリという倉庫に保存するよ。Google CloudではArtifact Registryが案内されていて、旧Container Registryは提供終了している。ただしArtifact Registryが配信するgcr.ioのURLは引き続き使えるよ。タグは別の内容を指すよう更新できるので、特定のイメージを固定するときはダイジェストを使うんだ。

ひよこ

イメージが大きすぎると困ることってあるの？

ペンギン先生

転送や保存に必要な量が増えるね。マルチステージビルドなら、ビルド用の段階で作った成果物を実行用の段階へコピーして、コンパイラなどを最終イメージから外せる。小ささだけで選ばず、実行に必要なライブラリや証明書などがそろっているか確認しよう。

ひよこ

セキュリティ面で気をつけることってあるの？

ペンギン先生

たとえばTrivyは、対応するOSや言語のパッケージを脆弱性データベースと照合できるよ。CI/CDに組み込むと確認を続けやすい。ただし未検出でも安全の証明にはならないんだ。ベースイメージや依存ライブラリを更新して再ビルドする運用も必要だよ。

ひよこ

もっと進んだセキュリティ対策ってあるの？

ペンギン先生

cosignなどで署名を検証する方法があるよ。信頼する公開鍵、または期待する署名者と証明書の発行元を指定し、署名とイメージのダイジェストが合うかを確認するんだ。署名が正しくても、作成時から含まれていた脆弱性や悪意ある処理まで否定できるわけではないよ。

ひよこ

同じDockerfileでビルドしても毎回同じイメージになるの？

ペンギン先生

同じになるとは限らないよ。ベースイメージのタグや取得する依存パッケージが変わることがあるからね。ダイジェストや依存バージョンを固定すると変動を減らせるけれど、それだけで完全な再現性は保証できない。固定した依存関係も、修正が出たら更新してテストしよう。

まずは「メッセージ入りのイメージ」と「動くコンテナ」を分ける

コンテナイメージは、実行に使うファイルと設定をまとめたものです。イメージからコンテナを作り、その中でコマンドを動かします。写真ではなく、同じ準備済みの内容から実行環境を作るためのひな型と考えましょう。

Dockerが導入済みでLinuxコンテナを実行できる環境なら、次の小さな例を試せます。新しい練習用フォルダーに、UTF-8のmessage.txtを作り「こんにちは、ひよこです」と1行書いて保存します。同じ場所に、拡張子なしのDockerfileを保存してください。

FROM alpine:3.23
COPY message.txt /message.txt
CMD ["cat", "/message.txt"]

そのフォルダーで、次を順番に実行します。初回はベースイメージを取得するため通信が必要です。

docker build -t hiyopen-message .
docker run --rm hiyopen-message

成功すると、message.txtの内容が表示されます。COPYはファイルをイメージへ入れる命令、CMDはコンテナを起動するときの既定のコマンドです。CMDがビルド時にcatを実行するわけではありません。

ファイルを変更したら、何が変わる？

ホスト側のmessage.txtを「こんにちは、ぺんぎんです」へ変更し、まず同じrunをもう一度試してください。イメージを作り直していなければ、前にCOPYした「ひよこ」の内容が使われます。

その後、もう一度buildしてrunすると、新しくコピーした「ぺんぎん」の内容が表示されます。この例はボリュームやバインドマウントを使っていません。元のファイルを編集することと、イメージを更新することは別だと確認できます。

レイヤーと書き込み層の違い

イメージは、不変のファイル差分の層と、起動などの設定を持ちます。コンテナを通常の書き込み可能な構成で作ると、そのコンテナ専用の書き込み層が加わります。

同じイメージからコンテナAとBを作っても、Aの書き込み層で変更した内容は、Bの書き込み層へ自動反映されません。コンテナを削除すると、その専用の書き込み層も削除されます。残す必要のあるデータには、ボリュームなど別の保管を考えます。

すべてのDockerfile命令がファイルの層を追加するわけではなく、CMDなどは設定です。COPYした内容の変更などでキャッシュが使えなくなった場合は、同じ段階の後続手順も再実行されます。

もう少し詳しく：配布・更新・確認

レジストリはイメージを配布する倉庫です。タグは別の内容を指すように変更できます。特定の内容を参照するにはダイジェストを使いますが、固定した依存関係も修正に合わせて更新する運用が必要です。同じDockerfileだけで、取得するすべての依存やビルド結果まで同一になるとは限りません。

マルチステージビルドでは、ビルド用の段階から成果物だけを実行用の段階へコピーできます。小ささだけでなく、実行に必要なライブラリーや証明書がそろうかも確認します。OS・CPUとの互換性も必要で、どのマシンでも同じ動作を保証するものではありません。

脆弱性スキャンは既知の問題を探す手掛かりで、署名検証は期待する署名者やダイジェストとの対応を確かめる手段です。どちらも、含まれるプログラムが無害であることの証明ではありません。

Google Cloudでは旧Container Registryは終了し、Artifact Registryへの移行が案内されています。Artifact Registryが配信するgcr.ioのURLまで、すべて使えなくなったわけではありません。

覚え方と次の一歩

「コンテナイメージ」って出てきたら「実行に使うファイルと設定をまとめたひな型」と思えばだいたいOK！

Docker入門で起動の流れを試し、仮想マシンとコンテナの比較で実行基盤との違いを整理できます。

参考資料

• Docker: Understanding the image layers — 不変のファイル差分の積層とコンテナ実行時の専用書き込み領域。
• Docker: Storage drivers — CMD/LABELはメタデータ、読み取り専用層の共有、書き込み層とcopy_upの容量、ボリュームとの区別。
• Docker: Build cache invalidation — キャッシュ無効化後は後続手順も再実行される。
• Docker: Building best practices — タグの可変性、digest固定、依存更新と定期再ビルド、最小構成の選択。
• Docker: Multi-stage builds — COPY —fromで成果物を最終段階へ渡し、ビルド用ツールを除ける。
• Docker: Multi-platform builds — ホストOS/CPUとの互換性が必要で、無条件にどこでも実行できるわけではない。
• Google Cloud: Transition from Container Registry — 旧Container Registry終了、Artifact Registry推奨、同サービスが配信するgcr.io URLは継続。
• Trivy: Vulnerability — 対応ソフトウェアの既知の脆弱性をデータベースで検出。検出対象に限界がある。
• Sigstore: Verifying Signatures — 信頼する公開鍵または期待するidentity/issuerを指定し、署名とイメージdigestを検証する。
• Docker：Dockerfile reference — COPYとCMD、CMDはビルド時には実行しない