1. Panoramica
Artifact Registry è il gestore di pacchetti completamente gestito per e fornisce uno strumento unificato per gestire le immagini container OCI e i pacchetti di linguaggio (come Maven e npm).
Artifact Registry è completamente integrato con l'ampia gamma di altri servizi Google Cloud, come nei seguenti esempi:
- Cloud Build può caricare direttamente gli artefatti immagine in Artifact Registry.
- Cloud Deploy può eseguire il deployment delle immagini di Artifact Registry direttamente in vari ambienti di runtime.
- Fornisce immagini ai runtime dei container come Cloud Run e GKE e consente funzionalità avanzate di ottimizzazione delle prestazioni come lo streaming delle immagini.
- Artifact Registry può fungere da punto di rilevamento per Artifact Analysis per monitorare continuamente le vulnerabilità note.
- Cloud IAM fornisce un controllo coerente e granulare sull'accesso e sulle autorizzazioni degli artefatti.
Questo lab ti guiderà attraverso molte di queste funzionalità sotto forma di tutorial pratico.
Cosa imparerai a fare
Quali sono gli obiettivi di apprendimento di questo lab?
- Crea repository diversi per i contenitori e i pacchetti di linguaggio
- Creare e utilizzare immagini container con Artifact Registry
- Utilizzare Artifact Registry per analizzare il livello di sicurezza e i contenuti degli artefatti
- Configura e utilizza Artifact Registry per le dipendenze Maven di Java
2. Configurazione e requisiti
Configurazione dell'ambiente autonomo
- Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.
- Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
- L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere identificato come
PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimane per tutta la durata del progetto. - Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
- Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. Completare questo codelab non costa molto, se non nulla. Per arrestare le risorse ed evitare addebiti oltre a quelli previsti in questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.
Configura gcloud
In Cloud Shell, imposta l'ID e il numero del progetto. Salvali come variabili PROJECT_ID e PROJECT_NUMBER.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
Attiva i servizi 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
Recupera il codice sorgente
Il codice sorgente di questo lab si trova nell'organizzazione GoogleCloudPlatform su GitHub. Clonalo con il comando riportato di seguito.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. Eseguire il push delle immagini container
Crea un repository Docker in Artifact Registry
Come accennato in precedenza, Artifact Registry supporta diversi formati di repository che consentono di gestire le immagini container e i pacchetti di linguaggio. Le interazioni con i diversi tipi di repository di artefatti sono definite nelle specifiche e sono standard ampiamente adottati. Ad esempio, le richieste per le dipendenze Maven sono diverse da quelle per le dipendenze Node.
Per supportare specifiche API di artefatti, Artifact Registry deve gestire gli artefatti nei tipi di repository corrispondenti. Quando crei un nuovo repository, passi il flag --repository-format per indicare il tipo di repository.
Per creare un primo repository per le immagini Docker, esegui questo comando da Cloud Shell:
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
Fai clic su Autorizza se viene visualizzato il prompt di autorizzazione di Cloud Shell
Vai a Google Cloud Console - Artifact Registry - Repository e nota il repository Docker appena creato denominato container-example. Se fai clic su di esso, puoi vedere che al momento è vuoto.
Configura l'autenticazione Docker in Artifact Registry
Quando ti connetti ad Artifact Registry, sono necessarie le credenziali per fornire l'accesso. Anziché configurare credenziali separate, Docker può essere configurato per utilizzare le credenziali gcloud senza problemi.
Da Cloud Shell esegui il seguente comando per configurare Docker in modo che utilizzi Google Cloud CLI per autenticare le richieste ad Artifact Registry nella regione us-central1:
gcloud auth configure-docker us-central1-docker.pkg.dev
Se il comando richiede una conferma per modificare la configurazione Docker di Cloud Shell, premi Invio.
Esplora l'applicazione di esempio
Un'applicazione di esempio è fornita nel repository Git che hai clonato in un passaggio precedente. Passa alla directory Java ed esamina il codice dell'applicazione.
cd java-docs-samples/run/helloworld/
ls
La cartella contiene un'applicazione Java di esempio che esegue il rendering di una semplice pagina web: oltre a vari file non pertinenti per questo lab specifico, contiene il codice sorgente, nella cartella src, e un Dockerfile che utilizzeremo per creare un'immagine container.
Crea l'immagine container
Prima di poter archiviare le immagini container in Artifact Registry, devi crearne una.
Esegui questo comando per creare l'immagine container e taggarla con il percorso completo di Artifact Registry:
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
Esegui il push dell'immagine container in Artifact Registry
Esegui il comando seguente per eseguire il push dell'immagine container nel repository creato in precedenza:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
Esamina l'immagine in Artifact Registry
Vai a Google Cloud Console - Artifact Registry - Repository. Apri il repository container-example e verifica che l'immagine java-hello-world sia presente.
Fai clic sull'immagine e prendi nota dell'immagine taggata tag1. Poiché abbiamo attivato la scansione automatica delle immagini tramite il servizio containerscanning.googleapis.com, puoi vedere che l'analisi delle vulnerabilità è in esecuzione o è già stata completata. Al termine, puoi visualizzare il numero di vulnerabilità rilevate per questa revisione dell'immagine. Esploreremo le vulnerabilità e altri approfondimenti sugli artefatti nella sezione successiva.
4. Ispezione delle immagini container
Ora che hai eseguito il push della prima immagine nel repository container-example, possiamo esaminarla in modo più dettagliato. Nella scheda delle versioni, fai clic sulla versione che abbiamo appena creato. Per mostrare l'immagine in modo più dettagliato:
Il pulsante di copia in alto è particolarmente utile perché fornisce un modo semplice per accedere all'URI completo dell'immagine per quella versione dell'immagine, incluso l'hash SHA. Questo URI può essere utilizzato per estrarre una versione specifica dell'immagine o come riferimento all'immagine in un deployment Kubernetes o in un servizio Cloud Run. Per testare l'URI dell'immagine, puoi eseguire questo comando in Cloud Shell:
docker pull $IMAGE_URI
Informazioni sulle dipendenze
Se passi alla scheda "Dipendenze" in alto, puoi visualizzare tutte le dipendenze rilevate nell'immagine. Tieni presente che elenca sia le dipendenze a livello di lingua sia quelle a livello di sistema operativo. Puoi anche visualizzare le licenze software associate a ciascuna dipendenza.
Se guardi da vicino, puoi notare che le informazioni della SBOM non sono ancora state compilate. Per compilare la SOM per l'artefatto, puoi eseguire il seguente comando in Cloud Shell utilizzando l'URI completo dell'immagine che possiamo copiare dalla barra di navigazione nella parte superiore.
gcloud artifacts sbom export --uri $IMAGE_URI
Una volta aggiornata la pagina, conterrà un link alla SBOM generata automaticamente e archiviata in Cloud Storage. Se utilizzi le SBOM per le tue immagini, ti consigliamo di generarle automaticamente per i tuoi artefatti e di integrarle nella pipeline CI/CD.
Esplorazione delle vulnerabilità delle immagini
Quando fai clic sulla scheda "Vulnerabilità" nella parte superiore della visualizzazione, puoi vedere tutte le vulnerabilità rilevate nell'immagine. Oltre al riepilogo delle vulnerabilità nella parte superiore, puoi visualizzare l'elenco completo delle vulnerabilità nella tabella in basso. Ogni riga rimanda al bollettino CVE, indicando la gravità e il pacchetto di origine. Per le vulnerabilità per cui è disponibile una correzione, fornisce anche istruzioni su come aggiornare le dipendenze per risolvere il problema.
5. Repository virtuali e remoti
Nella sezione precedente abbiamo utilizzato un singolo repository di immagini per eseguire il push e il pull delle immagini. Questa soluzione è ideale per i casi d'uso su piccola scala, ma presenta delle sfide soprattutto per le organizzazioni più grandi con team diversi che richiedono autonomia sui propri repository. È normale che i team o le unità aziendali abbiano un proprio repository di immagini con autorizzazioni e configurazione proprie. Per semplificare l'utilizzo delle immagini in questi repository e proteggere il consumatore dalla struttura organizzativa sottostante, Artifact Registry fornisce repository virtuali che possono aggregare risorse da più repository sottostanti. Una potenziale architettura potrebbe avere il seguente aspetto:
Repository remoto per Docker Hub
Docker Hub è un registro di immagini pubbliche molto diffuso e ospita molte immagini container open source. Sebbene l'utilizzo diretto del repository pubblico sia semplice, presenta una serie di sfide in un ambiente di produzione che possiamo superare con i repository remoti in Artifact Registry.
I repository remoti ti consentono di eseguire il proxy delle richieste al registro upstream e memorizzare nella cache le immagini durante il percorso. In questo modo non solo si riducono i tempi di download delle immagini, ma si elimina anche la dipendenza dall'uptime del servizio esterno e si ha la possibilità di applicare le stesse norme di sicurezza e di accesso che si applicano alle proprie immagini.
Per creare un repository remoto per Docker Hub, puoi eseguire questo comando in 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"
Ora dovresti vedere un repository aggiuntivo nell'elenco dei repository Artifact Registry:
Per verificare se il repository remoto è in grado di eseguire il proxy delle richieste al repository remoto, esegui questo comando in Cloud Shell per eseguire il pull dell'immagine nginx:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
Una volta eseguito il pull, puoi anche esaminare il repository nella console Cloud e verificare che l'immagine nginx memorizzata nella cache ora fornisca lo stesso report su dipendenze e vulnerabilità che avevamo visto per l'immagine che hai creato personalmente.
Creazione di un repository virtuale
Seguendo le procedure che abbiamo utilizzato finora, puoi creare un numero di repository per ogni team o attività e definire chiaramente la proprietà e le autorizzazioni IAM per ciascuno. Possiamo anche creare proxy per i repository remoti, rendendo più facile e sicuro l'utilizzo di immagini di terze parti. Lo svantaggio di questo elevato numero di repository è evidente se sposti la prospettiva sul consumatore di queste immagini. Come fa uno sviluppatore a sapere quale repository di immagini deve utilizzare nel deployment?
Per semplificare l'utilizzo e nascondere i repository sottostanti dietro un livello di astrazione, puoi creare un repository virtuale in Artifact Registry con il seguente comando in 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"
Ora possiamo estrarre le immagini dal repository virtuale senza esporre la struttura sottostante. Per verificare che tutto funzioni come previsto, puoi eseguire questi comandi in 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. Esegui il deployment in Cloud Run
Con i repository e le immagini rispettivi, ora possiamo utilizzarli in un deployment. Per illustrare un caso d'uso di esempio ed evitare di eseguire il deployment di un'infrastruttura aggiuntiva, eseguiremo il deployment del container in Cloud Run. Nella sua forma più semplice, il deployment può essere eseguito eseguendo questo comando in 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
Al termine del deployment, verrà visualizzato l'URL generato automaticamente in cui puoi accedere al servizio.
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
Se apri questo URL in una nuova scheda del browser, dovresti visualizzare il messaggio "Hello World" che indica che l'operazione è andata a buon fine.
7. Rafforzare la sicurezza della catena di fornitura
Ora che l'immagine container è stata implementata in produzione, potrebbe essere il momento giusto per esaminare come rafforzare la nostra supply chain end-to-end. Nella sezione precedente abbiamo esaminato come l'analisi dei container di Artifact Registry fornisce informazioni sulle librerie e sulle licenze utilizzate nell'immagine. Tuttavia, è ancora possibile che utenti malintenzionati introducano contenuti dannosi nell'immagine lungo la catena di fornitura. In questa sezione esploreremo come utilizzare il framework SLSA per introdurre l'attestazione per gli artefatti di build e persino sfruttare le firme crittografiche degli artefatti stessi per garantire che solo gli artefatti attendibili possano essere sottoposti a deployment nel runtime Cloud Run.
Attestazione SLSA con Cloud Build
Il framework SLSA fornisce diversi livelli di prove per gli artefatti della supply chain. La specifica e l'implementazione potrebbero sembrare scoraggianti a prima vista, ma con Cloud Build la creazione dell'attestazione SLSA è semplice come aggiungere una specifica cloudbuild.yaml con requestedVerifyOption impostato su VERIFIED.
Per la nostra applicazione, possiamo eseguire il seguente comando in Cloud Shell per creare un file cloudbuild.yaml nella cartella 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
Ora creiamo un nuovo job Cloud Build che crea una nuova versione della nostra immagine Java Hello World eseguendo il comando seguente in Cloud Shell.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
Una volta completata la build, possiamo andare all'interfaccia utente di Cloud Build nella console Google Cloud e visualizzare il livello SLSA raggiunto aprendo la build e poi esaminando gli artefatti di build in Riepilogo build. L'immagine visualizzata contiene un pulsante per visualizzare "Approfondimenti sulla sicurezza". Quando fai clic, visualizzi l'attestazione SLSA e i report sulle vulnerabilità che abbiamo visto in precedenza nell'interfaccia utente di Artifact Registry quando abbiamo eseguito il push della build locale.
La provenienza SLSA per la nostra immagine può essere recuperata anche eseguendo questo comando in Cloud Shell:
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
Richiedere la provenienza di Cloud Build con l'autorizzazione binaria
Con la pipeline Cloud Build in funzione, non sarebbe fantastico assicurarsi che tutte le immagini di cui eseguiamo il deployment in produzione siano state create utilizzando questo ambiente di build programmabile e riproducibile?
È qui che entra in gioco Autorizzazione binaria. Ti consente di inserire un gatekeeper davanti ai runtime dei container che ispeziona l'immagine container e verifica l'esistenza di un'attestazione attendibile. Se non viene trovata alcuna attestazione, vengono create voci del log di controllo o il deployment viene bloccato completamente, a seconda della configurazione.
Per modificare la configurazione predefinita di Binary Authorization del nostro progetto in modo da richiedere l'attestazione integrata emessa da Cloud Run, eseguiamo questo comando in 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
Qui puoi ovviamente aggiungere anche i tuoi attestatori personalizzati, ma questo non rientra nell'ambito di questo codelab e viene lasciato come esercizio facoltativo per i compiti a casa.
Per applicare l'autorizzazione binaria al nostro servizio Cloud Run, esegui questo comando in Cloud Shell:
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
Verifichiamo che l'autorizzazione binaria sia applicata correttamente eseguendo nuovamente il deployment dell'immagine creata localmente.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
Come previsto, dovresti ricevere un messaggio di errore che spiega perché l'immagine non è stata implementata, simile a questo:
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
Per eseguire il deployment di una nuova versione nel nostro servizio Cloud Run, dobbiamo quindi fornire un'immagine creata con 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
Questa volta il deployment dovrebbe riuscire e mostrare un messaggio di operazione riuscita simile a quello riportato di seguito:
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. Gestione dei pacchetti di linguaggio Java Maven
In questa sezione vedrai come configurare un repository Java di Artifact Registry e caricare pacchetti al suo interno, utilizzandoli in diverse applicazioni.
Crea un repository di pacchetti Maven
Da Cloud Shell, esegui questo comando per creare un repository per gli artefatti Java:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Fai clic su Autorizza se viene visualizzato il prompt di autorizzazione di Cloud Shell
Vai alla console Google Cloud - Artifact Registry - Repository e nota il repository Maven appena creato denominato java-repo. Se fai clic su questo repository, puoi vedere che al momento è vuoto.
Configura l'autenticazione in Artifact Repository
Utilizza il seguente comando per aggiornare la posizione nota per le credenziali predefinite dell'applicazione (ADC) con le credenziali del tuo account utente in modo che l'helper delle credenziali di Artifact Registry possa autenticarsi utilizzandole quando si connette ai repository:
gcloud auth login --update-adc
Configura Maven per Artifact Registry
Esegui questo comando per stampare la configurazione del repository da aggiungere al tuo progetto Java:
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
Apri pom.xml nell'editor di Cloud Shell eseguendo questo comando in Cloud Shell dalla directory helloworld:
cloudshell edit pom.xml
e aggiungi le impostazioni restituite alle sezioni appropriate del file.
Aggiorna la sezione 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>
Aggiorna la sezione repository
<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>
Aggiorna la sezione Estensioni in Build
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.1.0</version>
</extension>
</extensions>
Ecco un esempio del file completo per riferimento. Assicurati di sostituire <PROJECT> con l'ID progetto.
<?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>
Carica il pacchetto Java su Artifact Registry
Con Artifact Registry configurato in Maven, ora puoi utilizzare Artifact Registry per archiviare i file JAR Java da utilizzare in altri progetti della tua organizzazione.
Esegui questo comando per caricare il pacchetto Java su Artifact Registry:
mvn deploy
Controlla il pacchetto Java in Artifact Registry
Vai a Cloud Console - Artifact Registry - Repositories fai clic su java-repo e verifica che l'artefatto binario helloworld sia presente:
9. Complimenti!
Congratulazioni, hai completato il codelab.
Argomenti trattati
- Repository creati per container e pacchetti di linguaggio
- Gestire le immagini container con Artifact Registry
- Artifact Registry integrato con Cloud Code
- Configurato Maven per utilizzare Artifact Registry per le dipendenze Java
Esegui la pulizia
Esegui questo comando in Cloud Shell per eliminare l'intero progetto
gcloud projects delete $PROJECT_ID