リポジトリの概要

Artifact Registry を使用すると、さまざまなアーティファクト タイプを格納し、単一のプロジェクトに複数のリポジトリを作成し、各リポジトリにリージョンやマルチリージョンを関連付けることができます。このページでは、リポジトリの場所と組織を計画する際に考慮すべき点について説明します。

ご自身のアーティファクトを作成するための内部プロセスと、リポジトリの作成時にコンシューマによるアーティファクトの使用の両方を考慮してください。

リポジトリ形式

各リポジトリは、特定のアーティファクト形式に関連付けられます。たとえば、Docker リポジトリには Docker イメージが保存されます。同じ Google Cloud プロジェクト内には、形式ごとに複数のリポジトリを作成できます。

リポジトリ モード

リポジトリのモードは複数あります。各モードはそれぞれ異なる目的を果たすため、リポジトリの作成後はリポジトリのモードを変更できません。

標準リポジトリ
標準リポジトリは、非公開アーティファクト用の通常の Artifact Registry リポジトリです。こうしたリポジトリで直接アーティファクトをアップロードしてダウンロードし、Artifact Analysis を使用して脆弱性や他のメタデータをスキャンします。
リモート リポジトリ

読み取り専用リポジトリ。Docker Hub、Maven Central、Python Package Index（PyPI）、Debian、CentOS などの事前設定された外部ソースからのアーティファクトや、ユーザー定義のソースを格納するプロキシの役割を果たします。アーティファクト バージョンを初めてリクエストすると、リポジトリは外部ソースからバージョンをダウンロードし、そのコピーをキャッシュに保存します。同じバージョンが再度リクエストされると、リポジトリはキャッシュに保存されたコピーを提供します。

リモート リポジトリにより、レイテンシが短縮され、Google Cloud 上のビルドとデプロイの可用性が向上します。また、Artifact Analysis を使用して、キャッシュに保存されているパッケージをスキャンし、脆弱性やその他のメタデータを検出することもできます。

仮想リポジトリ

読み取り専用リポジトリ。1 つ以上のアップストリーム リポジトリから同じ形式のアーティファクトをダウンロード、インストール、デプロイするための単一のアクセス ポイントとして機能します。アップストリーム リポジトリは、標準リポジトリ、リモート リポジトリ、または仮想リポジトリになります。

仮想リポジトリは、アーティファクトのコンシューマに対するクライアント構成を簡略化します。また、パブリック アーティファクトをキャッシュに保存するリモート リポジトリよりもプライベート アーティファクトを含むリポジトリを優先するようにアップストリーム ポリシーを構成することで、依存関係のかく乱攻撃を軽減することもできます。

リポジトリの使用例

次の図では、さまざまなモードのリポジトリを一緒に使用する方法の 1 つを示します。図には、2 つの Google Cloud プロジェクトにまたがるワークフローを示しています。開発プロジェクトでは、デベロッパーが Java アプリケーションをビルドします。別のランタイム プロジェクトでは、別のビルドによりアプリケーションを含むコンテナ イメージを作成し、Google Kubernetes Engine にデプロイします。

2 つのプロジェクトで使用される標準リポジトリ、仮想リポジトリ、リモート リポジトリ。

  1. 開発プロジェクトで、Java 開発チームが Cloud Build を使用して Java アプリケーションを構築します。

    • ビルドでは、仮想リポジトリを使用してパブリック Java の依存関係をリクエストできます。仮想リポジトリは、リモート リポジトリ（Maven Central のキャッシュ プロキシ）から依存関係を提供します。
    • Cloud Build は、パッケージをコンポーネント プロジェクトの標準の Maven リポジトリにアップロードします。

  2. ランタイム プロジェクトで、Cloud Build が Java アプリケーションをコンテナ化します。

    ビルドは、Maven 仮想リポジトリを使用してアプリケーションをダウンロードします。仮想リポジトリは、開発プロジェクトの標準リポジトリからパッケージを提供します。ビルドでは、同じ仮想リポジトリからパブリック Java の依存関係をダウンロードすることもできます。

  3. ランタイム プロジェクトで、Cloud Build が、ビルドされたコンテナ イメージを標準の Docker リポジトリにアップロードします。

  4. GKE は Docker 仮想リポジトリからイメージを pull します。

    • 上の標準 Docker リポジトリには、コンテナ化された Java アプリケーションなどの限定公開イメージが用意されています。
    • 上のリモート リポジトリは、GKE が Docker Hub からリクエストするイメージを提供します。

この例では、すべてのリポジトリ、ビルド、GKE クラスタが同じリージョンにあります。複数の Google Cloud サービスに同じロケーションを使用することには、リポジトリのロケーションで説明されているような利点があります。

リポジトリの場所

サポートされているリージョンまたはマルチリージョンには、複数のリポジトリを作成できます。適切なリポジトリ ロケーションによって、データ コンシューマに対するレイテンシ、可用性、帯域幅のコストのバランスをとれます。組織には、特定のコンプライアンス要件がある場合もあります。

ロケーションに関する留意事項

他の Google Cloud サービスと同じリージョンにリポジトリを作成すると、次のような利点があります。

  • 同じリージョンにリポジトリを作成し、そこで GKE、Cloud Run、Cloud Build などの Google Cloud サービスがリポジトリとやり取りすることで、レイテンシと下り（外向き）ネットワークの費用が削減されます。Artifact Registry から同じリージョン内の他の Google Cloud サービスへの下り（外向き）トラフィックは課金されません。

    マルチリージョンから対応するリージョンの Google Cloud サービスへの下り（外向き）には料金は発生しませんが、この料金は限られたリージョンにのみ適用されます。

    • us マルチリージョンの場合、us-central などの米国内のリージョンへの下り（外向き）は課金されません。カナダや南米のリージョンへの下り（外向き）は課金されます。
    • asia マルチリージョンの場合、asia-northeast1 などのアジアのリージョンへの下り（外向き）は課金されませんが、オーストラリアのリージョンへの下り（外向き）は課金されます。

  • コンテナ イメージがワークロードと同じリージョンの Artifact Registry リポジトリに保存されているか、ワークロードのあるリージョンに対応するマルチリージョンに保存されている場合、GKE および Dataproc サーバーレス では、イメージ ストリーミングしか使用できません。大きなコンテナ イメージを使用している場合、イメージ全体がダウンロードされる前にワークロードが開始されるため、イメージ ストリーミングは、ワークロードの初期化時間を大幅に短縮できます。

  • コンシューマの Google Cloud 外部のロケーションを考慮します。たとえば、オーストラリアのデベロッパー チームが Artifact Registry からローカル ワークステーションにアーティファクトをダウンロードする必要がある場合、オーストラリア リージョンにあるリポジトリによってレイテンシが短縮され、他の大陸にあるリポジトリよりも下り（外向き）の料金が低くなります。

リポジトリのロケーションの制限

特定のリージョンにデータを保存する必要がある規制やポリシーを遵守する必要がある場合は、対象リージョンでのリポジトリ作成のみを許可するリソース ロケーションの制約を、Google Cloud の組織のポリシーに含めることもできます。Artifact Registry は、組織のポリシーに追加した制約を適用するだけです。非準拠のロケーションに既存のリポジトリがある場合は、遵守しているロケーションのリポジトリにアーティファクトを移動させ、非準拠のリポジトリを削除する必要があります。

クリーンアップ ポリシー

Artifact Registry のクリーンアップ ポリシーでは、不要になったアーティファクト バージョンを自動的に削除する、または無期限に保存するアーティファクトを保持するための条件を定義します。

クリーンアップ ポリシーは、アーティファクトの多くのバージョンを保存するが、本番環境にリリースする特定のバージョンのみを保持する必要がある場合に便利です。アーティファクトを削除する条件で削除ポリシーを定義し、アーティファクトを保持する条件で保持ポリシーを定義できます。

アーティファクト バージョンが削除ポリシーと保持ポリシーの両方の条件と一致する場合、Artifact Registry は保持ポリシーを適用します。

削除ポリシー

削除ポリシーは、次の必須基準に一致するアーティファクトを削除します。

  • タグの状態: タグ付けされたアーティファクトかタグ付けされていないアーティファクトかをポリシーで確認するかどうかを指定します。イメージをリポジトリに push またはリポジトリから pull するときに、アーティファクトにタグが付けられます。Docker タグの詳細については、コンテナのコンセプトをご覧ください。

    • 任意のタグ状態: タグの状態を無視し、タグ付けされたアーティファクトとタグ付けされていないアーティファクトの両方に適用されます。
    • タグ付き: タグ付けされたアーティファクトにのみ適用されます。
    • タグなし: タグ付けされていないアーティファクトにのみ適用されます。

    タグをサポートしていない形式は、untagged として扱われます。不変のタグが有効になっているリポジトリ内のタグ付きアーティファクトは削除できません。

    クリーンアップ ポリシーに適用されるタグの状態の詳細については、TagState リファレンスをご覧ください。

削除ポリシーを定義する省略可能な方法は次のとおりです。

  • タグ接頭辞: タグ接頭辞のカンマ区切りのリスト。たとえば、接頭辞 test と staging は、タグ testenv と staging-1.5 が付けられたイメージと一致します。タグ接頭辞を使用するには、tagState を TAGGED に設定する必要があります。
    • バージョン接頭辞: アーティファクト バージョン接頭辞のカンマ区切りのリストです。たとえば、v1、v2 は、バージョン v1.5、v2.0alpha、v10.2 と一致します。
  • パッケージ接頭辞: アーティファクト名の接頭辞のリスト。接頭辞間で Enter または , を入力することにより、複数の接頭辞を入力できます。たとえば、red, blue は red と blue の 2 つの接頭辞を作成し、red-team、redis、bluebird のアーティファクト名と一致します。
  • 次より古い: アーティファクト バージョンがリポジトリにアップロードされてからの最小時間（期間）。たとえば、30d は 30 日間です。それぞれ、s、m、h、d を追加することにより、秒、分、時、日の期間を指定できます。
  • 次より大きい: アーティファクト バージョンがリポジトリにアップロードされてからの最大時間（期間）。たとえば、30d は 30 日間です。

保持ポリシー

保持ポリシーは、削除ポリシーと同じ条件に一致するアーティファクト、または設定された数の最新バージョンを保持します。

たとえば、次のアーティファクトを含むリポジトリがあるとします。

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

最新バージョンを保持ポリシーが、パッケージ接頭辞に一致するパッケージの 3 つのバージョンを保持するように設定されている場合、{release-xyz}、release-xyz-v1 のみ、release-xyz-v2 が保持されます。

削除ポリシーによってトリガーされる削除は、Artifact Registry のプロジェクトごとの削除リクエストの割り当てに対してカウントされます。

クリーンアップ ポリシーを作成してリポジトリに適用するには、クリーンアップ ポリシーの設定をご覧ください。

gcr.io ドメインのサポート

Artifact Registry は、gcr.io ドメインでのイメージのホスティングをサポートしています。Container Registry から Artifact Registry に移行している場合は、既存の自動化とワークフローに対する変更を最小限に抑えるように gcr.io リポジトリの Artifact Registry を設定できます。これらのリポジトリは以下の機能を備えています。

  • リクエストを gcr.io ドメインにリダイレクトします。
  • Container Registry の動作との互換性を確保するために、最初のイメージが gcr.io ホスト名に push されたときに gcr.io リポジトリが作成される。

詳細については、gcr.io ドメインをサポートするリポジトリへの移行をご覧ください。

プロジェクトの構造

リソース階層は、Google Cloud プロジェクト間でリソースを整理する方法です。選択する構造は、データ ガバナンスの要件、信頼境界、チーム構造などの要因によって変わります。

マルチプロジェクトの組織でリポジトリを設定するには、次の 2 つの方法があります。

リポジトリを一元化する
1 つのプロジェクトにすべてのリポジトリを作成し、リポジトリ レベルで他のプロジェクトのプリンシパルにアクセス権を付与します。この方法は、1 人の個人またはチームが組織全体でリポジトリの管理とリポジトリへのアクセス権を扱う場合に、より効果的です。
また、必要なことは Artifact Registry の単一インスタンスのみを有効にして管理することだけのため、
ソフトウェア デリバリー シールドのような仮想リポジトリやソリューションの設定を簡素化することもできます。
プロジェクト固有のリポジトリ
アーティファクトを保存およびダウンロードするプロジェクトにリポジトリを作成します。この方法は、データ ガバナンス ポリシーや信頼境界があり、プロジェクト レベルでリソースを分離して制御することが求められる場合に必要になる可能性があります。

アクセス制御

リポジトリは、公開アクセス用にリポジトリを構成しない限り、適切な権限でのみアクセスできます。権限は、プロジェクト レベルまたはリポジトリ レベルで付与できます。

一部の Google Cloud サービスでは、同じ Google Cloud プロジェクト内のリポジトリに対するデフォルトの権限を持つデフォルトのサービス アカウントを使用します。ただし、これらのデフォルトは、ソフトウェア開発プロセスに適していない場合や、組織のセキュリティ要件またはポリシー要件を遵守していない場合があります。次の場合には、リポジトリ管理者がこれらのサービスにリポジトリへのアクセス権を明示的に付与する必要があります。

  • Artifact Registry が、操作するサービスとは異なるプロジェクトにある。
  • 事前定義ロールではなく、デフォルトのサービス アカウントでカスタム IAM ロールを使用している。
  • Google Cloud サービスにデフォルトのサービス アカウントを使用していない。
  • 仮想リポジトリを設定します。Artifact Registry サービス アカウントに、アップストリーム リポジトリへのアクセス権を明示的に付与する必要があります。

リポジトリへのアクセス権を必要とする他のプリンシパルについては、リポジトリ管理者がアクセス権を付与する必要があります。最小権限のセキュリティ原則に従って、必要最小限の権限を付与します。例:

  • Artifact Registry のコンテナ イメージを複数のプロジェクトの GKE クラスタにデプロイする。これらのクラスタ内のノードのサービス アカウントは、リポジトリへの読み取りアクセス権しか必要としません。
  • 開発中のアプリケーション用の開発リポジトリと、リリースされるアプリケーション用の本番環境リポジトリがあります。デベロッパーには、開発リポジトリに対する読み取り / 書き込みアクセス権と、本番環境リポジトリに対する読み取り専用アクセス権が必要です。
  • サンプル アプリケーションを含むデモリポジトリが用意されている。セールスチームは、デモをダウンロードするための読み取り専用権限しか必要としません。

データ暗号化

Google Cloud では、デフォルトで、Google が所有し管理する鍵を使用して、保存されているデータを自動的に暗号化します。データを保護する鍵に関連する具体的なコンプライアンス要件や規制要件がある場合は、顧客管理の暗号鍵（CMEK）で暗号化されたリポジトリを作成できます。

Artifact Registry は、組織のポリシーの制約もサポートしており、リソースを保護するために CMEK を必要とする場合があります。

ラベルとタグ

ラベルは、Google Cloud サービスに固有のリソースを整理する方法を提供します。Artifact Registry では、リポジトリにラベルを追加して、リポジトリをグループ化したり、ラベルでリポジトリ リストをフィルタしたりできます。たとえば、自動化や課金を目的として、ラベルを使用して開発ステージまたはチーム別にリポジトリをグループ化できます。リポジトリ ラベルの作成と使用の詳細については、リポジトリのラベル付けをご覧ください。

リポジトリにタグを適用することもできます。ラベルは主にサービス固有のリソースを整理してフィルタリングするためのものですが、タグは Google Cloud 組織全体のポリシーをプログラムで制御するためのものです。詳細については、リポジトリへのタグ付けをご覧ください。

次のステップ