Container Registry の概要

Container Registry は、Google Cloud に非公開コンテナ イメージを保存するためのレガシー サービスです。

このサービスは非推奨になりました。既存のイメージを Artifact Registry に移行しても、gcr.io ドメインを使用して引き続きアクセスできます。 2024 年 5 月 15 日以降、以前の Container Registry を使用しないプロジェクトでは、Artifact Registry で gcr.io ドメインのイメージのみがホストされます。

Container Registry と Artifact Registry の比較と、Container Registry から Artifact Registry への移行については、Container Registry からの移行をご覧ください。

イメージの操作

多くのユーザーは Docker 公開イメージを保存するための中央レジストリとして Docker Hub を使用しますが、イメージへのアクセスを制御するには、Artifact Registry や Container Registry などの非公開レジストリを使用する必要があります。

セキュアな HTTPS エンドポイントを使用してレジストリにアクセスできるため、あらゆるシステム、VM インスタンス、所有のハードウェアからイメージを push、pull、管理することが可能です。

  • レジストリは、Google Cloud の CI / CD サービスや既存の CI / CD ツールと統合できます。
  • コンテナ ソフトウェアのサプライ チェーンを保護します。
    • Artifact Analysis を使用して、コンテナのメタデータを管理し、コンテナの脆弱性をスキャンします。
    • Binary Authorization を使用してデプロイ ポリシーを適用します。
  • VPC Service Controls セキュリティ境界でレジストリを保護します。

レジストリ

Container Registry を使用して、Google Cloud プロジェクトごとに最大 4 つのマルチリージョン ホストを作成できます。別々のアクセス ポリシーを使用して個別のリポジトリを作成する場合や、マルチリージョンではなくリージョンにイメージを保存する場合は、代わりに Artifact Registry を使用します。

Container Registry 内のレジストリは、ホストとプロジェクト ID によって命名されます。イメージを操作（push、pull、delete など）するには、次の形式を使用してイメージを識別します。

HOSTNAME/PROJECT-ID/IMAGE:TAG

または

HOSTNAME/PROJECT-ID/IMAGE@IMAGE-DIGEST

ここで

  • HOSTNAME は、イメージが保存される場所です。

    • gcr.io は現時点では米国でイメージをホストしていますが、今後は場所が変更される可能性があります。
    • us.gcr.io は米国でイメージをホストしますが、その場所は、gcr.io によってホストされるイメージからは独立したストレージ バケットです。
    • eu.gcr.io は、欧州連合の加盟国でイメージをホストします。
    • asia.gcr.io は、アジアでイメージをホストします。

    これらの場所は、Cloud Storage ストレージ バケットのマルチリージョンに対応します。イメージを新しいホスト名でレジストリに push すると、Container Registry では、指定されたマルチリージョン内にストレージ バケットを作成します。このバケットは、レジストリの基盤となるストレージです。1 つのプロジェクト内では、ホスト名が同じであるすべてのレジストリが 1 つのストレージ バケットを共有します。

  • PROJECT-ID は、Google Cloud Console プロジェクト ID です。プロジェクト ID にコロン（:）が含まれている場合は、下記のドメインをスコープとするプロジェクトをご覧ください。

  • IMAGE はイメージの名前です。イメージのローカル名とは別の名前にできます。Google Cloud Console では、プロジェクトのレジストリはイメージ名で一覧表示されます。各リポジトリでは、名前が同じである複数のイメージを保持できます。たとえば、名前が「my-image」であるイメージの異なるバージョンを保持できます。

  • 末尾に :TAG または @IMAGE-DIGEST のいずれかを追加すると、イメージの特定のバージョンを区別できますが、省略することもできます。タグまたはダイジェストを指定しなかった場合、Container Registry はデフォルトのタグ latest が付いたイメージを探します。下記のレジストリ内のイメージのバージョンをご覧ください。

レジストリ gcr.io/PROJECT-ID 内のイメージ my-image の場合、次の形式を使用してイメージを push または pull します。

gcr.io/PROJECT-ID/my-image:tag1

PROJECT-ID は、Google Cloud Console プロジェクト ID です。

リポジトリを使用したイメージの整理

レジストリ内のリポジトリに基づき関連イメージをグループ化できます。イメージにタグ付け、push、pull するときに、イメージパス内のプロジェクトに基づきリポジトリ名を指定します。

Container Registry では、リポジトリは整理の助けになります。それらはイメージパス中では論理フォルダのように機能しますが、実際のファイル システム構造を反映しませんし、よりきめ細かなアクセス制御はサポートしません。

プロジェクト builds のホスト us.gcr.io に保存されている次のイメージについて考えてみます。

us.gcr.io/builds/product1/dev/product1-app:beta-2.0
us.gcr.io/builds/product1/stable/product1:1.0
us.gcr.io/builds/product2/dev/product2:alpha
us.gcr.io/builds/product2/stable/product2:1.0

ユーザーが builds プロジェクトの us.gcr.io ホストへの書き込みアクセス権を持つ場合、すべてのイメージが同じストレージ バケットにあるため、us.gcr.io/builds の下の任意のパスへの書き込みアクセス権があります。リポジトリ レベルやイメージレベルでアクセスを制限することはできません。

よりきめ細かなアクセス制御が必要な場合は、代わりに Artifact Registry を使用できます。Artifact Registry では、リポジトリは独立したリソースであるため、us-docker.pkg.dev/builds/product1 や us-docker.pkg.dev/builds/product2 などのリポジトリに個別の IAM ポリシーを適用できます。

レジストリ内のイメージのバージョン

1 つのレジストリには多くのイメージを含めることができ、それらはバージョンの異なる場合があります。レジストリ内でイメージの特定のバージョンを識別するには、イメージタグまたはダイジェストを指定します。

  • タグはラベルとして機能します。1 つのイメージに複数のタグを適用できます。たとえば、イメージにバージョン番号用の v1.5 タグと、最終テストの準備状況を示す release-candidate タグが付いている場合があります。
  • ダイジェストは自動的に生成されます。これは、イメージのバージョンに固有のものであり、@IMAGE-DIGEST の形式になります。IMAGE-DIGEST は、イメージ コンテンツの sha256 ハッシュ値です。

イメージ my-image の特定のバージョンを指定する手順は、次のとおりです。

  • イメージタグを追加します。

    gcr.io/PROJECT-ID/my-image:tag1

  • または、イメージのダイジェストを追加します。

    gcr.io/PROJECT-ID/my-image@sha256:4d11e24ba8a615cc85a535daa17b47d3c0219f7eeb2b8208896704ad7f88ae2d

PROJECT-ID は、Google Cloud Console プロジェクト ID です。プロジェクト ID にコロン（:）が含まれている場合は、下記のドメインをスコープとするプロジェクトをご覧ください。

Google Cloud コンソールの [イメージ] 画面で、[タグ] 列にイメージのタグが一覧表示されます。イメージのバージョンをクリックすると、メタデータ（イメージ ダイジェストを含む）が表示されます。

タグの変更方法については、イメージにタグを付けるをご覧ください。

ドメインをスコープとするプロジェクト

プロジェクトのスコープがドメインに設定されている場合、プロジェクト ID に含まれるドメインの名前の後にコロン（:）が続いています。Docker でのコロンの処理方法の関係で、Container Registry でイメージ ダイジェストを指定する場合は、コロン文字をスラッシュで置き換える必要があります。このようなプロジェクトのイメージを指定する場合は、次の形式を使用します。

HOSTNAME/[DOMAIN]/[PROJECT]/IMAGE

たとえば、ID が example.com:my-project のプロジェクトには、次のイメージが含まれる場合があります。

gcr.io/example.com/my-project/image-name

URL としてのレジストリ名

URL https://HOSTNAME/PROJECT-ID/IMAGE は、Google Cloud コンソール内のイメージの URL です。レジストリ ホストへのアクセス権限を持つ認証済みのユーザーは、リンクを使用して保存されているイメージを表示できます。イメージパスの形式の詳細については、レジストリをご覧ください。

たとえば、次の URL は Google Cloud コンソール内の公開レジストリにリンクしています。

Container のイメージ形式

Container Registry は、Docker イメージ マニフェスト V2 と OCI イメージをサポートしています。 詳細については、Container のイメージ形式をご覧ください。

イメージや他のタイプのアーティファクトを一元的に保存する場合は、Container Registry ではなく Artifact Registry の使用を検討してください。

アクセス制御

Container Registry は自身と同じプロジェクト内の Cloud Storage バケットにコンテナ イメージのタグとレイヤファイルを格納します。バケットへのアクセスは、Cloud Storage の Identity and Access Management（IAM）で構成します。

レジストリ ホストにアクセスできるユーザーは、ホストのストレージ バケット内の任意のイメージにアクセスできます。よりきめ細かいアクセス制御が必要な場合は、Artifact Registry の使用を検討してください。Artifact Registry は、リポジトリ レベルのアクセス制御を提供します。

デフォルトでは、プロジェクトのオーナーと編集者にプロジェクトの Container Registry バケットに対する push および pull 権限が付与されます。プロジェクト閲覧者にはイメージの pull 権限のみが付与されます。

Container Registry の権限の詳細については、アクセス制御の構成をご覧ください。

Cloud Storage から高性能なバックエンド データベースへのイメージ メタデータの移動計画については、Container Registry 非推奨のお知らせをご覧ください。

認証

イメージを push または pull するには、その前に、認証を構成する必要があります。Google Cloud CLI を使用して Container Registry へのリクエストを認証するように Docker を構成できます。Container Registry では、アクセス トークンまたは JSON 鍵ファイルを使用した高度な認証方式もサポートしています。

Docker 認証ヘルパー

Docker は、イメージを push および pull するために Container Registry にアクセスする必要があります。Docker 認証ヘルパー コマンドライン ツールを使用して、Docker で使用するための Container Registry 認証情報を構成できます。

認証ヘルパーは、Container Registry 認証情報を自動的に、または --token-source フラグで指定したロケーションからフェッチし、それらを Docker の構成ファイルに書き込みます。この方法で、Docker のコマンドライン ツール docker を使用して、Container Registry を直接操作できます。

詳細については、高度な認証をご覧ください。

Container Registry サービス アカウント

Container Registry API を有効にすると、Container Registry はプロジェクトにサービス アカウントを追加します。このサービス アカウントには次の ID があります。

service-[PROJECT_NUMBER]@containerregistry.iam.gserviceaccount.com

Container Registry サービス アカウントは、プロジェクトでサービスに関して必要な処理を実行するための Container Registry 専用のサービス アカウントです。Google はこのアカウントを管理していますが、このアカウントはプロジェクトに固有のものです。

このサービス アカウントを削除したり、その権限を変更したりすると、Container Registry の一部の機能は正常に動作しなくなります。役割を変更したり、アカウントを削除したりしないでください。

このサービス アカウントとその権限の詳細については、Container Registry サービス アカウントをご覧ください。

プルスルー キャッシュ

mirror.gcr.io レジストリは、頻繁にリクエストされる公開イメージを Docker Hub からキャッシュします。

キャッシュに保存されたイメージを使用すると、Docker Hub から pull を高速化できます。クライアントは、Docker Hub から直接 pull する前に、Docker Hub イメージのキャッシュに保存されたコピーを常にチェックします。

詳細については、キャッシュに保存された Docker Hub イメージの pull をご覧ください。

通知

Pub/Sub を使用して、コンテナ イメージの変更に関する通知を受け取ることができます。

詳細については、Pub/Sub 通知の構成をご覧ください。

Google Cloud での Container Registry の使用

Compute Engine インスタンスと Google Kubernetes Engine クラスタは、インスタンスの Cloud Storage スコープに基づいて Container Registry イメージの push と pull を行います。Google Cloud での Container Registry の使用をご覧ください。

Container Registry に格納されているイメージは、App Engine フレキシブル環境にデプロイできます。

継続的デリバリー ツールの統合

Container Registry は、Cloud Build や Jenkins のようなサードパーティ ツールなど、広くく使用されている継続的インテグレーション / 継続的デリバリー システムと動作します。

Container Registry は、Google Cloud サービスとシームレスに統合されます。たとえば、デフォルトで Cloud Build は、同じプロジェクト内の Container Registry ホストから、イメージを push および pull できます。Google Kubernetes Engine や Cloud Run などのランタイム環境でも、デフォルトで同じプロジェクト内のレジストリ ホストから、イメージを pull できます。

また、他の方法としては、Jenkins などのサードパーティ ツールを使用して、イメージのビルド、pull、push を行うこともできます。サードパーティ ツールを使用する場合は、ツールの代わりに Container Registry とやり取りするアカウントの権限と認証を構成する必要があります。

統合の例については、Container Registry を含む Google Cloud のテクニカル ガイドをご覧ください。