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
- 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 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.
- 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
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.
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.
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:
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.
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à.
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:
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:
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".
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.
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:
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