Approfondimento su Artifact Registry

Approfondimento su Artifact Registry

Informazioni su questo codelab

subjectUltimo aggiornamento: dic 4, 2024
account_circleScritto da: Giovanni Galloro, Daniel Strebel

1. Panoramica

Artifact Registry è il gestore pacchetti completamente gestito per OCI e fornisce uno strumento unificato per gestire le immagini container e i pacchetti di linguaggio OCI (come Maven e npm).

Artifact Registry è completamente integrato con una vasta gamma di altri servizi Google Cloud, come nei seguenti esempi:

  • Cloud Build può caricare direttamente gli artefatti delle immagini 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 abilita funzionalità di ottimizzazione delle prestazioni avanzate come lo streaming di immagini.
  • Artifact Registry può fungere da punto di rilevamento per Artifact Analysis al fine di monitorare continuamente la presenza di vulnerabilità note.
  • Cloud IAM fornisce un controllo coerente e granulare sull'accesso e sulle autorizzazioni degli elementi.

Questo lab ti guiderà attraverso molte di queste funzionalità sotto forma di tutorial pratico.

Cosa imparerai a fare

Quali sono gli obiettivi didattici di questo lab?

  • Crea repository diversi per contenitori e pacchetti di lingua
  • Creare e utilizzare immagini container con Artifact Registry
  • Utilizza Artifact Registry per analizzare la posizione di sicurezza e i contenuti degli elementi
  • Configurare e utilizzare Artifact Registry per le dipendenze Maven di Java

2. Configurazione e requisiti

Configurazione dell'ambiente a tuo ritmo

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

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Il nome del progetto è il nome visualizzato per i partecipanti al progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
  • L'ID progetto è univoco per tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca; di solito non ti interessa quale sia. Nella maggior parte dei codelab, dovrai fare riferimento al tuo ID progetto (in genere identificato come PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare il tuo e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimane invariato per tutta la durata del progetto.
  • Per tua informazione, esiste un terzo valore, un Numero progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
  1. Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare le API/risorse Cloud. La partecipazione a questo codelab non ha costi, o quasi. Per arrestare le risorse ed evitare di incorrere in fatturazione al termine di questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud sono idonei al programma Prova senza costi di 300$.

Configura gcloud

In Cloud Shell, imposta l'ID progetto e il numero di progetto. Salvale 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 seguente.

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

3. Eseguire il push delle immagini container

Crea un repository Docker su Artifact Registry

Come accennato in precedenza, Artifact Registry supporta diversi formati di repository che ti consentono di gestire immagini container e pacchetti di linguaggio. Le interazioni con i diversi tipi di repository di elementi 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 specifiche dell'API degli elementi, Artifact Registry deve gestire gli elementi nei tipi di repository corrispondenti. Quando crei un nuovo repository, devi passare il flag --repository-format per indicare il tipo di repository.

Per creare un primo repository per le immagini Docker, esegui il seguente 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 alla console Google Cloud - Artifact Registry - Repository e noterai il repository Docker appena creato denominato container-example. Se fai clic su di esso, puoi vedere che al momento è vuoto

5b854eb010e891c2.png

Configura l'autenticazione di 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 di 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. Vai 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 il comando seguente per creare l'immagine del contenitore e taggarla con il percorso completo del registry degli elementi:

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

Esegui il push dell'immagine del contenitore in Artifact Registry

Esegui il seguente comando per eseguire il push dell'immagine del contenitore 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 - Repositories. Apri il repository container-example e verifica che l'immagine java-hello-world sia presente.

88e4b26e8536afb2.png

Fai clic sull'immagine e prendi nota dell'immagine contrassegnata come 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 vedere il numero di vulnerabilità rilevate per questa revisione dell'immagine. Esploreremo le vulnerabilità e altri approfondimenti sugli elementi nella sezione successiva.

55406d03cf0c96b8.png

4. Ispezione delle immagini container

Ora che hai eseguito il push della tua prima immagine nel repository container-example, possiamo esaminarla più in dettaglio. Nella scheda Versioni, fai clic sulla versione appena creata. Per visualizzare l'immagine in modo più dettagliato:

44c3f28dd457ed1d.png

Il pulsante di copia in alto è particolarmente utile in quanto fornisce un modo semplice per accedere all'URI dell'immagine completo della versione dell'immagine, incluso l'hash SHA. Questo URI può essere utilizzato per estrarre una versione dell'immagine specifica o come riferimento immagine in un deployment Kubernetes o in un servizio Cloud Run. Per testare l'URI immagine, puoi eseguire il seguente comando in Cloud Shell:

docker pull $IMAGE_URI

Informazioni sulle dipendenze

Se passi alla scheda "Dipendenze" in alto, puoi vedere tutte le dipendenze rilevate nell'immagine. Tieni presente che vengono elencate sia le dipendenze a livello di lingua sia a livello di sistema operativo. Puoi anche visualizzare le licenze software associate a ciascuna dipendenza.

af03348529575dbc.png

Se guardi attentamente, puoi vedere che le informazioni SBOM non sono ancora state inserite. Per compilare il SOM per l'elemento, puoi eseguire il seguente comando in Cloud Shell utilizzando l'URI immagine completo che possiamo copiare dalla barra del breadcrumb in alto.

gcloud artifacts sbom export --uri $IMAGE_URI

Dopo aver aggiornato la pagina, questa conterrà un link all'SBOM generato automaticamente e archiviato in Cloud Storage. Se utilizzi gli SBOM per le tue immagini, ti consigliamo di generarli automaticamente per i tuoi artefatti e di includere la generazione nella pipeline CI/CD.

Esplorazione delle vulnerabilità delle immagini

Se fai clic sulla scheda "Vulnerabilità" nella parte superiore della visualizzazione, puoi vedere tutte le vulnerabilità rilevate nell'immagine. Oltre al riepilogo delle vulnerabilità in alto, puoi visualizzare l'elenco completo delle vulnerabilità nella tabella in basso. Ogni riga rimanda al bollettino CVE, che ne indica la gravità e il pacchetto di origine. Per le vulnerabilità per le quali è disponibile una correzione, vengono fornite anche istruzioni su come aggiornare le dipendenze per correggere la vulnerabilità.

fda03e6fd758ddef.png

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 è ottima per casi d'uso su piccola scala, ma presenta delle sfide, in particolare per le organizzazioni più grandi con team diversi che richiedono autonomia sui propri repository. È normale che i team o le unità aziendali abbiano il proprio repository di immagini con le proprie autorizzazioni e configurazioni. Per semplificare l'utilizzo delle immagini in questi repository e per proteggere il consumatore dalla struttura organizzativa sottostante, Artifact Registry fornisce repository virtuali che possono aggregare le risorse di più repository sottostanti. Una potenziale architettura potrebbe avere il seguente aspetto:

c6488dc5a6bfac3.png

Repository remoto per Docker Hub

Docker Hub è un registry di immagini pubbliche molto utilizzato 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 registry a monte e memorizzare nella cache le immagini lungo il percorso. In questo modo, non solo riduci i tempi di download delle immagini, ma rimuovi anche la dipendenza dal tempo di attività del servizio esterno e hai la possibilità di applicare gli stessi criteri di sicurezza e accesso che applichi alle tue immagini.

Per creare un repository remoto per Docker Hub, puoi eseguire il seguente 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 di Artifact Registry:

7e174a9944c5f34c.png

Per verificare se il tuo repository remoto è in grado di eseguire il proxy delle richieste al repository remoto, esegui il seguente 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 completato il pull, puoi anche esaminare il repository nella console Cloud e verificare che l'immagine nginx memorizzata nella cache ora fornisca gli stessi report sulle dipendenze e sulle vulnerabilità che abbiamo visto per l'immagine che hai creato.

Creazione di un repository virtuale

Seguendo le procedure che abbiamo utilizzato finora, puoi creare una serie 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. Il rovescio della medaglia di questo numero elevato di repository è evidente se cambi prospettiva e ti metti nei panni del consumatore di queste immagini. In che modo uno sviluppatore deve sapere quale repository di immagini 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 i seguenti 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

Ora che i rispettivi repository e le immagini sono stati configurati, 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 nostro contenitore in Cloud Run. Nella sua forma più semplice, il deployment può essere eseguito eseguendo il seguente 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, viene visualizzato l'URL generato automaticamente tramite il quale 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 l'URL in una nuova scheda del browser, dovresti visualizzare il messaggio di esito positivo "Hello World".

852a8748c1543736.png

7. Rafforzare la sicurezza della catena di approvvigionamento

Ora che l'immagine del contenitore è stata implementata, potrebbe essere un buon momento per capire come possiamo rafforzare la nostra catena di approvvigionamento end-to-end. Nella sezione precedente abbiamo esaminato in che modo l'analisi dei container di Artifact Registry fornisce informazioni sulle librerie e sulle licenze utilizzate nell'immagine. Tuttavia, è ancora possibile che attori malintenzionati introducano contenuti dannosi nella tua immagine lungo la catena di approvvigionamento. In questa sezione esploreremo come possiamo utilizzare il framework SLSA per introdurre l'attestazione per gli elementi di build e persino sfruttare le firme crittografiche degli elementi stessi per garantire che solo gli elementi attendibili possano essere dispiacciati nel nostro runtime Cloud Run.

Attestazione SLSA con Cloud Build

Il framework SLSA fornisce diversi livelli di prove per gli elementi della catena di approvvigionamento. La specifica e l'implementazione potrebbero sembrare scoraggianti a prima vista, ma con Cloud Build la creazione dell'attestazione SLSA è semplice come aggiungere la creazione di 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 genera una nuova versione dell'immagine Java Hello World eseguendo il seguente comando 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 accedere all'interfaccia utente di Cloud Build nella console Google Cloud e visualizzare il livello SLSA raggiunto aprendo la build e poi esaminando gli elementi della build in Riepilogo build. L'immagine visualizzata ha un pulsante per visualizzare "Approfondimenti sulla sicurezza". Quando fai clic, viene visualizzata l'attestazione SLSA, oltre ai report sulle vulnerabilità che abbiamo visto in precedenza nell'interfaccia utente di Artifact Registry quando abbiamo eseguito il push della build locale.

f6154004bfcddc16.png

L'origine SLSA della nostra immagine può essere recuperata anche eseguendo il seguente 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 l'origine di Cloud Build con l'autorizzazione binaria

Con la pipeline Cloud Build implementata, 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?

Ed è qui che entra in gioco l'Autorizzazione binaria. Ti consente di inserire un gatekeeper davanti ai runtime dei container che ispeziona l'immagine del contenitore e verifica l'esistenza di un'attestazione attendibile. Se non viene trovata alcuna attestazione, vengono create voci nel log di controllo o il deployment viene bloccato completamente, a seconda della configurazione.

Per modificare la configurazione predefinita di Autorizzazione binaria del nostro progetto in modo che richieda l'attestazione integrata emessa da Cloud Run, eseguiamo il seguente 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 esula dall'ambito di questo codelab e viene lasciato come compito extracurricolare facoltativo.

Per applicare l'autorizzazione binaria al nostro servizio Cloud Run, eseguiamo il seguente comando in Cloud Shell:

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

Testiamo l'applicazione corretta di Autorizzazione binaria 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é non è stato possibile eseguire il deployment dell'immagine, simile al seguente:

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 viene spiegato come configurare un repository Java di Artifact Registry e caricare i pacchetti al suo interno, per utilizzarli in diverse applicazioni.

Creare un repository di pacchetti Maven

Da Cloud Shell, esegui il comando seguente per creare un repository per gli elementi 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 - Repositories e controlla il repository Maven appena creato denominato java-repo. Se fai clic su di esso, puoi vedere che al momento è vuoto.

Configura l'autenticazione nel repository di artefatti

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 lo strumento di assistenza per le credenziali di Artifact Registry possa autenticarsi utilizzandole quando si connette ai repository:

gcloud auth login --update-adc

Configura Maven per Artifact Registry

Esegui il seguente comando per stampare la configurazione del repository da aggiungere al 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 il seguente 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 da conservare come riferimento. Assicurati di sostituire <PROJECT> con l'ID del tuo 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 in Artifact Registry

Con Artifact Registry configurato in Maven, ora puoi utilizzarlo per archiviare i file JAR Java da utilizzare in altri progetti della tua organizzazione.

Esegui il comando seguente 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'elemento helloworld binario sia presente:

a95d370ee0fd9af0.png

9. Complimenti!

Complimenti, hai completato il codelab.

Cosa hai coperto

  • Repository creati per container e pacchetti di lingua
  • Immagini container gestite con Artifact Registry
  • Artifact Registry integrato con Cloud Code
  • Maven è stato configurato per utilizzare Artifact Registry per le dipendenze Java

Esegui la pulizia

Esegui il comando seguente in Cloud Shell per eliminare l'intero progetto

gcloud projects delete $PROJECT_ID