Container Registry からの移行

Artifact Registry は Container Registry が進化したものです。Artifact Registry は、コンテナ イメージとコンテナ以外のアーティファクトの両方をサポートするフルマネージド サービスとして、Container Registry の機能を拡張します。

現在 Container Registry を使用されいる場合は、このページの情報を活用して Artifact Registry への移行についてご確認ください。

概要

Artifact Registry には、Container Registry と同じコンテナ管理機能が用意されています。コンテナで Artifact Registry を使用するため、自動化の移行を開始できます。

下位互換性と共存

同じプロジェクトで Artifact Registry と Container Registry の両方を使用できます。gcloud または Cloud Console を使用してリポジトリのリストを表示すると、Artifact Registry は同じプロジェクト内の Container Registry リポジトリもリスト表示します。

Artifact Registry が一般提供になった後でも、どちらのサービスも共存し続けられます。Artifact Registry の拡張機能を活用するには、コンテナと自動化を Artifact Registry に移行します。

Artifact Registry が一般提供になった後に、下位互換性のあるリポジトリを使用して Google Cloud Storage とやり取りできます。これらのリポジトリを使用すると、以下のサポートにより、ビルドやデプロイの自動化のための段階的な更新を行うことができます。

  • gcloud container images コマンド
  • *.pkg.dev または *.gcr.io ホスト名でのリポジトリ参照

互換性を確保するために、これらのリポジトリの一部の機能が制限されます。特に、下位互換性のある各リポジトリは、プロジェクト内の対応する Container Registry ホスト名と同じマルチリージョンに配置する必要があります。

リポジトリの設定

Artifact Registry では、イメージを push する前にリポジトリを作成する必要があります。Artifact Registry に移行する際の重要な点は、Artifact Registry リポジトリを設定し、それを CI / CD の自動化に統合することです。

柔軟性を高めるため、Artifact Registry でリポジトリが表現される方法が変更されました。

Container Registry

各マルチリージョン ロケーションは、単一のストレージ バケットに関連付けられています。必要に応じて、イメージをホスト名の下のリポジトリに整理できます。次の例では、3 つの場所でイメージ webapp が表示されています。

us.gcr.io/my-project/webapp
us.gcr.io/my-project/team1/webapp
us.gcr.io/my-project/team2/webapp

リポジトリは単なる整理メカニズムであり、アクセスは制限されません。このプロジェクトの us.gcr.io バケットのストレージ バケットにアクセスできるユーザーは、webapp コンテナ イメージのすべてのバージョンにアクセスできます。

Artifact Registry

各リポジトリは、プロジェクト内の別個のリソースです。各リポジトリは一意のリソースであるため、次のことができます。

  • 各リポジトリに名前、説明、ラベルを付ける
  • 同じ場所に複数のリポジトリを作成する
  • リポジトリ固有の権限を設定する

また、リポジトリの場所はリージョンまたはマルチリージョンになります。

これらの変更により、リポジトリをより細かく制御できます。たとえば、サンパウロとシドニーにチームがある場合、最も近いマルチリージョンのロケーションよりも地理的に近いリージョンに各チームのリポジトリを作成できます。

southamerica-east1-docker.pkg.dev/my-project/team1/webapp
australia-southeast1-docker.pkg.dev/my-project/team2/webapp

各チームには、チーム リポジトリに対する権限のみを付与できます。

Artifact Registry への移行手順については、セットアップ ガイドをご覧ください。

機能の比較

このセクションでは、Container Registry の機能の変更点と改善について概要を説明します。

Artifact Registry が一般提供された後、Artifact Registry には、*-docker.pkg.dev ホスト名と *.gcr.io ホスト名のどちらでも参照できる下位互換性のあるリポジトリを作成するオプションが提供されます。

機能 Container Registry Artifact Registry
サポートされているファイル形式 コンテナ イメージのみ コンテナ イメージ、Java パッケージ、Node.js モジュールなど、複数のアーティファクト形式
リポジトリ
  • 作成 - これまでイメージを push したことがない場合、マルチリージョンにリポジトリを自動的に作成します。
  • ロケーション - マルチリージョン リポジトリのみ。
  • 組織 - Google Cloud プロジェクト内の同じマルチリージョン ホスト上のリポジトリはすべて、単一のストレージ バケットを共有します。
  • アクセス制御 - プロジェクト レベルまたはマルチリージョン ホストごとにストレージ バケットに対して権限を付与します。
  • 作成 - イメージを push する前にリポジトリを作成する必要があります。
  • ロケーション - マルチリージョンまたはリージョン リポジトリ。たとえば、オーストラリアに最も近いマルチリージョンはアジアです。リージョンのサポートで、シドニー データセンターにリポジトリを作成できます。
  • 組織 - リージョンまたはマルチリージョンごとに、個別のリポジトリを作成できます。ラベルを適用して、チーム、開発段階、その他のカテゴリ別にグループ化します。
  • アクセス制御 - プロジェクトまたは個々のリポジトリに対する権限を付与します。
ホスト名 ホストは gcr.io ドメインにあります。 ホストは pkg.dev ドメインにあります。名前の形式の詳細については、リポジトリとアーティファクトの名前をご覧ください。
権限
  • Cloud Storage の権限を使用してアクセス権を付与する。
  • マルチリージョン内に保存されているすべてのイメージへのアクセスを制限できますが、個々のリポジトリではアクセスを制限することはできません。たとえば、プロジェクト my-project では us.gcr.io へのアクセスを制限できますが、us.gcr.io/my-project/team1us.gcr.io/my-project/team2 のイメージには特定の権限を付与することはできません。
  • Artifact Registry の権限を使用してアクセス権を付与する。
  • 個々のリポジトリへのアクセスを制限できます。たとえば、us-docker.pkg.dev/my-project/team1us-docker.pkg.dev/my-project/team2 内のイメージへのアクセスを個別に制御できます。
認証 サードパーティのクライアントがイメージを push および pull するための複数の認証方法を提供します。 Artifact Registry は、Container Registry と同じ認証方法をサポートしています。詳しくは、Docker に対する認証の設定をご覧ください。

Docker 認証ヘルパーを使用する場合:

  • バージョン 2.0.0 以降が必要です。
  • v18.03 より前のバージョンの Docker クライアントのサポートは終了しました。
  • 認証ヘルパー構成に使用する Artifact Registry の場所を追加する必要があります。
顧客管理の暗号鍵(CMEK) CMEK を使用して、イメージを含むストレージ バケットを暗号化する。 個々のリポジトリを暗号化するには、CMEK を使用します。
Google Cloud Console の使用 Cloud Console の Container Registry セクションから Container Registry イメージを表示、管理します。 Cloud Console の Artifact Registry セクションで、Artifact Registry と Container Registry リポジトリのリストを表示します。このページから Artifact Registry リポジトリとイメージを管理します。

Container Registry リポジトリをクリックすると、Cloud Console の [Container Registry] セクションのイメージが一覧表示されます。

gcloud と API コマンドを使用する。 gcloud container images コマンドを使用する。 gcloud artifacts docker コマンドを使用する。

Artifact Registry が一般公開された後、Artifact Registry には gcloud container images commands をサポートする下位互換性のあるリポジトリを作成するオプションが提供されます。

Container Registry と Artifact Registry の gcloud コマンドの比較については、gcloud コマンドの比較をご覧ください。

Artifact Registry には、すべての形式でリポジトリとアーティファクトを管理するための API も含まれています。

Pub/Sub 通知 gcr トピックの変更を公開します。 gcr トピックの変更を公開します。既存の Container Registry サービスと同じプロジェクトにリポジトリを作成すると、既存の Pub/Sub 構成が自動的に機能します。

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

キャッシュされた Docker Hub のイメージ mirror.gcr.io で最も多くリクエストされる Docker Hub イメージをキャッシュに保存します。 mirror.gcr.io では引き続き、Docker Hub から頻繁にリクエストされるイメージがキャッシュされます。
VPC Service Controls サービス境界に Container Registry を追加できます。 サービス境界に Artifact Registry を追加できます。
メタデータ ストレージと分析 Container Analysis では、メタデータ ストレージ、脆弱性スキャンに加えて、Binary Authorization などのメタデータを使用するサービスとの統合が提供されます。メモとオカレンスを操作するための Cloud SDK コマンドは、gcloud container images グループにあります。 Container Analysis は、Artifact Registry と Container Registry の両方で、コンテナ イメージのメタデータ保存と脆弱性スキャンをサポートしています。
  • どちらのプロダクトも同じ Container Analysis API を使用します。Container Registry または Artifact Registry のどちらかで Container Analysis API を 有効にすると、両方のプロダクトで API が有効になります。
  • どちらのプロダクトも、Pub/Sub 通知に同じ「gcr」トピックを使用します。つまり、「gcr」トピックへの既存のサブスクリプションには、Artifact Registry と Container Registry の両方の通知が含まれています。
  • メモとオカレンスを操作するための Cloud SDK コマンドは、gcloud artifacts docker グループにあります。
Google 提供のイメージ Google が提供するイメージは gcr.io でホストされます。次に例を示します。 Google が提供するイメージは、引き続き gcr.io で利用できます。
料金 Container Registry の料金は、ストレージと外向きネットワークを含む Cloud Storage の使用量に基づいています。 Artifact Registry では、ストレージと外向きネットワークに基づいて独自の料金が設定されています。