Container Registry

解決する課題

Container Registry は停止済みです。現在の課題は、旧 Cloud Storage バケットに残るイメージと gcr.io 参照を棚卸しし、Artifact Registry 上の保存先、権限、実行環境の取得経路へ移すことです。

• ビルドしたコンテナイメージを 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 済みイメージの既知脆弱性を検出できる
• 旧 Container Registry への書き込みと読み取りは停止済み。利用可能な gcr.io URL は Artifact Registry が提供するものに限られる

内部の仕組み

横にスクロール

旧 Container Registry は、Cloud Storage バケットをバックエンドにした薄いレジストリ層でした。移行後は、gcr.io を使い続ける場合でも要求が同一プロジェクトの Artifact Registry リポジトリへ転送されます。新規の pkg.dev リポジトリへ変える場合は、URLも明示的に変更します。

• 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 の費用を監視対象にする
• 旧 Container Registry はレジストリ操作の監査ログを提供しなかった。移行後は Artifact Registry の監査ログで登録・取得・設定変更を追跡する
• 脆弱性スキャン結果は Container Analysis から確認し、新たに見つかった脆弱性に対応する
• よくある失敗は認証設定の不足（gcloud のクレデンシャルヘルパー未設定）と、裏側バケットへの権限不足による push/pull 失敗
• 不要イメージの蓄積でバケットが膨らむため、ライフサイクルに沿った削除を運用に組み込む

コスト

移行前の旧イメージには Cloud Storage の保管費が残り得ます。現行の配布元は Artifact Registry の保管、データ転送、脆弱性スキャンの料金で見積もり、移行検証後に不要な旧バケットを整理します。

セキュリティ

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

関連サービス・比較

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

ハンズオン / CLI例

# gcr.io互換リポジトリで現在取得できるイメージを確認する
# 旧バケットやコード内の参照先は別途棚卸しする
gcloud artifacts docker images list \
  gcr.io/PROJECT_ID --include-tags

# gcr.io互換リポジトリへの移行を自動化する公式ツール
gcloud artifacts docker upgrade migrate \
  --projects=PROJECT_ID

# Artifact Registry側の保存先とダイジェストを確認する
gcloud artifacts docker images list \
  gcr.io/PROJECT_ID --include-tags

# pkg.devへ切り替える場合は対象ホストの認証を設定し、
# ビルド定義・実行環境・配布設定の参照先も同時に変更する
gcloud auth configure-docker \
  asia-northeast1-docker.pkg.dev