標準リポジトリへの移行

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

以下の手順は主にリポジトリ管理者向けです。イメージのビルド、push、pull、デプロイの変更点については、次の情報をご覧ください。

始める前に

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

    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. 表示するレジストリ ホストのストレージ バケットをクリックします。バケット名では、Google Cloud のプロジェクト IDは PROJECT-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 へのアクセスが妥当である場合に、適切なロールを付与できます。

次の表に、事前定義された Cloud Storage ロールによって Container Registry アクセスに付与される権限に基づいて、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 は、単一のプロジェクトで複数の 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. [削除] をクリックします。確認ダイアログボックスが表示されます。

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

gcloud

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

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

gcloud storage rm gs://BUCKET-NAME --recursive

BUCKET-NAME を Container Registry ストレージのバケット名に置き換えます。バケット名では、Google Cloud のプロジェクト IDは PROJECT-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 を使用していない場合も同様です。

次のステップ