gcr.io ドメインをサポートするリポジトリを設定する

Artifact Registry は、既存の Container Registry イメージをホストし、gcr.io ホストのリクエストを対応する Artifact Registry リポジトリに自動的にリダイレクトできます。リダイレクトでは、既存の自動化とワークフローの gcr.io ドメインでイメージパスを引き続き使用できます。

始める前に

Google Cloud CLI がまだインストールされていない場合は、インストールします。既存のインストールの場合は、次のコマンドを実行してコンポーネントを最新バージョンに更新します。
```
gcloud components update
```
Artifact Registry API と Resource Manager API を有効にします。gcloud CLI は、Resource Manager API を使用して必要な権限を確認します。

次のコマンドを実行します。
```
gcloud services enable \
    cloudresourcemanager.googleapis.com \
    artifactregistry.googleapis.com
```
移行を開始する前に、Artifact Registry の料金をご覧ください。

必要なロール

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

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

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

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

制限事項

gcr.io ドメインサポートがあるリポジトリには、次の制限が適用されます。

Container Registry ホストを別のプロジェクトの Artifact Registry リポジトリにマッピングすることはできません。
各 Container Registry ホスト名は、同じマルチリージョン内の対応する Artifact Registry gcr.io リポジトリ 1 つにのみマッピングされます。
gcr.io リポジトリの名前は事前定義されており、変更できません。

リポジトリの場所をより詳細に制御するには、Artifact Registry pkg.dev ドメインの標準リポジトリに移行できます。標準リポジトリは gcr.io ドメインをサポートしていないため、この移行アプローチでは既存の自動化とワークフローに対してより多くの変更が必要になります。機能の違いについては、移行オプションを選択するをご覧ください。

リポジトリの作成

リダイレクトを有効にする前に、ユーザーのアクセス権を構成し、既存の Container Registry イメージを Artifact Registry にコピーできるように、gcr.io リポジトリを作成します。

リポジトリの迅速な作成

この手順では、Google が管理する暗号鍵で暗号化された gcr.io リポジトリを作成します。顧客管理の暗号鍵（CMEK）を使用する場合は、リポジトリを手動で作成する必要があります。

gcr.io リポジトリを作成するには:

Google Cloud コンソールで [リポジトリ] ページを開きます。

[リポジトリ] ページを開く

ページのバナーに「You have gcr.io repositories in Container Registry」というメッセージが表示されます。

設定ページを開く
バナーで、[gcr.io リポジトリの作成] をクリックします。

[gcr.io リポジトリの作成] パネルが開きます。[イメージのコピー] セクションに、作成される各リポジトリの完全修飾名が表示されます。リダイレクトを有効にする前に Container Registry からイメージをコピーする場合は、これらのリポジトリ名が必要になります。
[作成] をクリックします。

Artifact Registry では、すべての Container Registry ホスト名に対して gcr.io リポジトリが作成されます。

Container Registry ホスト名	Artifact Registry リポジトリ名
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

リポジトリの Artifact Registry URL をすばやく表示するには、リポジトリ名の横にある警告アイコン（）にカーソルを合わせます。

トラフィックを新しいリポジトリにリダイレクトする前に、既存の自動化がリポジトリにアクセスできることを確認する必要があります。次のステップでは、リポジトリへのアクセスを許可する権限を構成します。

リポジトリの手動作成

顧客管理の暗号鍵（CMEK）を使用してリポジトリのコンテンツを暗号化する場合、またはロケーションの制約が存在し、Google Cloud 組織で特定のロケーションでの新しいリソース作成がブロックされている場合は、gcr.io リポジトリを手動で作成します。

gcr.io リポジトリを手動で作成するには、次のようにします。

CMEK を使用している場合は、このリポジトリで使用する鍵を作成し、鍵を使用する権限を付与します。顧客管理の暗号鍵の有効化をご覧ください。
リポジトリを追加します。
コンソール
1. Google Cloud コンソールで [リポジトリ] ページを開きます。
  
  [リポジトリ] ページを開く
2. [リポジトリを作成] をクリックします。
3. リポジトリ名を指定します。
  
  Container Registry ホスト名 Artifact Registry リポジトリ名
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
4. Docker をリポジトリ形式として指定します。
5. [ロケーションタイプ] で、リポジトリのマルチリージョンを指定します。
  
  Container Registry ホスト名 Artifact Registry リポジトリの場所
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
6. リポジトリの説明を追加します。リポジトリの説明は暗号化されないため、機密データは含めないでください。
7. [暗号化] セクションで、リポジトリの暗号化方式を選択します。
  - Google が管理する鍵 - Google が管理する暗号鍵を使用してリポジトリのコンテンツを暗号化します。
  - 顧客管理の暗号鍵 - Cloud Key Management Service で管理する鍵を使用してリポジトリのコンテンツを暗号化します。鍵の設定手順については、リポジトリの CMEK の設定をご覧ください。
8. [作成] をクリックします。
gcloud
次のコマンドを実行して新しいリポジトリを作成します。
```
gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description=DESCRIPTION \
    --kms-key=KMS-KEY
```
次の値を置き換えます。
- REPOSITORY はリポジトリの名前です。
  
  Container Registry ホスト名 Artifact Registry リポジトリ名
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
- LOCATION は、リポジトリのマルチリージョンです。
  
  Container Registry ホスト名 Artifact Registry リポジトリの場所
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
- DESCRIPTION はリポジトリの説明です。リポジトリの説明は暗号化されないため、機密データは含めないでください。
- KMS-KEY は、リポジトリのコンテンツを暗号化するために顧客管理の暗号鍵を使用する場合、Cloud KMS 暗号鍵のフルパスです。パスの形式は次のとおりです。
```
projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY
```
  次の値を置き換えます。
  - KMS-PROJECT は、鍵が保存されているプロジェクトです。
  - KMS-LOCATION は鍵の場所です。
  - KEY-RING はキーリングの名前です。
  - KEY は、鍵の名前です。
次のコマンドでリポジトリを一覧表示することで、リポジトリが作成されたことを確認できます。
```
gcloud artifacts repositories list
```

Container Registry ホスト名	Artifact Registry リポジトリの場所
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

Container Registry ホスト名	Artifact Registry リポジトリの場所
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

リポジトリに権限を付与する

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

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

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

Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。
[バケット] に移動
表示するレジストリホストのストレージバケットをクリックします。バケット名では、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
[権限] タブをクリックします。
[Permissions] タブで、[View by role] サブタブをクリックします。
ロールを開いて、そのロールを持つプリンシパルを表示します。

このリストには、バケットに直接付与された 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 のロール	ロールを付与する場所
イメージの pull のみ（読み取り専用）	Storage オブジェクト閲覧者（`roles/storage.objectViewer`）	Artifact Registry 読み取り（`roles/artifactregistry.reader)`）	Artifact Registry リポジトリまたは Google Cloud プロジェクト
イメージの push と pull（読み取りと書き込み）画像の削除	Storage レガシーバケット書き込み（`roles/storage.legacyBucketWriter`）	Artifact Registry リポジトリ管理者（`roles/artifactregistry.repoAdmin)`）	Artifact Registry リポジトリまたは Google Cloud プロジェクト
プロジェクトでイメージが gcr.io ホスト名に初めて push されたときに、Artifact Registry で gcr.io リポジトリを作成する。	ストレージ管理者（`roles/storage.admin`）	Artifact Registry の Create-on-push リポジトリ管理者 `(roles/artifactregistry.createOnPushRepoAdmin)`	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 のロールを付与する手順については、ロールと権限を構成するをご覧ください。

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

既存のイメージを Container Registry から Artifact Registry にコピーします。最も高速で低価格な方法は、gcrane でイメージをコピーすることです。

イメージをコピーするには:

gcrane をダウンロードし、アーカイブファイルからツールを抽出します。バージョン 0.10.0 以降であることが必要です。インストールされている gcrane のバージョンを確認するには、次のコマンドを実行します。
```
gcrane version
```
ストレージバケットで Container Registry イメージを読み取ることができるように、Artifact Registry の Google が管理するサービスアカウントにストレージオブジェクト閲覧者のロール（roles/storage.objectViewer）を付与します。Container Registry からイメージをコピーする必要がなくなった場合は、このロールを削除できます。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='serviceAccount:service-PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com' \
    --role='roles/storage.objectViewer'
```
PROJECT_ID はプロジェクト ID に、PROJECT_NUMBER は Container Registry と Artifact Registry が実行されている Google Cloud プロジェクトのプロジェクト番号に置き換えます。

次のコマンドを実行して、イメージをコピーします。

gcr.io:

gcrane cp -r gcr.io/PROJECT_ID us-docker.pkg.dev/PROJECT_ID/gcr.io

asia.gcr.io:

gcrane cp -r asia.gcr.io/PROJECT_ID asia-docker.pkg.dev/PROJECT_ID/asia.gcr.io

eu.gcr.io:

gcrane cp -r eu.gcr.io/PROJECT_ID europe-docker.pkg.dev/PROJECT_ID/eu.gcr.io

us.gcr.io:

gcrane cp -r us.gcr.io/PROJECT_ID us-docker.pkg.dev/PROJECT_ID/us.gcr.io

Artifact Registry へのイメージのコピーが完了したら、次のコマンドを使用して、Artifact Registry サービスアカウントから Storage オブジェクト閲覧者のロールを削除できます。

gcloud projects remove-iam-policy-binding PROJECT_ID \
    --member='serviceAccount:service-PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com' \
    --role='roles/storage.objectViewer'

その他の機能を設定する

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

Artifact Analysis

Artifact Analysis は、Container Registry と Artifact Registry の両方をサポートしています。どちらのプロダクトも、イメージメタデータと脆弱性スキャンに同じ Artifact Analysis API を使用し、Artifact Analysis 通知に同じ Pub/Sub トピックを使用します。

ただし、次の操作はリダイレクトが有効な場合にのみ行うことができます。

Artifact Registry の gcr.io リポジトリの自動スキャン。
Pub/Sub 通知に gcr.io リポジトリアクティビティが含まれる。

引き続き gcloud container images コマンドを使用して、gcr.io イメージパスに関連付けられたメモとオカレンスを一覧表示できます。

Container Registry	Artifact Registry
サポートされている OS を含むイメージで、オンデマンドスキャンを使用して OS と言語パッケージの脆弱性をスキャンします。自動スキャンでは、OS の脆弱性情報のみが返されます。スキャンの種類について学習します。オンデマンドスキャン Google Cloud CLI の gcloud artifacts docker images Scanner コマンドは、ローカルイメージまたは Container Registry のイメージの脆弱性をスキャンします。 Google Cloud CLI の gcloud artifacts docker images list-vulnerabilities コマンドは、脆弱性スキャンの結果を返します。スキャンを実行すると、サポートされているオペレーティングシステムで Container Registry のイメージの OS と言語パッケージの脆弱性情報が返されます。自動スキャン Google Cloud CLI の gcloud container images コマンドには、脆弱性やその他のメタデータを含むスキャン結果を表示するためのフラグが含まれています。スキャンを実行すると、サポートされているオペレーティングシステムの Container Registry のイメージの OS 脆弱性情報のみが返されます。	オンデマンドスキャンと自動スキャンの両方を使用して、OS と言語パッケージの脆弱性をスキャンします。スキャンの種類について学習します。オンデマンドスキャン Google Cloud CLI の gcloud artifacts docker images Scanner コマンドは、ローカルイメージまたは Artifact Registry のイメージの脆弱性をスキャンします。 Google Cloud CLI の gcloud artifacts docker images list-vulnerabilities コマンドは、脆弱性スキャンの結果を返します。スキャンを実行すると、サポートされているオペレーティングシステムで Artifact Registry のイメージの OS と言語パッケージの脆弱性情報が返されます。自動スキャン Google Cloud CLI の gcloud artifacts docker images コマンドには、脆弱性やその他のメタデータを含むスキャン結果を表示するためのフラグが含まれています。スキャンを実行すると、サポートされているオペレーティングシステムでの Artifact Registry のイメージの OS 脆弱性情報と、サポートされているオペレーティングシステムとサポートされていないオペレーティングシステムの両方の言語パッケージの脆弱性情報が返されます。

Container Registry

Artifact Registry

サポートされている OS を含むイメージで、オンデマンドスキャンを使用して OS と言語パッケージの脆弱性をスキャンします。自動スキャンでは、OS の脆弱性情報のみが返されます。スキャンの種類について学習します。

オンデマンドスキャン

Google Cloud CLI の gcloud artifacts docker images Scanner コマンドは、ローカルイメージまたは Container Registry のイメージの脆弱性をスキャンします。
Google Cloud CLI の gcloud artifacts docker images list-vulnerabilities コマンドは、脆弱性スキャンの結果を返します。
スキャンを実行すると、サポートされているオペレーティングシステムで Container Registry のイメージの OS と言語パッケージの脆弱性情報が返されます。

自動スキャン

Google Cloud CLI の gcloud container images コマンドには、脆弱性やその他のメタデータを含むスキャン結果を表示するためのフラグが含まれています。
スキャンを実行すると、サポートされているオペレーティングシステムの Container Registry のイメージの OS 脆弱性情報のみが返されます。

オンデマンドスキャンと自動スキャンの両方を使用して、OS と言語パッケージの脆弱性をスキャンします。スキャンの種類について学習します。

オンデマンドスキャン

Google Cloud CLI の gcloud artifacts docker images Scanner コマンドは、ローカルイメージまたは Artifact Registry のイメージの脆弱性をスキャンします。
Google Cloud CLI の gcloud artifacts docker images list-vulnerabilities コマンドは、脆弱性スキャンの結果を返します。
スキャンを実行すると、サポートされているオペレーティングシステムで Artifact Registry のイメージの OS と言語パッケージの脆弱性情報が返されます。

自動スキャン

Google Cloud CLI の gcloud artifacts docker images コマンドには、脆弱性やその他のメタデータを含むスキャン結果を表示するためのフラグが含まれています。
スキャンを実行すると、サポートされているオペレーティングシステムでの Artifact Registry のイメージの OS 脆弱性情報と、サポートされているオペレーティングシステムとサポートされていないオペレーティングシステムの両方の言語パッケージの脆弱性情報が返されます。

Pub/Sub 通知

Artifact Registry は、Container Registry と同じ gcr トピックに変更を公開します。Artifact Registry と同じプロジェクトで Container Registry と Pub/Sub をすでに使用している場合は、追加の構成は必要ありません。ただし、リダイレクトを有効にするまで、Artifact Registry は gcr.io リポジトリのメッセージをパブリッシュしません。

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

gcr.io トラフィックのリダイレクトを有効にする

gcr.io リポジトリを作成し、サードパーティクライアントの権限と認証を構成したら、gcr.io トラフィックのリダイレクトを有効にできます。

リダイレクトを有効にした後、問題が発生した場合は、トラフィックを Container Registry にルーティングし、問題が解決してからもう一度リダイレクトを有効にできます。

リダイレクトを有効にする権限を確認する

リダイレクトを有効にするには、プロジェクトレベルで次の権限が必要です。

artifactregistry.projectsettings.update: Artifact Registry プロジェクト設定を更新する権限。この権限は、Artifact Registry 管理者のロール（roles/artifactregistry.admin）に含まれています。
storage.buckets.update - プロジェクト全体でストレージバケットを更新する権限。この権限は、ストレージ管理者のロール（roles/storage.admin）に含まれています。

これらの権限がない場合は、管理者にプロジェクトレベルで付与するよう依頼してください。

次のコマンドは、プロジェクトに Artifact Registry 管理者およびストレージ管理者のロールを付与します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/artifactregistry.admin'

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/storage.admin'

次の値を置き換えます。

PROJECT_ID は、Google Cloud プロジェクト ID です。
PRINCIPAL は、更新するアカウントのメールアドレスです。例: user:my-user@example.com

プロジェクトの設定を検証する

プロジェクトの設定を検証するには、次のコマンドを実行します。

gcloud artifacts settings enable-upgrade-redirection \
    --project=PROJECT_ID --dry-run

PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

Artifact Registry は、Container Registry ホスト名にマッピングされているリポジトリを確認します。

リダイレクトを有効にすると、Artifact Registry によって不足している gcr.io リポジトリが作成されるようにできますが、リダイレクトを有効にする前に確認できるように、最初に gcr.io リポジトリを作成することをおすすめします。

リポジトリレベルの権限を構成する
引き続き使用する Container Registry からイメージをコピーする
追加の構成を行います。

リダイレクトをオンにする

gcr.io トラフィックのリダイレクトをオンにするには:

Console

Google Cloud コンソールで [設定] ページを開きます。

設定ページを開く
[Artifact Registry にルーティング] をクリックします。

gcloud

リダイレクトを有効にするには、次のコマンドを実行します。

gcloud artifacts settings enable-upgrade-redirection \
    --project=PROJECT_ID

PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

Artifact Registry でリダイレクトの有効化が開始されます。

リダイレクトの現在のステータスを確認するには、次のコマンドを実行します。

gcloud artifacts settings describe

リダイレクトが有効な場合、結果は次のようになります。

legacyRedirectionState: REDIRECTION_FROM_GCR_IO_ENABLED

すべての Container Registry ホスト名に対して gcr.io リポジトリを作成していない場合でも、gcr.io、asia.gcr.io、eu.gcr.io、us.gcr.io へのすべてのトラフィックがリダイレクトされます。対応する Artifact Registry リポジトリがないホスト名にイメージを push すると、artifactregistry.repositories.createOnPush 権限を持つロールがユーザーに付与されている場合に、Artifact Registry はリポジトリを作成します。事前定義ロールの Create-on-push Writer（artifactregistry.createOnPushWriter）と Create-on-push リポジトリ管理者（artifactregistry.createOnPushRepoAdmin）には、この権限が付与されています。

リダイレクトを有効にすると、新しい gcr.io リポジトリを使用して自動化をテストし、イメージを push および pull できるかどうかを確認できます。必要に応じて、トラフィックを Container Registry にルーティングし、テストを続行する準備ができたら、リダイレクトを再度有効にできます。

Container Registry にトラフィックを戻すルーティング

必要に応じて、gcr.io トラフィックを Container Registry に戻すルーティングを行うことができます。準備ができたら、リダイレクトを有効にできます。

Console

Google Cloud コンソールで [設定] ページを開きます。

設定ページを開く
[Container Registry にルーティングを戻す] をクリックします。

gcloud

次のコマンドを実行します。
```
gcloud artifacts settings disable-upgrade-redirection \
    --project=PROJECT_ID
```
PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

Artifact Registry から確認を求められます。
Container Registry への再ルーティングを確認するには、「y」と入力します。

リダイレクトを確認する

gcr.io ホスト名への pull リクエストと push リクエストが機能していることを確認します。

gcr.io パスを使用して、gcr.io リポジトリの 1 つにテストイメージを push します。
1. gcr.io パスを使用してイメージにタグを付けます。たとえば、次のコマンドではイメージ local-image に us.gcr.io/my-project/test-image というタグが付けられます。
```
docker tag local-image us.gcr.io/my-project/test-image
```
2. タグ付きイメージを push します。たとえば、次のコマンドはイメージ us.gcr.io/my-project/test-image を push します。
```
docker push us.gcr.io/my-project/test-image
```
リポジトリ内のイメージを一覧表示して、イメージが正常にアップロードされたことを確認します。たとえば、us.gcr.io/my-project 内のイメージを一覧表示するには、次のコマンドを実行します。
```
gcloud container images list --repository=us.gcr.io/my-project
```
Container Registry パスを使用してリポジトリからイメージを pull します。たとえば、このコマンドはイメージ us.gcr.io/my-project/test-image を pull します。
```
docker pull us.gcr.io/my-project/test-image
```

この初期テストの後、イメージのビルドとデプロイを行う既存の自動化が期待どおりに機能することを確認します。

Container Registry を使用するユーザーとサービスアカウントは、リダイレクトが有効な場合でも、イメージの push、pull、デプロイを行うことができます。
自動化は、イメージを既存のリポジトリにのみ push します。
Artifact Analysis の脆弱性スキャンが有効になっている場合、スキャンによって gcr.io リポジトリに脆弱性が存在するイメージが特定されます。
Binary Authorization を使用する場合、既存のポリシーが gcr.io リポジトリからデプロイされたイメージに対して正しく機能します。
構成済みの Pub/Sub サブスクリプションには、gcr.io リポジトリの変更に関する通知が含まれます。

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

リダイレクトが有効な場合、gcr.io パス内のイメージを削除するコマンドで、対応する Artifact Registry gcr.io リポジトリ内のイメージを削除します。Container Registry ホストに保存されているイメージは削除されません。すべての Container Registry イメージを安全に削除するには、Container Registry の各ホスト名の Cloud Storage バケットを削除します。

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

コンソール

Google Cloud コンソールの [Cloud Storage] ページに移動します。
削除するストレージバケットを選択します。バケット名で、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
[Delete] をクリックします。確認ダイアログボックスが表示されます。
削除を確定するには、バケット名を入力してから [削除] をクリックします。

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 を使用していない場合でも、依存関係が構成された同じプロジェクト内のサービスが自動的に無効になります。

次のステップ

Docker クイックスタートを試す。
gcr.io リポジトリについて学習する。