リポジトリの概要

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

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

リポジトリの形式

各リポジトリは、特定のアーティファクト形式に関連付けられます。たとえば、Python リポジトリには、Python パッケージが保存されます。同じ 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 サービスに同じロケーションを使用することには、リポジトリのロケーションで説明されているような利点があります。

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 ドメインをサポートするリポジトリへの移行をご覧ください。

リポジトリの場所

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

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

他の 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 は、組織のポリシーに追加した制約を適用するだけです。非準拠のロケーションに既存のリポジトリがある場合は、遵守しているロケーションのリポジトリにアーティファクトを移動させ、非準拠のリポジトリを削除する必要があります。

プロジェクトの構造

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

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

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

アクセス制御

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

一部の Google Cloud サービス(Cloud Build、Cloud Run、GKE など)では、同じ 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 組織全体のポリシーをプログラムで制御するためのものです。詳細については、リポジトリへのタグ付けをご覧ください。

次のステップ