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] > [リポジトリ] に移動し、新しく作成された Docker リポジトリ container-example を確認します。クリックすると、現時点では空であることがわかります。

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

Artifact Registry に接続する際には、アクセスのために認証情報が必要です。Docker は、個別の認証情報を設定するのではなく、gcloud 認証情報をそのまま使用するように構成できます。

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 で SLSA 構成証明を作成するのは、requestedVerifyOption を VERIFIED に設定して cloudbuild.yaml 仕様を作成するのと同じくらい簡単です。

アプリケーションの場合、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 ジョブを作成します。

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

プロジェクトのデフォルトの Binary Authorization 構成を変更して、Cloud Run によって発行された組み込みの構成証明を必須にするには、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

ここでは、独自のカスタム Attestor を追加することもできますが、この 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] - [リポジトリ]）に移動し、新しく作成された Maven リポジトリ java-repo を確認します。クリックすると、現時点では空であることがわかります。

Artifact Repository の認証を設定する

次のコマンドを使用して、アプリケーションのデフォルト認証情報（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

Cloud Shell で次のコマンドを helloworld ディレクトリ内で実行し、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