Container Registry

解決する課題

ビルドしたコンテナイメージを安全に保管し、GKE や Cloud Run などのデプロイ先へ確実に配信する置き場が必要です。Container Registry は、その「イメージの保管庫」を GCP のプロジェクト内にマネージドで用意します。

• ビルドしたコンテナイメージを GCP 内に集約し、デプロイ先から pull したい
• イメージの push/pull 権限を IAM で制御し、誰がイメージを置けて誰が取得できるかを管理したい
• イメージをリージョン（ホスト）単位で保管し、デプロイ先と近い場所から配信して遅延や転送費用を抑えたい
• 外部レジストリに依存せず、Cloud Build から自プロジェクトのレジストリへ自動 push する CI/CD を組みたい

主要概念と用語

• コンテナレジストリ（container registry）: コンテナイメージを保存・配信するためのサーバー。push でイメージを登録し、pull で取得する
• イメージ（image）: アプリと依存をまとめた実行可能なパッケージ。タグやダイジェストで特定のバージョンを参照する
• リポジトリパス（repository path）: HOST/PROJECT_ID/IMAGE の形式でイメージを指す名前。例として gcr.io/PROJECT_ID/web のように表す
• ホスト（registry host）: 保管リージョンを表すエンドポイント。gcr.io（米国）・asia.gcr.io・eu.gcr.io・us.gcr.io のように地域別に分かれる
• タグ（tag）: web:latest のようにイメージの版を指す可読なラベル。同じタグでも push し直すと指す中身が変わりうる
• ダイジェスト（digest）: sha256:... で表す内容ハッシュ。中身が同じなら常に同じ値になり、再現性のある参照に使う
• 裏側の Cloud Storage バケット: イメージの実体は自動生成される Cloud Storage バケットに格納される。アクセス制御もこのバケットの権限が基になる

仕様・制限・クォータ

• イメージの実体はプロジェクト内に自動生成される Cloud Storage バケットに保存され、レジストリの権限はそのバケットの IAM に基づく
• ホスト名で保管リージョンが決まる（例として米国・アジア・欧州など）。デプロイ先と同じ地域を選ぶと pull が速く転送費用も抑えやすい
• 認証は gcloud によるクレデンシャルヘルパー経由で行い、Docker クライアントが GCP の認証情報で push/pull できるようにする
• アクセス制御の粒度はバケット単位が基本で、Artifact Registry のようなリポジトリ単位の細かい IAM には対応しない
• 脆弱性スキャンは Container Analysis と連携して実施でき、push 済みイメージの既知脆弱性を検出できる
• 新規利用の受け付けや機能追加は終息方向にあり、最新機能は後継の Artifact Registry 側で提供される

内部の仕組み

Container Registry は、専用のレジストリ基盤を持つというより、Cloud Storage バケットをバックエンドにした薄いレジストリ層として動きます。初めてイメージを push したホスト（gcr.io など）ごとに、プロジェクト内へ専用のバケットが自動作成され、イメージのレイヤーやマニフェストはそのバケットに格納されます。

• push/pull のアクセス制御は、裏側バケットの IAM 権限で決まる。バケットへの読み取りを持つ ID が pull でき、書き込みを持つ ID が push できる
• ホスト名（地域）ごとにバケットが分かれるため、保管リージョンの選択はホスト名で行う
• イメージはタグまたはダイジェストで参照する。再現性が要るデプロイではダイジェスト参照を使う
• Cloud Build からはこのレジストリへ直接 push でき、ビルドからデプロイまでを自プロジェクト内で完結できる

この「実体がただの Cloud Storage バケット」という設計が、後継の Artifact Registry との大きな違いです。Artifact Registry は専用のリポジトリという概念を持ち、リポジトリ単位で IAM やフォーマット（Docker 以外の言語パッケージも）を扱えるため、よりきめ細かい管理ができます。

AWS でいえば、コンテナイメージの保管・配信を担う Amazon ECR に相当します。ECR がリポジトリ単位のポリシーを持つのに対し、Container Registry はバケット単位の制御である点が対比になります。

設計パターン / ベストプラクティス

• 新規構築では Artifact Registry を選択する。Container Registry は既存資産の維持にとどめ、計画的に移行する
• デプロイはタグではなくダイジェスト（sha256）で参照し、同じイメージが確実に動くようにする
• イメージの保管ホストはデプロイ先と同じ地域を選び、pull の遅延とリージョン間転送費用を抑える
• CI/CD では Cloud Build からレジストリへ push し、ビルドからデプロイまでを自プロジェクト内で完結させる
• push 後のイメージは Container Analysis で脆弱性スキャンし、既知の重大脆弱性を含むイメージのデプロイを避ける
• 古い・未使用のイメージは定期的に整理し、裏側バケットの保管費用の肥大化を防ぐ

運用・監視

• レジストリの実体はバケットなので、保管容量と Cloud Storage の費用を監視対象にする
• イメージへのアクセスや変更は Cloud Audit Logs で追跡できる（誰がいつ push/pull したか）
• 脆弱性スキャン結果は Container Analysis から確認し、新たに見つかった脆弱性に対応する
• よくある失敗は認証設定の不足（gcloud のクレデンシャルヘルパー未設定）と、裏側バケットへの権限不足による push/pull 失敗
• 不要イメージの蓄積でバケットが膨らむため、ライフサイクルに沿った削除を運用に組み込む

コスト

Container Registry そのものには専用の料金体系がなく、課金は実体である Cloud Storage の保管容量と下り通信（egress） に対して発生します。つまり、保存しているイメージの総サイズと、それを別リージョンやインターネットへ pull する際のデータ転送量が費用の主因です。

セキュリティ

• push/pull の権限は裏側バケットの IAM で決まる。読み取りと書き込みを必要な ID に限定し、過剰な公開を避ける
• レジストリ全体やバケットを公開（allUsers への付与）にしない。社内利用なら非公開を徹底する
• イメージはダイジェスト参照で固定し、想定外のイメージがデプロイされる事故を防ぐ
• Container Analysis で脆弱性スキャンし、必要に応じて Binary Authorization と組み合わせて検証済みイメージだけをデプロイする
• 細かい権限分離が必要な場合は、リポジトリ単位 IAM を持つ Artifact Registry へ移行する方がより安全に運用できる

関連サービス・比較

最も近い関連サービスは後継の Artifact Registry です。役割は重なりますが、管理の粒度や対応フォーマットに違いがあります。

ハンズオン / CLI例

# Docker が gcr.io へ push/pull できるよう認証ヘルパーを設定
gcloud auth configure-docker

# ローカルイメージにレジストリ向けのタグを付ける（PROJECT_ID は自分のプロジェクト）
docker tag web:latest gcr.io/PROJECT_ID/web:latest

# イメージを Container Registry へ push
docker push gcr.io/PROJECT_ID/web:latest

# レジストリ内のイメージ（リポジトリ）一覧を確認
gcloud container images list --repository=gcr.io/PROJECT_ID

# 特定イメージのタグとダイジェスト一覧を表示
gcloud container images list-tags gcr.io/PROJECT_ID/web

# 不要になったイメージをダイジェスト指定で削除
gcloud container images delete gcr.io/PROJECT_ID/web@sha256:DIGEST --quiet