標準リポジトリへの移行

現在、Container Registry を使用してコンテナ イメージを管理している場合、このページでは標準の Artifact Registry リポジトリの設定方法およびリポジトリと Container Registry の使用方法の相違について説明します。

これらの手順は主にリポジトリ管理者を対象としています。イメージのビルド、push、pull、デプロイの変更については、次の情報をご覧ください。

始める前に

  1. Artifact Registry API は、Google Cloud Console から、または次のコマンドを使用して有効にします。

    gcloud services enable artifactregistry.googleapis.com

  2. gcloud CLI がまだインストールされていない場合は、インストールします。既存のインストールの場合は、次のコマンドを実行してコンポーネントを最新バージョンに更新します。

    gcloud components update

  3. 移行を開始する前に、Artifact Registry の料金をご覧ください。

必要なロール

gcr.io リポジトリの設定に必要な権限を取得するには、Google Cloud プロジェクトに対する次の IAM ロールの付与を管理者に依頼してください。

  • Artifact Registry リポジトリを作成して、個々のリポジトリへのアクセス権を付与する場合: Artifact Registry 管理者（roles/artifactregistry.admin）
  • Cloud Storage ストレージ バケットに適用される既存の Container Registry 構成を閲覧して管理する場合: Storage 管理者（roles/storage.admin）
  • プロジェクト レベルでリポジトリへのアクセス権を付与する場合: プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）、またはフォルダ管理者（roles/resourcemanager.folderAdmin）や組織管理者（roles/resourcemanager.organizationAdmin）などの同等の権限を含むロール

ロールの付与の詳細については、アクセスの管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

概要

標準リポジトリは、すべての機能をサポートする通常の Artifact Registry リポジトリです。

わかりやすくするために、このページの手順では、Container Registry と Artifact Registry の両方が同じ Google Cloud プロジェクトにあることを前提としています。Artifact Registry への移行時に両方のサービスを継続できるため、設定手順を段階的に行い、自動化を更新できます。必要に応じて、別のプロジェクトに Artifact Registry を設定し、全般にわたって同一の手順を行うことができます。

Artifact Registry は gcr.io リポジトリも提供しています。これらのリポジトリは、既存のレジストリから対応する Artifact Registry リポジトリに gcr.io トラフィックをリダイレクトできます。これらは Container Registry との下位互換性がありますが、機能の制限もあります。ただし、gcr.io 参照を含むツール構成、スクリプト、コードが多い場合は、Artifact Registry に移行するために、より戦術的なアプローチが必要になることがあります。適切な決定を行うために、gcr.io ドメインをサポートするリポジトリの移行ドキュメントを確認してください。

更新の手順

このガイドでは、次の手順を行う方法について説明します。

  1. コンテナの Docker リポジトリを作成します。イメージを push する前にリポジトリを作成する必要があります。
  2. リポジトリに権限を付与します。
  3. 認証を構成して、新しいリポジトリに接続できるようにします。
  4. 必要に応じて、新しいリポジトリで使用する Container Registry からイメージをコピーします。
  5. コンテナを push および pull してみてください。
  6. イメージをランタイム環境にデプロイしてみてください。
  7. その他の機能を構成します。
  8. 移行が完了したら、Container Registry のイメージをクリーンアップします。

リポジトリの作成

以前にイメージを push していない場合、Container Registry は、マルチリージョンにストレージ バケットを自動的に作成します。

Artifact Registry で、イメージをアップロードする前にリポジトリを作成する必要があります。リポジトリを作成する際は、以下の項目を指定する必要があります。

  • リポジトリの形式。Artifact Registry は Docker リポジトリにコンテナを保存します。

  • リポジトリのリージョンまたはマルチリージョンのロケーション。

    Artifact Registry リポジトリのロケーションを選択するときは、リポジトリと他のインフラストラクチャおよびユーザーとの近接性を考慮してください。Container Registry から Artifact Registry にイメージをコピーする場合、ロケーションの違いがコピーの費用に影響する可能性があります。

  • Cloud Key Management Service 鍵（暗号化に顧客管理の暗号鍵（CMEK）を使用している場合）。

    Container Registry で、CMEK を使用するように Container Registry ストレージ バケットを構成します。Artifact Registry では、リポジトリの作成時に CMEK を使用するようにリポジトリを構成します。Artifact Registry で CMEK を使用する方法については、顧客管理の暗号鍵の有効化をご覧ください。

Container Registry は、ドメイン gcr.io でコンテナをホストします。Artifact Registry は、ドメイン pkg.dev でコンテナをホストします。

暗号化に CMEK を使用するリポジトリなど、リポジトリの作成については、リポジトリの作成をご覧ください。

権限を付与する

Container Registry では、Cloud Storage のロールを使用してアクセスを制御します。Artifact Registry には独自の IAM ロールがあり、これらのロールは読み取り、書き込み、リポジトリ管理のロールを Container Registry よりも明確に分離しています。

ストレージ バケットに付与されている既存の権限を、推奨される Artifact Registry のロールにすばやくマッピングするには、ロール マッピング ツールを使用します。

また、Google Cloud コンソールを使用して、ストレージ バケットにアクセスできるプリンシパルのリストを表示することもできます。

  1. Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。

    [バケット] に移動

  2. 表示するレジストリ ホストのストレージ バケットをクリックします。バケット名の PROJECT-ID は、Google Cloud プロジェクト ID です。

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

  3. [権限] タブをクリックします。

  4. [Permissions] タブで、[View by role] サブタブをクリックします。

  5. ロールを開いて、そのロールを持つプリンシパルを表示します。

このリストには、バケットに直接付与された IAM のロールと、親プロジェクトから継承されたロールが含まれます。ロールに基づいて、最適な Artifact Registry のロールを選択して付与できます。

Cloud Storage と基本ロール

現在 Container Registry にアクセスしているユーザーとサービス アカウントに、Artifact Registry リポジトリへのアクセス権を付与します。親プロジェクトから継承された Cloud Storage のロールについては、プリンシパルが現在 Container Registry を使用していることを確認する必要があります。一部のプリンシパルは、Container Registry に関係のない他の Cloud Storage バケットにのみアクセスできる場合があります。

IAM の導入前から存在する基本ロールのオーナー、編集者、閲覧者は、ストレージ バケットへのアクセスが制限されています。それらのロールは本質的に名前が示すように Cloud Storage リソースに対するすべてのアクセス権を付与するものではなく、その他の Google Cloud サービスに対する追加の権限を付与します。Artifact Registry にアクセスする必要があるユーザーとサービス アカウントを確認します。ロールのマッピングの表を使用して、Artifact Registry へのアクセスが妥当である場合に、適切なロールを付与できます。

次の表に、Container Registry へのアクセス用に事前定義された Cloud Storage ロールによって付与される権限に基づいて、Artifact Registry のロールを示します。Artifact Registry のロールは、事前定義された Cloud Storage のロールでは使用できない権限を細分化して分離します。

必要なアクセス権 現在のロール Artifact Registry のロール ロールを付与する場所
イメージの pull のみ（読み取り専用） Storage オブジェクト閲覧者
（roles/storage.objectViewer）		 Artifact Registry 読み取り
（roles/artifactregistry.reader)）		 Artifact Registry リポジトリまたは Google Cloud プロジェクト
イメージの push と pull（読み取りと書き込み） Storage レガシー バケット書き込み
（roles/storage.legacyBucketWriter）		 Artifact Registry 書き込み
（roles/artifactregistry.writer)）		 Artifact Registry リポジトリまたは Google Cloud プロジェクト
イメージの push、pull、削除 Storage レガシー バケット書き込み
（roles/storage.legacyBucketWriter）		 Artifact Registry リポジトリ管理者
（roles/artifactregistry.repoAdmin)）		 Artifact Registry リポジトリまたは Google Cloud プロジェクト
リポジトリの作成、管理、削除 ストレージ管理者
（roles/storage.admin）		 Artifact Registry 管理者
(roles/artifactregistry.Admin)		 Google Cloud プロジェクト
プロジェクトから継承されたサービス エージェントのロール

Google Cloud サービスのデフォルトのサービス アカウントには、プロジェクト レベルで独自のロールが付与されています。たとえば、Cloud Run のサービス エージェントには Cloud Run サービス エージェントのロールがあります。

ほとんどの場合、これらのサービス エージェントのロールには Container Registry と Artifact Registry に対する同等のデフォルト権限が含まれています。既存の Container Registry サービスと同じプロジェクトで Artifact Registry を実行している場合は、追加の変更は必要ありません。

サービス エージェントのロールの権限について詳しくは、サービス エージェントのロールのリファレンスをご覧ください。

カスタムロール

ロールのマッピングの表を使用して、必要なアクセスレベルに基づいてユーザーまたはサービス アカウントに付与するロールを決定できます。

Artifact Registry のロールを付与する手順については、ロールと権限を構成するをご覧ください。

リポジトリに対して認証する

Artifact Registry は、Container Registry と同じ認証方法をサポートしています。

Docker 認証情報ヘルパーを使用している場合:

  • Artifact Registry リポジトリを操作するには、バージョン 2.0 以降を使用する必要があります。スタンドアロン バージョンは GitHub にあります。
  • 認証情報ヘルパーは、使用する Artifact Registry の場所を使用して構成する必要があります。デフォルトでは、認証情報ヘルパーは Container Registry ホストへのアクセスのみを構成します。

認証の設定の詳細については、Docker の認証の設定をご覧ください。

Container Registry からコンテナをコピーする

Container Registry に引き続き Artifact Registry で使用したいコンテナがある場合、それらをコピーする方法はいくつかあります。詳細な手順については、Container Registry からのイメージのコピーをご覧ください。

イメージを push および pull する

Artifact Registry 内のイメージのタグ付け、push、pull に使用する Docker コマンドは、Container Registry で使用するものと似ています。次の 2 つの主な違いがあります。

  • Artifact Registry Docker リポジトリのホスト名には、-docker.pkg.dev が続く、ロケーションの接頭辞があります。australia-southeast1-docker.pkg.dev、europe-north1-docker.pkg.dev、europe-docker.pkg.dev などがあります。
  • Artifact Registry は、1 つのプロジェクトで複数の Docker リポジトリをサポートしているため、コマンドではリポジトリ名を指定する必要があります。

たとえば、Container Registry では、このコマンドがイメージ my-image をプロジェクト my-project 内のレジストリ eu.gcr.io に push します。

docker push eu.gcr.io/my-project/my-image

Artifact Registry でこのコマンドは、イメージ my-image をリポジトリ my-repo とプロジェクト my-project のリージョン リポジトリ europe-north1-docker.pkg.dev に push します。

docker push europe-north1-docker.pkg.dev/my-project/my-repo/my-image

Artifact Registry でのイメージの push および pull の詳細については、イメージの push と pull をご覧ください。

イメージのデプロイ

一般的な Google Cloud 統合用のサービス アカウントは、同じプロジェクト内のリポジトリに対するデフォルトの権限で構成されます。

Cloud Build でイメージをビルドしリポジトリに push する方法は通常、Container Registry の場合と同じです。Artifact Registry の主な違いは、最初に push するイメージを含めて、イメージを push する前に、ターゲット リポジトリが存在している必要があります。

Docker コマンド docker push や Cloud Build コマンド gcloud builds submit など、イメージを push するコマンドを実行する前に、必要なリポジトリを作成するようにしてください。

Cloud Build ビルダーは、引き続き gcr.io でホストされます。詳細については、Cloud Build との統合をご覧ください。

その他の機能

このセクションでは、Container Registry で設定されているその他の機能の構成について説明します。

Artifact Analysis

Artifact Analysis は、Container Registry と Artifact Registry の両方をサポートしています。Artifact Analysis のドキュメントには、両方のプロダクトが含まれています。

  • どちらのプロダクトも同じ Artifact Analysis API を使用します。Container Registry または Artifact Registry で Artifact Analysis API を有効にすると、両方のプロダクトで API が有効になります。
  • どちらのプロダクトも、Artifact Analysis 通知に同じ Pub/Sub トピックを使用します。
  • 引き続き gcloud container images コマンドを使用して、gcr.io イメージパスに関連付けられたメモとオカレンスを一覧表示できます。
Container Registry Artifact Registry
サポートされている OS のイメージのオンデマンド スキャンで、OS と言語パッケージの脆弱性をスキャンします。自動スキャンでは、OS の脆弱性情報のみが返されます。 スキャンの種類について学習します。
オンデマンド スキャン
自動スキャン
 オンデマンド スキャンと自動スキャンの両方を使用して、OS や言語パッケージの脆弱性をスキャンします。 スキャンの種類について学習します。
オンデマンド スキャン
自動スキャン
  • Google Cloud CLI の gcloud artifacts docker images コマンドには、脆弱性やその他のメタデータを含むスキャン結果を表示するためのフラグが含まれています。
  • スキャンを実行すると、サポートされているオペレーティング システムでの Artifact Registry のイメージの OS 脆弱性情報と、サポートされているオペレーティング システムとサポートされていないオペレーティング システムの両方の言語パッケージの脆弱性情報が返されます。

Pub/Sub 通知

Artifact Registry は Container Registry と同じ gcr トピックに変更を公開します。すでに Artifact Registry と同じプロジェクトで Pub/Sub と Container Registry を併用している場合は、追加の構成は必要ありません。

別のプロジェクトで Artifact Registry を設定した場合は、gcr トピックが存在しない可能性があります。設定手順については、Pub/Sub 通知の構成をご覧ください。

サービス境界

VPC Service Controls を使用すると、Google マネージド サービスのリソースの周囲にセキュリティ境界を構成し、境界をまたぐデータの移動を制御できます。

手順については、サービス境界でのリポジトリの保護をご覧ください。

Container Registry イメージをクリーンアップする

Container Registry の使用を停止する準備ができたら、Container Registry のストレージ バケットを削除して、残りのイメージを削除します。

各 Container Registry ストレージ バケットを削除するには:

コンソール

  1. Google Cloud コンソールの [Cloud Storage] ページに移動します。

  2. 削除するストレージ バケットを選択します。バケット名で、PROJECT-ID は Google Cloud プロジェクト ID です。

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

  3. [Delete] をクリックします。確認ダイアログボックスが表示されます。

  4. 削除を確定するには、バケット名を入力して [削除] をクリックします。

gsutil

バケット内の数十万個以上のイメージを一括削除する場合は、削除プロセスに非常に時間がかかるため、gsutil の使用を避けてください。代わりに、Google Cloud コンソールを使用してオペレーションを実行します。

バケットを削除するには、gsutil rm コマンドを使用し、-r フラグを指定します。

gsutil rm -r gs://BUCKET-NAME

BUCKET-NAME は、Container Registry ストレージ バケット名に置き換えます。バケット名の PROJECT-ID は、Google Cloud プロジェクト ID です。

  • gcr.io: artifacts.PROJECT-ID.appspot.com
  • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
  • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
  • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

次の例のようなレスポンスになります。

Removing gs://artifacts.my-project.appspot.com/...

他の Google Cloud サービスが同じ Google Cloud プロジェクトで実行されている場合は、Container Registry API を有効にしたままにします。Container Registry API を無効化する場合。Container Registry では、依存関係が構成されている他のサービスがプロジェクト内で有効になっている場合、警告が表示されます。Container Registry API を無効にすると、これらのサービスで Container Registry を現在使用していなくても、依存関係が構成されている同じプロジェクト内のサービスが自動的に無効になります。

次のステップ