Artifact Registry は、Google Cloud でのコンテナ イメージの保存と管理に推奨されるサービスです。Artifact Registry は、コンテナ イメージとコンテナ以外のアーティファクトの両方をサポートするフルマネージド サービスとして、Container Registry の機能を拡張します。
現在 Container Registry を使用されている場合は、このページの情報を活用して Artifact Registry への移行についてご確認ください。 Container Registry は引き続き Google Enterprise API として利用でき、サポートされますが、新しい機能は Artifact Registry でのみ使用できます。Container Registry には、重要なセキュリティ修正のみ与えられます。
概要
Artifact Registry は、Container Registry と同じコンテナ管理機能を備え、次の機能を備えています。
- その他のアーティファクト形式
次のアーティファクト形式のリポジトリを作成できます。
- リージョン レポジトリ
Container Registry は、マルチリージョン レジストリ ホストのみを提供します。Artifact Registry は、リージョン ホストとマルチリージョン レジストリ ホストを提供します。
- 1 つの場所での複数の独立したリポジトリ
Container Registry では、マルチリージョンで 1 つのレジストリホストのみを作成し、レジストリ内のすべてのリポジトリで同じストレージ バケットを共有します。Artifact Registry では、各リポジトリは別々のリソースです。リポジトリごとに異なるラベルと Identity and Access Management ポリシーを適用できます。
- リポジトリレベルの権限
Container Registry では、各マルチリージョン レジストリ ホストに権限を付与します。リポジトリ レベルで別の権限を適用することはできません。 Artifact Registry は、リポジトリ レベルのアクセス制御を提供します。
- Artifact Registry の IAM ロール
Container Registry では、Cloud Storage のロールを使用してアクセスを制御します。ホストに権限を構成する前に、イメージをレジストリホストに push する必要があります。Artifact Registry では、Artifact Registry のロールを使用してアクセス権を付与します。また、リポジトリ管理者とリポジトリ ユーザーのロールは明確に区別されています。
- Google Kubernetes Engine イメージ ストリーミング
GKE は、アプリケーションからのリクエストに応じてデータを有効なイメージからストリーミングできるため、イメージ全体をダウンロードするのを待たずにワークロードを初期化できます。イメージ ストリーミング。自動スケーリングと Pod の起動を高速化し、大きなイメージを pull する際のレイテンシを短縮できます。
- Cloud Run ソースのデプロイ
1 つの Google Cloud CLI コマンドを使用して、ソースコードから新しいサービスと新しいリビジョンを Cloud Run に直接デプロイします。ソースのデプロイは、コードからコンテナ イメージをビルドして Artifact Registry に保存し、Cloud Run にデプロイします。
下位互換性と共存
同じプロジェクトで Artifact Registry と Container Registry の両方を使用できます。gcloud または Google Cloud コンソールでリポジトリのリストを表示すると、Artifact Registry には同じプロジェクト内の Container Registry リポジトリも表示されます。
Artifact Registry の拡張機能を活用するには、コンテナと自動化を Artifact Registry に移行します。
移行オプション
次のいずれかの方法で Artifact Registry に移行できます。
- 標準リポジトリ（推奨）
- すべての機能をサポートし、既存の Container Registry ホストから完全に独立している通常の Artifact Registry リポジトリ。
- gcr.io ドメインをサポートするリポジトリ
Container Registry の
gcr.ioホスト名にマッピングされる特別なリポジトリ。これらのリポジトリは、gcr.ioホスト名から、プロジェクト内の対応する gcr.io リポジトリにトラフィックをリダイレクトすることをサポートしています。これらのリポジトリには、いくつかの機能の制限があります。ただし、
gcr.io参照を使用するツールの構成、スクリプト、コードが多数ある場合は、Artifact Registry への移行に際して、より戦術的なアプローチが必要になることがあります。
両方のタイプのリポジトリを共存できるため、段階的に移行できます。次に例を示します。
- Artifact Registry に gcr.io リポジトリを作成して、既存の Container Registry の設定を移行し、新しい作業用の標準リポジトリを作成できます。
- 移行には多段階アプローチを使用できます。Artifact Registry の gcr.io リポジトリに移行し、Artifact Registry リポジトリとイメージパスを完全にサポートするように自動化を更新しながら、標準リポジトリの使用に段階的に移行します。
リポジトリの設定
Artifact Registry では、イメージを push する前にリポジトリを作成する必要があります。したがって、Artifact Registry への移行で重要な部分は、Artifact Registry リポジトリを設定して、CI/CD 自動化に統合することです。
柔軟性を高めるため、Artifact Registry でリポジトリが表現される方法が変更されました。
- Container Registry
各マルチリージョン ロケーションは、1 つのストレージ バケットに関連付けられます。ホスト名でイメージをリポジトリに編成することは任意です。次の例では、イメージ
webappが 3 つの場所に表示されています。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 への移行手順については、設定ガイドをご覧ください。
イメージの push と pull
以下の情報は、Container Registry 用に設計された既存の構成、コマンド、ドキュメントに対応するために、イメージのビルド、push、pull、デプロイを比較したものです。
機能の比較
このセクションでは、Container Registry の機能の変更点と改善について概要を説明します。
| 特徴 | Container Registry | Artifact Registry |
|---|---|---|
| サポートされているファイル形式 | コンテナ イメージのみ | コンテナ イメージ、言語パッケージ、OS パッケージなど、複数のアーティファクト形式。 |
| リポジトリ |
|
|
| ホスト名 | ホストは gcr.io ドメインにあります。 |
ホストは pkg.dev ドメインにあります。名前形式の詳細については、リポジトリとアーティファクト名をご覧ください。
gcr.io ドメイン サポートを使用して、 |
| 権限 |
|
|
| Authentication | サードパーティのクライアントがイメージを push および pull するための複数の認証方法を提供します。 | Artifact Registry では、Container Registry と同じ認証方法がサポートされています。詳細については、Docker の認証の設定をご覧ください。
Docker 認証ヘルパーを使用する場合:
|
| 顧客管理の暗号鍵（CMEK） | CMEK を使用して、イメージを含むストレージ バケットを暗号化します。 | CMEK を使用して個々のリポジトリを暗号化します。 |
| Google Cloud コンソールの使用 | Google Cloud コンソールの [Container Registry] セクションで、Container Registry イメージを表示して管理します。 | Google Cloud コンソールの [Artifact Registry] セクションで、Artifact Registry リポジトリと Container Registry リポジトリのリストを表示します。このページから Artifact Registry リポジトリとイメージを管理します。
Container Registry リポジトリをクリックすると、Google Cloud コンソールの [Container Registry] セクションのイメージのリストに誘導されます。 |
| gcloud と API コマンドを使用する。 | gcloud container images コマンドを使用します。コマンドは短縮ダイジェストをサポートしています。完全なダイジェスト文字列を指定しない場合、Container Registry は部分的な文字列に基づいて正しいイメージの検出を試みます。 | gcloud artifacts docker コマンドを使用する。 コマンドは短縮ダイジェストをサポートしていません。
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 によるメタデータの保存と分析 | サポートされている OS を含むイメージで、オンデマンド スキャンを使用して OS と言語パッケージの脆弱性をスキャンします。自動スキャンでは、OS の脆弱性情報のみが返されます。
スキャンの種類について学習します。
|
オンデマンド スキャンと自動スキャンの両方を使用して、OS と言語パッケージの脆弱性をスキャンします。
スキャンの種類について学習します。
|
| Google 提供のイメージ | Google が提供するイメージは gcr.io でホストされます。次に例を示します。
|
Google が提供するイメージは、引き続き gcr.io で利用できます。 |
| イメージ ストリーミング | 使用不可 | GKE は、Artifact Registry 内の対象イメージからデータをストリーミングし、自動スケーリングを高速化し、Pod の起動を高速化し、大きなイメージを pull する際のレイテンシを短縮します。 |
| Cloud Run ソースのデプロイ | 使用不可 | ソースデプロイでは、単一の gcloud CLI コマンドを使用して、ソースコードからコンテナ イメージをビルドし、Artifact Registry にイメージを保存して Cloud Run にデプロイできます。 |
| 料金 | Container Registry の料金は、ストレージと外向きネットワークを含む Cloud Storage の使用量に基づいています。 | Artifact Registry では、ストレージと外向きネットワークに基づいて独自の料金が設定されています。 |