Mempelajari Mendalam Artifact Registry

Pembahasan Mendalam Artifact Registry

Tentang codelab ini

subjectTerakhir diperbarui Des 4, 2024
account_circleDitulis oleh Giovanni Galloro, Daniel Strebel

1. Ringkasan

Artifact Registry adalah pengelola paket yang dikelola sepenuhnya dan menyediakan alat terpadu untuk mengelola image container OCI dan paket bahasa (seperti Maven dan npm).

Artifact Registry terintegrasi sepenuhnya dengan berbagai layanan Google Cloud lainnya seperti dalam contoh berikut:

  • Cloud Build dapat langsung mengupload artefak gambar ke Artifact Registry.
  • Cloud Deploy dapat men-deploy Image Artifact Registry langsung ke berbagai lingkungan runtime.
  • Containerd menyediakan image ke runtime container seperti Cloud Run dan GKE serta memungkinkan kemampuan pengoptimalan performa lanjutan seperti streaming image.
  • Artifact Registry dapat berfungsi sebagai titik deteksi untuk Artifact Analysis guna terus memantau kerentanan yang diketahui.
  • Cloud IAM memberikan kontrol yang konsisten dan terperinci atas akses dan izin artefak.

Lab ini akan memandu Anda mempelajari banyak fitur tersebut dalam bentuk tutorial langsung.

Yang akan Anda pelajari

Apa tujuan pembelajaran lab ini?

  • Membuat repositori yang berbeda untuk Container dan Paket Bahasa
  • Membuat dan menggunakan image container dengan Artifact Registry
  • Menggunakan Artifact Registry untuk menganalisis postur keamanan dan konten artefak Anda
  • Mengonfigurasi dan menggunakan Artifact Registry untuk Dependensi Maven Java

2. Penyiapan dan Persyaratan

Penyiapan lingkungan mandiri

  1. Login ke Google Cloud Console dan buat project baru atau gunakan kembali project yang sudah ada. Jika belum memiliki akun Gmail atau Google Workspace, Anda harus membuatnya.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Project name adalah nama tampilan untuk peserta project ini. String ini adalah string karakter yang tidak digunakan oleh Google API. Anda dapat memperbaruinya kapan saja.
  • Project ID bersifat unik di semua project Google Cloud dan tidak dapat diubah (tidak dapat diubah setelah ditetapkan). Cloud Console otomatis membuat string unik; biasanya Anda tidak mementingkan kata-katanya. Di sebagian besar codelab, Anda harus merujuk Project ID-nya (umumnya diidentifikasi sebagai PROJECT_ID). Jika tidak suka dengan ID yang dibuat, Anda dapat membuat ID acak lainnya. Atau, Anda dapat mencobanya sendiri, dan lihat apakah ID tersebut tersedia. ID tidak dapat diubah setelah langkah ini dan tersedia selama durasi project.
  • Sebagai informasi, ada nilai ketiga, Project Number, yang digunakan oleh beberapa API. Pelajari lebih lanjut ketiga nilai ini di dokumentasi.
  1. Selanjutnya, Anda harus mengaktifkan penagihan di Konsol Cloud untuk menggunakan resource/API Cloud. Menjalankan operasi dalam codelab ini tidak akan memakan banyak biaya, bahkan mungkin tidak sama sekali. Guna mematikan resource agar tidak menimbulkan penagihan di luar tutorial ini, Anda dapat menghapus resource yang dibuat atau menghapus project-nya. Pengguna baru Google Cloud memenuhi syarat untuk mengikuti program Uji Coba Gratis senilai $300 USD.

Menyiapkan gcloud

Di Cloud Shell, tetapkan project ID dan nomor project Anda. Simpan sebagai variabel PROJECT_ID dan PROJECT_NUMBER.

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

Mengaktifkan Layanan 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

Mendapatkan kode sumber

Kode sumber untuk lab ini terletak di organisasi GoogleCloudPlatform di GitHub. Buat clone-nya dengan perintah di bawah.

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

3. Mengirim Image Container

Membuat Repositori Docker di Artifact Registry

Seperti yang disebutkan sebelumnya, Artifact Registry mendukung berbagai format repositori yang memungkinkan Anda mengelola image container dan paket bahasa. Interaksi dengan berbagai jenis repositori artefak ditentukan dalam spesifikasi dan merupakan standar yang diadopsi secara luas. Misalnya, permintaan untuk dependensi Maven berbeda dengan permintaan untuk dependensi Node.

Untuk mendukung spesifikasi API artefak tertentu, Artifact Registry perlu mengelola artefak Anda dalam jenis repositori yang sesuai. Saat membuat repositori baru, Anda meneruskan flag --repository-format untuk menunjukkan jenis repositori.

Untuk membuat repositori pertama untuk image Docker, jalankan perintah berikut dari Cloud Shell:

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

Klik Izinkan jika perintah otorisasi Cloud Shell muncul

Buka Google Cloud Console - Artifact Registry - Repositories dan perhatikan repositori Docker yang baru Anda buat bernama container-example. Jika Anda mengkliknya, Anda dapat melihat bahwa repositori tersebut kosong saat ini

5b854eb010e891c2.png

Mengonfigurasi Autentikasi Docker ke Artifact Registry

Saat terhubung ke Artifact Registry, kredensial diperlukan untuk memberikan akses. Daripada menyiapkan kredensial terpisah, Docker dapat dikonfigurasi untuk menggunakan kredensial gcloud Anda dengan lancar.

Dari Cloud Shell, jalankan perintah berikut untuk mengonfigurasi Docker agar menggunakan Google Cloud CLI untuk mengautentikasi permintaan ke Artifact Registry di region us-central1,

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

Jika perintah akan meminta konfirmasi untuk mengubah konfigurasi docker Cloud Shell, tekan enter.

Menjelajahi Aplikasi contoh

Aplikasi contoh disediakan di repositori git yang Anda clone pada langkah sebelumnya. Ubah ke direktori java dan tinjau kode aplikasi.

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

Folder ini berisi contoh aplikasi Java yang merender halaman web sederhana: selain berbagai file yang tidak relevan untuk lab khusus ini, folder ini berisi kode sumber, di folder src, dan Dockerfile yang akan kita gunakan untuk mem-build image container.

Mem-build Image Penampung

Sebelum dapat menyimpan image container di Artifact Registry, Anda harus membuatnya.

Jalankan perintah berikut untuk mem-build image container dan memberi tag dengan jalur artifact registry lengkap:

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

Mengirim Image Container ke Artifact Registry

Jalankan perintah berikut untuk mengirim image container ke repositori yang dibuat sebelumnya:

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

Meninjau image di Artifact Registry

Buka Konsol Google Cloud - Artifact Registry - Repositories. Buka repositori container-example dan pastikan image java-hello-world ada di sana.

88e4b26e8536afb2.png

Klik gambar dan perhatikan gambar yang diberi tag tag1. Karena kami mengaktifkan pemindaian otomatis gambar melalui layanan containerscanning.googleapis.com, Anda dapat melihat bahwa Pemindaian Kerentanan sedang berjalan atau sudah selesai. Setelah selesai, Anda dapat melihat jumlah kerentanan yang terdeteksi untuk revisi image ini. Kita akan mempelajari kerentanan dan insight artefak lainnya di bagian berikutnya.

55406d03cf0c96b8.png

4. Memeriksa Image Container

Setelah Anda mem-push image pertama ke repositori container-example, kita dapat melihatnya secara lebih mendetail. Di tab versi, klik versi yang baru saja kita buat. Untuk menampilkan gambar secara lebih mendetail:

44c3f28dd457ed1d.png

Tombol salin di bagian atas sangat berguna karena menyediakan cara mudah untuk mengakses URI gambar yang sepenuhnya memenuhi syarat ke versi gambar tersebut, termasuk hash SHA. URI ini kemudian dapat digunakan untuk mengambil versi image tertentu atau sebagai referensi image dalam Deployment Kubernetes atau Layanan Cloud Run. Untuk menguji URI gambar, Anda dapat menjalankan perintah berikut di Cloud Shell:

docker pull $IMAGE_URI

Memahami Dependensi

Dengan beralih ke tab "Dependencies" di bagian atas, Anda dapat melihat semua dependensi yang terdeteksi dalam gambar. Perhatikan bahwa daftar ini mencantumkan dependensi di dependensi bahasa dan tingkat OS. Anda juga dapat melihat lisensi software yang dilampirkan ke setiap dependensi.

af03348529575dbc.png

Jika melihat dengan cermat, Anda dapat melihat bahwa informasi SBOM belum diisi. Untuk mengisi SOM untuk artefak, Anda dapat menjalankan perintah berikut di Cloud Shell menggunakan URI gambar yang sepenuhnya memenuhi syarat yang dapat kita salin dari panel breadcrumb di bagian atas.

gcloud artifacts sbom export --uri $IMAGE_URI

Setelah Anda memuat ulang halaman, halaman tersebut akan berisi link ke SBOM yang dibuat secara otomatis dan disimpan di Cloud Storage. Jika mengandalkan SBOM untuk image, Anda dapat membuat SBOM secara otomatis untuk artefak dan menjadikan pembuatan sebagai bagian dari pipeline CI/CD.

Mempelajari Kerentanan Image

Saat mengklik tab "Vulnerabilities" di bagian atas tampilan, Anda dapat melihat semua kerentanan yang terdeteksi dalam image. Selain ringkasan kerentanan di bagian atas, Anda dapat melihat daftar lengkap kerentanan dalam tabel di bagian bawah. Setiap baris ditautkan ke buletin CVE, yang menunjukkan tingkat keparahannya dan paket asalnya. Untuk kerentanan yang memiliki perbaikan, halaman ini juga memberikan petunjuk tentang cara mengupdate dependensi untuk memperbaiki kerentanan.

fda03e6fd758ddef.png

5. Repositori Virtual dan Jarak Jauh

Di bagian sebelumnya, kita menggunakan satu repositori gambar untuk mengirim dan mengambil gambar. Hal ini sangat cocok untuk kasus penggunaan skala kecil, tetapi menimbulkan tantangan terutama bagi organisasi yang lebih besar dengan tim yang berbeda yang memerlukan otonomi atas repositori mereka. Tim atau unit bisnis biasanya memiliki repositori image sendiri dengan izin dan konfigurasi mereka sendiri. Untuk menyederhanakan penggunaan image di repositori ini dan melindungi konsumen dari struktur organisasi yang mendasarinya, Artifact Registry menyediakan repositori virtual yang dapat menggabungkan resource dari beberapa repositori yang mendasarinya. Arsitektur potensial dapat terlihat seperti ini:

c6488dc5a6bfac3.png

Repositori Jarak Jauh untuk Docker Hub

Docker Hub adalah registry image publik yang populer dan menghosting banyak image container open source. Meskipun menggunakan repositori publik secara langsung itu mudah, ada sejumlah tantangan di lingkungan produksi yang dapat kita atasi dengan repositori Jarak Jauh di Artifact Registry.

Repositori jarak jauh memberi Anda kemampuan untuk membuat proxy permintaan ke registry upstream dan meng-cache gambar di sepanjang proses. Hal ini tidak hanya mengurangi waktu download gambar, tetapi juga menghapus dependensi pada waktu aktif layanan eksternal dan memberi Anda kemampuan untuk menerapkan kebijakan keamanan dan akses yang sama dengan yang Anda terapkan pada gambar Anda sendiri.

Untuk membuat repositori jarak jauh untuk Docker Hub, Anda dapat menjalankan perintah berikut di 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"

Sekarang Anda akan melihat repositori tambahan di daftar repositori Artifact Registry:

7e174a9944c5f34c.png

Untuk menguji apakah repositori jarak jauh Anda dapat melakukan proxy permintaan ke repositori jarak jauh, jalankan perintah berikut di Cloud Shell untuk mengambil image nginx:

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

Setelah pull berhasil, Anda juga dapat melihat repositori di Konsol Cloud dan image nginx yang di-cache kini memberikan pelaporan kerentanan dan dependensi yang sama seperti yang telah kita lihat untuk image yang Anda build sendiri.

Membuat Repositori Virtual

Dengan mengikuti proses yang telah kita gunakan sejauh ini, Anda dapat membuat sejumlah repositori untuk setiap tim atau bisnis dan menentukan kepemilikan serta izin IAM untuk setiap repositori dengan jelas. Kita juga dapat membuat proxy untuk repositori jarak jauh sehingga lebih mudah dan aman untuk menggunakan image pihak ketiga. Kelemahan dari repositori dalam jumlah besar ini terlihat jelas jika Anda mengubah perspektif ke konsumen gambar ini. Bagaimana cara developer mengetahui repositori image yang harus digunakan dalam deployment?

Untuk menyederhanakan penggunaan dan menyembunyikan repositori yang mendasarinya di balik lapisan abstraksi, Anda dapat membuat repositori virtual di Artifact Registry dengan perintah berikut di Cloud Shell:

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"

Sekarang kita dapat mengambil gambar dari repositori virtual tanpa mengekspos struktur yang mendasarinya. Untuk memverifikasi bahwa semuanya berfungsi seperti yang diharapkan, Anda dapat menjalankan perintah berikut di 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. Men-deploy ke Cloud Run

Dengan repositori dan image masing-masing yang sudah ada, sekarang kita dapat menggunakannya dalam deployment. Untuk mengilustrasikan contoh kasus penggunaan dan menghindari deployment infrastruktur tambahan, kita akan men-deploy container ke Cloud Run. Dalam bentuk yang paling sederhana, deployment dapat dilakukan dengan menjalankan perintah berikut di 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

Setelah selesai, deployment akan menampilkan URL yang otomatis dibuat tempat Anda dapat mengakses layanan.

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

Jika membuka URL tersebut di tab browser baru, Anda akan melihat pesan "Hello World" yang berhasil.

852a8748c1543736.png

7. Memperkuat Keamanan Supply Chain

Setelah Image container Anda berhasil di-deploy secara live, sekarang saatnya untuk melihat cara memperkuat rantai pasokan menyeluruh. Di bagian sebelumnya, kita telah melihat bagaimana analisis container Artifact Registry memberikan insight tentang library dan lisensi yang digunakan dalam image. Namun, pelaku kejahatan masih dapat memasukkan konten berbahaya ke dalam gambar Anda di sepanjang rantai pasokan. Di bagian ini, kita akan mempelajari cara menggunakan framework SLSA untuk memperkenalkan pengesahan untuk artefak build dan bahkan memanfaatkan tanda tangan kriptografis artefak itu sendiri untuk memastikan hanya artefak tepercaya yang dapat di-deploy ke runtime Cloud Run.

Pengesahan SLSA dengan Cloud Build

Framework SLSA memberikan tingkat bukti yang berbeda untuk artefak supply chain. Spesifikasi dan penerapan mungkin tampak menakutkan pada pandangan pertama, tetapi dengan Cloud Build, membuat pengesahan SLSA semudah menambahkan pembuatan spesifikasi cloudbuild.yaml dengan requestedVerifyOption yang ditetapkan ke VERIFIED.

Untuk aplikasi kita, kita dapat menjalankan perintah berikut di Cloud Shell untuk membuat file cloudbuild.yaml di folder helloworld.

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

Sekarang kita membuat Tugas Cloud Build baru yang mem-build versi baru Image Hello World Java dengan menjalankan perintah berikut di Cloud Shell.

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

Setelah build selesai, kita dapat membuka UI Cloud Build di Google Cloud Console dan melihat Level SLSA yang kita capai dengan membuka build, lalu melihat Artefak Build di bagian Ringkasan Build. Gambar yang terlihat di sana memiliki tombol untuk melihat "Insight Keamanan". Saat mengkliknya, Anda akan melihat pengesahan SLSA serta laporan kerentanan yang sudah dikenal yang kita lihat sebelumnya di UI Artifact Registry saat kita mendorong build lokal.

f6154004bfcddc16.png

Sumber SLSA untuk image kita juga dapat diambil dengan menjalankan perintah berikut di Cloud Shell:

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

Memerlukan Cloud Build Provenance dengan Otorisasi Biner

Dengan pipeline Cloud Build yang sudah ada, bukankah akan lebih baik jika kita memastikan bahwa semua image yang di-deploy ke produksi dibuat menggunakan lingkungan build yang dapat diprogram dan direproduksi?

Di sinilah Otorisasi Biner berperan. Hal ini memungkinkan Anda menempatkan gatekeeper di depan runtime penampung yang memeriksa image penampung dan memverifikasi keberadaan pengesahan tepercaya. Jika tidak ada pengesahan yang ditemukan, tindakan yang dilakukan adalah membuat entri log audit atau memblokir deployment sepenuhnya, bergantung pada konfigurasi.

Untuk mengubah konfigurasi Otorisasi Biner default project agar mewajibkan pengesahan bawaan yang dikeluarkan oleh Cloud Run, kita menjalankan perintah berikut di 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

Di sini, Anda tentu juga dapat menambahkan Pengesah kustom Anda sendiri, tetapi hal itu berada di luar cakupan codelab ini dan dibiarkan sebagai latihan pekerjaan rumah ekstrakurikuler opsional.

Untuk menerapkan otorisasi biner di Layanan Cloud Run, kita menjalankan perintah berikut di Cloud Shell:

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

Mari kita uji apakah Otorisasi Biner diterapkan dengan benar dengan men-deploy ulang image yang di-build secara lokal terlebih dahulu

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

Seperti yang diharapkan, Anda akan mendapatkan pesan error yang menjelaskan alasan gambar tidak dapat di-deploy yang terlihat seperti ini:

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

Oleh karena itu, untuk men-deploy versi baru ke layanan Cloud Run, kita perlu menyediakan image yang dibuat dengan 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

Kali ini deployment akan berhasil dan menampilkan pesan deployment yang berhasil seperti di bawah ini:

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. Mengelola paket bahasa Java Maven

Di bagian ini, Anda akan melihat cara menyiapkan repositori Java Artifact Registry dan mengupload paket ke dalamnya, serta memanfaatkannya di berbagai aplikasi.

Membuat repositori paket Maven

Dari Cloud Shell, jalankan perintah berikut untuk membuat repositori artefak Java:

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

Klik Izinkan jika perintah otorisasi Cloud Shell muncul

Buka Konsol Google Cloud - Artifact Registry - Repositories dan perhatikan repositori Maven yang baru Anda buat bernama java-repo. Jika Anda mengkliknya, Anda dapat melihat bahwa repositori tersebut kosong saat ini.

Menyiapkan autentikasi ke Repositori Artefak

Gunakan perintah berikut untuk memperbarui lokasi yang dikenal untuk Kredensial Default Aplikasi (ADC) dengan kredensial akun pengguna Anda sehingga helper kredensial Artifact Registry dapat melakukan autentikasi menggunakan kredensial tersebut saat terhubung dengan repositori:

gcloud auth login --update-adc

Mengonfigurasi Maven untuk Artifact Registry

Jalankan perintah berikut untuk mencetak konfigurasi repositori yang akan ditambahkan ke project Java Anda:

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

Buka pom.xml di Cloud Shell Editor dengan menjalankan perintah berikut di Cloud Shell dari dalam direktori helloworld:

cloudshell edit pom.xml

dan tambahkan setelan yang ditampilkan ke bagian yang sesuai dalam file,

Memperbarui bagian 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>

Memperbarui bagian repositori

 <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>

Perbarui bagian extensions di bagian build

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

Berikut adalah contoh file lengkap untuk referensi Anda. Pastikan untuk mengganti <PROJECT> dengan project ID Anda.

<?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>

Mengupload paket Java ke Artifact Registry

Dengan Artifact Registry yang dikonfigurasi di Maven, Anda kini dapat menggunakan Artifact Registry untuk menyimpan Java Jar untuk digunakan oleh project lain di organisasi Anda.

Jalankan perintah berikut untuk mengupload paket Java Anda ke Artifact Registry:

mvn deploy

Memeriksa paket Java di Artifact Registry

Buka Konsol Cloud - Artifact Registry - Repositories Klik java-repo dan pastikan artefak biner helloworld ada di sana:

a95d370ee0fd9af0.png

9. Selamat!

Selamat, Anda telah menyelesaikan codelab!

Yang telah Anda pelajari

  • Membuat Repositori untuk Container dan Paket Bahasa
  • Image container terkelola dengan Artifact Registry
  • Artifact Registry Terintegrasi dengan Cloud Code
  • Mengonfigurasi Maven untuk menggunakan Artifact Registry untuk Dependensi Java

Pembersihan

Jalankan perintah berikut di Cloud Shell untuk menghapus seluruh project

gcloud projects delete $PROJECT_ID