コンテナイメージの仕組み ― レイヤー構造からセキュリティまで

コンテナイメージは、アプリを動かすために必要なファイルや設定をまるごとパッケージにした「読み取り専用のテンプレート」だよ。料理でいうと「レシピ＋材料セット」みたいなもので、これがあればどこでも同じ環境を再現できるんだ。

Dockerfileっていう設計図を書いて、docker build コマンドで組み立てるよ。たとえば「ベースOSはAlpine Linux」「Node.jsをインストール」「アプリのコードをコピー」みたいな手順を1行ずつ書いていくんだ。

Dockerfileの各命令が1つの「レイヤー（層）」になるんだ。ミルフィーユみたいに薄い層が重なっていて、Union FileSystemという技術で1つのファイルシステムに見せてるよ。変更があったレイヤーだけ差し替えればいいから、ビルドもダウンロードも高速なんだ。

Copy-on-Write（CoW）っていう仕組みで、元のレイヤーはそのままに、変更分だけ新しい書き込み層に記録されるよ。だから元のイメージは汚れないし、同じイメージから何個コンテナを起動してもディスクの無駄がないんだ。

レジストリっていう倉庫に保存するよ。Docker Hubが一番有名で、AWSのECRやGoogleのGCRもあるね。タグ（例: myapp:v1.2）で管理するんだけど、タグは上書きできちゃうから、確実に特定したいときはsha256のダイジェスト値を使うのが安全だよ。

デプロイが遅くなるし、ストレージも食うから小さい方がいいね。マルチステージビルドっていうテクニックがあって、ビルド用の大きな環境でコンパイルして、実行用には最小限のファイルだけコピーするんだ。ベースイメージもAlpine（約5MB）やdistroless、scratchを選ぶとグッと小さくなるよ。

イメージの中に古いライブラリや既知の脆弱性が含まれていることがあるんだ。TrivyやSnykみたいなスキャンツールでCI/CDパイプラインに組み込んで、脆弱性を自動検出するのが今の標準的なやり方だよ。

サプライチェーンセキュリティっていう考え方が重要になってきてるよ。cosignやNotaryでイメージに電子署名を付けて「このイメージは改ざんされていない」と証明するんだ。さらにSBOM（ソフトウェア部品表）を添付して、どんなライブラリが入っているか透明にする動きも広がってるね。

実はならないことが多いんだ。apt-get updateで取得されるバージョンが変わったり、タイムスタンプが違ったりするからね。「再現可能ビルド（Reproducible Build）」は意外と難しくて、ベースイメージのダイジェスト固定やパッケージバージョンのピン留めが必要になるよ。本番環境の信頼性に直結する、奥が深いテーマだね。