このページは Cloud Translation API によって翻訳されました。

Artifact Registry の詳細

1. 概要

Artifact Registry は、OCI コンテナイメージと言語パッケージ（Maven や npm など）を管理するための統合ツールを提供する、フルマネージドのパッケージマネージャーです。

Artifact Registry は、次の例に示すように、Google Cloud の幅広い他の Google Cloud サービスと完全に統合されています。

Cloud Build は、イメージアーティファクトを Artifact Registry に直接アップロードできます。
Cloud Deploy は、Artifact Registry イメージをさまざまなランタイム環境に直接デプロイできます。
Cloud Run や GKE などのコンテナランタイムにイメージを提供し、イメージストリーミングなどの高度なパフォーマンス最適化機能を有効にします。
Artifact Registry は、Artifact Analysis の検出ポイントとして機能し、既知の脆弱性を継続的にモニタリングできます。
Cloud IAM は、アーティファクトのアクセスと権限を一貫してきめ細かく制御します。

このラボでは、ハンズオンチュートリアル形式で、これらの機能の多くについて説明します。

学習内容

このラボの学習目標は何ですか？

コンテナと言語パッケージ用に異なるリポジトリを作成する
Artifact Registry でコンテナイメージを作成して使用する
Artifact Registry を使用してアーティファクトのセキュリティ対策とコンテンツを分析する
Java Maven 依存関係用に Artifact Registry を構成して使用する

2. 設定と要件

セルフペース型の環境設定

Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。いつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。
なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。

次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクトを削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

gcloud を設定する

Cloud Shell で、プロジェクト ID とプロジェクト番号を設定します。これらの情報は、PROJECT_ID 変数と PROJECT_NUMBER 変数として保存します。

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

Google サービスを有効にする

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  containerregistry.googleapis.com \
  containerscanning.googleapis.com \
  binaryauthorization.googleapis.com \
  cloudbuild.googleapis.com

ソースコードを取得する

このラボのソースコードは、GitHub の GoogleCloudPlatform 組織にあります。次のコマンドを使用してクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/java-docs-samples

3. コンテナイメージの push

Artifact Registry に Docker リポジトリを作成する

前述のように、Artifact Registry は、コンテナイメージと言語パッケージを管理できるさまざまなリポジトリ形式をサポートしています。さまざまなタイプのアーティファクトリポジトリとのやり取りは仕様で定義されており、広く採用されている標準です。たとえば、Maven 依存関係のリクエストは、Node 依存関係のリクエストとは異なります。

特定のアーティファクト API 仕様をサポートするには、Artifact Registry が対応するリポジトリタイプでアーティファクトを管理する必要があります。新しいリポジトリを作成するときに、--repository-format フラグを渡してリポジトリのタイプを指定します。

Docker イメージの最初のリポジトリを作成するには、Cloud Shell から次のコマンドを実行します。

gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"

Cloud Shell の承認プロンプトが表示されたら、[承認] をクリックします。

Google Cloud コンソールの [Artifact Registry] - [リポジトリ] に移動し、container-example という名前の Docker リポジトリが新しく作成されていることを確認します。クリックすると、現在は空であることがわかります。

Artifact Registry に対する Docker 認証を構成する

Artifact Registry に接続する場合は、アクセス権を付与するために認証情報が必要です。別の認証情報を設定するのではなく、gcloud 認証情報をシームレスに使用するように Docker を構成できます。

Cloud Shell で次のコマンドを実行して、Google Cloud CLI を使用して us-central1 リージョンの Artifact Registry へのリクエストを認証するように Docker を構成します。

gcloud auth configure-docker us-central1-docker.pkg.dev

コマンドから Cloud Shell Docker 構成の変更確認を求められた場合は、Enter キーを押します。

サンプルアプリケーションを確認する

サンプルアプリケーションは、前の手順でクローンを作成した Git リポジトリにあります。java ディレクトリに移動して、アプリケーションコードを確認します。

cd java-docs-samples/run/helloworld/
ls

このフォルダには、シンプルなウェブページをレンダリングする Java アプリケーションの例が含まれています。このラボには関係のないさまざまなファイルに加えて、src フォルダにソースコードと、コンテナイメージのビルドに使用する Dockerfile が含まれています。

コンテナイメージをビルドする

コンテナイメージを Artifact Registry に保存する前に、コンテナイメージを作成する必要があります。

次のコマンドを実行してコンテナイメージをビルドし、アーティファクトレジストリの完全なパスでタグ付けします。

docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .

コンテナイメージを Artifact Registry に push する

次のコマンドを実行して、前に作成したリポジトリにコンテナイメージを push します。

docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1

Artifact Registry でイメージを確認する

Google Cloud コンソール - Artifact Registry - リポジトリに移動します。. container-example リポジトリを開き、java-hello-world イメージが存在することを確認します。

画像をクリックし、tag1 のタグが付いた画像をメモします。containerscanning.googleapis.com サービスによるイメージの自動スキャンを有効にしたので、脆弱性スキャンが実行中か、すでに完了していることがわかります。スキャンが完了すると、このイメージリビジョンで検出された脆弱性の数が示されます。脆弱性などのアーティファクトの分析情報については、次のセクションで説明します。

4. コンテナイメージの検査

最初のイメージを container-example リポジトリに push したので、このイメージについて詳しく見てみましょう。[バージョン] タブで、作成したバージョンをクリックします。画像をより詳細に表示するには:

上部のコピーボタンは、SHA ハッシュを含むそのイメージバージョンの完全修飾イメージ URI に簡単にアクセスできるため、特に便利です。この URI は、特定のイメージバージョンの pull に使用できます。また、Kubernetes Deployment または Cloud Run Service のイメージ参照としても使用できます。イメージ URI をテストするには、Cloud Shell で次のコマンドを実行します。

docker pull $IMAGE_URI

依存関係の把握

上部の [依存関係] タブに移動すると、イメージで検出されたすべての依存関係を確認できます。言語依存関係と OS レベルの両方の依存関係が一覧表示されます。各依存関係に関連付けられているソフトウェアライセンスも確認できます。

よく見ると、SBOM の情報はまだ入力されていません。アーティファクトの SOM にデータを入力するには、上部のパンくずリストバーからコピーできる完全修飾イメージ URI を使用して、Cloud Shell で次のコマンドを実行します。

gcloud artifacts sbom export --uri $IMAGE_URI

ページを更新すると、Cloud Storage に保存されている自動生成された SBOM へのリンクが表示されます。イメージに SBOM を使用する場合は、アーティファクトの SBOM を自動的に生成し、生成を CI/CD パイプラインの一部にすることを検討してください。

イメージの脆弱性の確認

ビューの上部にある [脆弱性] タブをクリックすると、イメージで検出されたすべての脆弱性を確認できます。上部にある脆弱性の概要に加えて、下部の表に脆弱性の完全なリストが表示されます。各行は CVE に関する公開情報にリンクしており、重大度と元のパッケージを示しています。修正が可能な脆弱性については、脆弱性を修正するために依存関係を更新する方法も示されます。

5. 仮想リポジトリとリモートリポジトリ

前のセクションでは、単一のイメージリポジトリを使用してイメージを push と pull しました。これは小規模なユースケースには適していますが、リポジトリに対する自律性を必要とする複数のチームがある大規模な組織では、特に課題があります。チームや事業部門には、独自の権限と構成を持つ独自のイメージリポジトリが用意されていることが一般的です。これらのリポジトリでのイメージの使用を簡素化し、基盤となる組織構造からコンシューマを保護するために、Artifact Registry には、基盤となる複数のリポジトリからリソースを集約できる仮想リポジトリが用意されています。アーキテクチャは次のようになります。

Docker Hub のリモートリポジトリ

Docker Hub は一般公開イメージレジストリとして広く使用されており、多くのオープンソースコンテナイメージをホストしています。公開リポジトリを直接使用するのは簡単ですが、本番環境では多くの課題があります。Artifact Registry のリモートリポジトリを使用すると、これらの課題を克服できます。

リモートリポジトリを使用すると、アップストリームレジストリへのリクエストをプロキシし、その過程でイメージをキャッシュに保存できます。これにより、イメージのダウンロード時間が短縮されるだけでなく、外部サービスの稼働時間に依存する必要がなくなり、独自のイメージに適用するセキュリティポリシーとアクセスポリシーを適用できるようになります。

Docker Hub のリモートリポジトリを作成するには、Cloud Shell で次のコマンドを実行します。

gcloud artifacts repositories create dockerhub \
  --repository-format=docker \
  --mode=remote-repository \
  --remote-docker-repo=docker-hub \
  --location=us-central1 \
  --description="Example Remote Repo for Docker Hub"

Artifact Registry リポジトリのリストに追加のリポジトリが表示されます。

リモートリポジトリがリモートリポジトリへのリクエストをプロキシできるかどうかをテストするには、Cloud Shell で次のコマンドを実行して nginx イメージを pull します。

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine

pull が成功すると、Cloud コンソールでリポジトリを確認できます。キャッシュに保存された nginx イメージには、自分でビルドしたイメージと同じ依存関係と脆弱性のレポートが表示されます。

仮想リポジトリを作成する

ここまで説明したプロセスに沿って、チームまたはビジネスごとに複数のリポジトリを作成し、それぞれの所有権と IAM 権限を明確に定義できます。また、リモートリポジトリのプロキシを作成して、サードパーティのイメージをより簡単に安全に使用することもできます。これらのイメージの利用者から見ると、この多数のリポジトリの欠点は明らかです。デベロッパーは、デプロイで使用するイメージリポジトリをどのように判断すればよいですか。

使用を簡素化し、基盤となるリポジトリを抽象化レイヤの背後に隠すには、Cloud Shell で次のコマンドを使用して Artifact Registry に仮想リポジトリを作成します。

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com \
    --role roles/artifactregistry.reader

cat <<EOF > /tmp/upstream.json
[{
"id" : "hello-repo",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/container-example",
"priority" : 100
},{
"id" : "dockerhub",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/dockerhub",
"priority" : 101
}]
EOF

gcloud artifacts repositories create all-images \
    --repository-format=docker \
    --mode=virtual-repository \
    --location=us-central1 \
    --upstream-policy-file=/tmp/upstream.json \
    --description="Example Virtual Repo"

基盤となる構造を公開せずに、仮想リポジトリからイメージを pull できるようになりました。すべてが想定どおりに動作することを確認するには、Cloud Shell で次のコマンドを実行します。

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/nginx:stable-alpine

6. Cloud Run にデプロイする

それぞれのリポジトリとイメージが用意できたので、デプロイで使用できるようになりました。ユースケースの例を示すため、追加のインフラストラクチャをデプロイせずに、コンテナを Cloud Run にデプロイします。最もシンプルな方法では、Cloud Shell で次のコマンドを実行してデプロイできます。

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1 \
  --allow-unauthenticated

デプロイが完了すると、サービスにアクセスできる自動生成された URL が表示されます。

Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1]
OK Deploying... Done.                                                                      
  OK Creating Revision...                                                                  
  OK Routing traffic...
  OK Setting IAM Policy...                                                                    
Done.                                                                                      
Service [hello-world] revision [hello-world-00001-wtc] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-world-13746229022.us-central1.run.app

新しいブラウザタブでその URL を開くと、「Hello World」という成功メッセージが表示されます。

7. サプライチェーンセキュリティを強化する

コンテナイメージが本番環境にデプロイされたので、エンドツーエンドのサプライチェーンを強化する方法を検討しましょう。前のセクションでは、Artifact Registry のコンテナ分析によって、イメージで使用されているライブラリとライセンスに関する分析情報を取得する方法について説明しました。ただし、悪意のある行為者がサプライチェーンを通じて画像に有害なコンテンツを導入する可能性はあります。このセクションでは、SLSA フレームワークを使用してビルドアーティファクトの構成証明を導入し、アーティファクト自体の暗号署名を活用して、信頼できるアーティファクトのみを Cloud Run ランタイムにデプロイする方法について説明します。

Cloud Build を使用した SLSA 構成証明

SLSA フレームワークは、サプライチェーンアーティファクトにさまざまなレベルの証拠を提供します。仕様と実装は一見複雑に思えますが、Cloud Build では、requestedVerifyOption を VERIFIED に設定した cloudbuild.yaml 仕様を追加するだけで、SLSA 構成証明を作成できます。

アプリケーションの場合、Cloud Shell で次のコマンドを実行して、helloworld フォルダに cloudbuild.yaml ファイルを作成できます。

cat <<EOF > cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', '\$_IMAGE_URI', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', '\$_IMAGE_URI']
images:
- '\$_IMAGE_URI'
options:
  requestedVerifyOption: VERIFIED
substitutions:
  _IMAGE_URI: us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:latest
EOF

Cloud Shell で次のコマンドを実行して、新しいバージョンの Java Hello World イメージをビルドする新しい Cloud Build Job を作成します。

gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build

ビルドが完了したら、Google Cloud コンソールの Cloud Build UI に移動し、ビルドを開いて [ビルドの概要] の [ビルドアーティファクト] で、達成した SLSA レベルを確認します。表示される画像には、[セキュリティ分析情報] を表示するためのボタンがあります。これをクリックすると、SLSA 構成証明と、ローカルビルドを push したときに Artifact Registry UI で表示された脆弱性レポートが表示されます。

イメージの SLSA 来歴は、Cloud Shell で次のコマンドを実行して取得することもできます。

gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
 --show-provenance

Binary Authorization で Cloud Build の来歴を必須にする

Cloud Build パイプラインが確立されているので、本番環境にデプロイするすべてのイメージが、そのプログラム可能で再現可能なビルド環境を使用してビルドされていることを確認できます。

ここで役に立つのが Binary Authorization です。これにより、コンテナランタイムの前にゲートキーパーを配置して、コンテナイメージを検査し、信頼できる構成証明の存在を確認できます。構成に応じて、構成証明が見つからない場合、監査ログエントリが作成されるか、デプロイが完全にブロックされます。

Cloud Run によって発行された組み込み構成証明を必要とするように、プロジェクトのデフォルトの Binary Authorization 構成を変更するには、Cloud Shell で次のコマンドを実行します。

cat << EOF > /tmp/policy.yaml
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: REQUIRE_ATTESTATION
  requireAttestationsBy:
  - projects/$PROJECT_ID/attestors/built-by-cloud-build
name: projects/$PROJECT_ID/policy
EOF

gcloud container binauthz policy import /tmp/policy.yaml

ここでは、独自のカスタム構成証明も追加できますが、これはこの Codelab の範囲外であり、オプションの課外宿題として残しておきます。

Cloud Run サービスにバイナリ認可を適用するには、Cloud Shell で次のコマンドを実行します。

gcloud run services update hello-world \
  --region us-central1 \
  --binary-authorization=default

まず、ローカルでビルドしたイメージを再デプロイして、Binary Authorization が正しく適用されていることをテストします。

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1

想定どおり、イメージがデプロイされなかった理由を説明するエラーメッセージが表示されます。次に例を示します。

Image us-central1-docker.pkg.dev/my-project/all-images/java-hello-world@sha256:71eebbf04bf7d1d023e5de5e18f786ea3b8b6411bf64c8def3301c71baca0518 denied by attestor projects/my-project/attestors/built-by-cloud-build: No attestations found that were valid and signed by a key trusted by the attestor

そのため、新しいバージョンを Cloud Run サービスにデプロイするには、Cloud Build でビルドされたイメージを提供する必要があります。

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:cloud-build \
  --region us-central1

今回はデプロイが成功し、次のようなデプロイ成功メッセージが表示されます。

Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1]
OK Deploying... Done.                                                                      
  OK Creating Revision...                                                                  
  OK Routing traffic...                                                                    
Done.                                                                                      
Service [hello-world] revision [hello-world-00005-mq4] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-world-13746229022.us-central1.run.app

8. Java Maven 言語パッケージの管理

このセクションでは、Artifact Registry Java リポジトリを設定してパッケージをアップロードし、さまざまなアプリケーションで活用する方法について説明します。

Maven パッケージリポジトリを作成する

Cloud Shell で次のコマンドを実行して、Java アーティファクトのリポジトリを作成します。

gcloud artifacts repositories create java-repo \
    --repository-format=maven \
    --location=us-central1 \
    --description="Example Java Maven Repo"

Cloud Shell の承認プロンプトが表示されたら、[承認] をクリックします。

Google Cloud コンソールの Artifact Registry - リポジトリに移動し、java-repo という名前の新しい Maven リポジトリを確認します。クリックすると、現在は空であることがわかります。

Artifact リポジトリに対する認証を設定する

次のコマンドを使用して、アプリケーションのデフォルト認証情報（ADC）の既知のロケーションをユーザーアカウント認証情報で更新します。これにより、Artifact Registry 認証ヘルパーがリポジトリへの接続時にそれらを使用して認証できるようになります。

gcloud auth login --update-adc

Artifact Registry 用に Maven を構成する

次のコマンドを実行して、Java プロジェクトに追加するリポジトリ構成を出力します。

gcloud artifacts print-settings mvn \
    --repository=java-repo \
    --location=us-central1 | tee config.xml

helloworld ディレクトリ内から Cloud Shell で次のコマンドを実行し、Cloud Shell エディタで pom.xml を開きます。

cloudshell edit pom.xml

返された設定をファイル内の適切なセクションに追加します。

distributionManagement セクションを更新する

<distributionManagement>
   <snapshotRepository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </snapshotRepository>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </repository>
</distributionManagement>

repositories セクションを更新する

 <repositories>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
     <releases>
       <enabled>true</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
   </repository>
 </repositories>

[build] の [extensions] セクションを更新します。

   <extensions>
     <extension>
       <groupId>com.google.cloud.artifactregistry</groupId>
       <artifactId>artifactregistry-maven-wagon</artifactId>
       <version>2.1.0</version>
     </extension>
   </extensions>

ファイル全体の例を以下に示します。<PROJECT> は、プロジェクト ID に置き換えてください。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.example.run</groupId>
 <artifactId>helloworld</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <packaging>jar</packaging>

 <parent>
   <groupId>com.google.cloud.samples</groupId>
   <artifactId>shared-configuration</artifactId>
   <version>1.2.0</version>
 </parent>
 <dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-dependencies</artifactId>
       <version>${spring-boot.version}</version>
       <type>pom</type>
       <scope>import</scope>
     </dependency>
   </dependencies>
 </dependencyManagement>
 <properties>
   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
   <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
   <maven.compiler.target>17</maven.compiler.target>
   <maven.compiler.source>17</maven.compiler.source>
   <spring-boot.version>3.2.2</spring-boot.version>
 </properties>
 <dependencies>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-web</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-test</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>org.junit.vintage</groupId>
     <artifactId>junit-vintage-engine</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <scope>test</scope>
   </dependency>
 </dependencies>
 <!-- [START Artifact Registry Config] -->
 <distributionManagement>
   <snapshotRepository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </snapshotRepository>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </repository>
 </distributionManagement>

 <repositories>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
     <releases>
       <enabled>true</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
   </repository>
 </repositories>
  <build>
   <extensions>
     <extension>
       <groupId>com.google.cloud.artifactregistry</groupId>
       <artifactId>artifactregistry-maven-wagon</artifactId>
       <version>2.2.0</version>
     </extension>
   </extensions>
 <!-- [END Artifact Registry Config] -->

   <plugins>
     <plugin>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-maven-plugin</artifactId>
       <version>${spring-boot.version}</version>
       <executions>
         <execution>
           <goals>
             <goal>repackage</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
     <plugin>
       <groupId>com.google.cloud.tools</groupId>
       <artifactId>jib-maven-plugin</artifactId>
       <version>3.4.0</version>
       <configuration>
         <to>
           <image>gcr.io/PROJECT_ID/helloworld</image>
         </to>
       </configuration>
     </plugin>
   </plugins>
 </build>
 </project>

Java パッケージを Artifact Registry にアップロードする

Maven で Artifact Registry を構成したので、Artifact Registry を使用して Java Jar を保存し、組織内の他のプロジェクトで使用できるようになりました。

次のコマンドを実行して、Java パッケージを Artifact Registry にアップロードします。

mvn deploy

Artifact Registry で Java パッケージを確認する

Cloud コンソール - Artifact Registry - リポジトリに移動し、java-repo をクリックして、helloworld バイナリアーティファクトが存在することを確認します。

9. 完了

お疲れさまでした。これでこの Codelab は終了です。

学習した内容

コンテナと言語パッケージ用のリポジトリを作成しました
Artifact Registry で管理対象のコンテナイメージ
Artifact Registry と Cloud Code を統合
Java 依存関係に Artifact Registry を使用するように Maven を構成する

クリーンアップ

Cloud Shell で次のコマンドを実行して、プロジェクト全体を削除します。

gcloud projects delete $PROJECT_ID