Présentation détaillée d'Artifact Registry

Présentation détaillée d'Artifact Registry

À propos de cet atelier de programmation

subjectDernière mise à jour : déc. 4, 2024
account_circleRédigé par Giovanni Galloro, Daniel Strebel

1. Présentation

Artifact Registry est un gestionnaire de paquets entièrement géré qui fournit un outil unifié pour gérer vos images de conteneurs OCI et vos packages de langages (tels que Maven et npm).

Artifact Registry est entièrement intégré à la vaste gamme d'autres services Google Cloud, comme dans les exemples suivants:

  • Cloud Build peut importer directement des artefacts d'image dans Artifact Registry.
  • Cloud Deploy peut déployer les images Artifact Registry directement dans divers environnements d'exécution.
  • Il fournit des images aux environnements d'exécution de conteneur tels que Cloud Run et GKE, et permet d'utiliser des fonctionnalités avancées d'optimisation des performances telles que le streaming d'images.
  • Artifact Registry peut servir de point de détection pour Artifact Analysis afin de surveiller en continu les failles connues.
  • Cloud IAM fournit un contrôle cohérent et précis des autorisations et de l'accès aux artefacts.

Cet atelier vous présentera de nombreuses fonctionnalités sous la forme d'un tutoriel pratique.

Objectifs de l'atelier

Quels sont les objectifs d'apprentissage de cet atelier ?

  • Créer des dépôts distincts pour les conteneurs et les packages de langue
  • Créer et utiliser des images de conteneur avec Artifact Registry
  • Utiliser Artifact Registry pour analyser la posture de sécurité et le contenu de vos artefacts
  • Configurer et utiliser Artifact Registry pour les dépendances Maven Java

2. Préparation

Configuration de l'environnement d'auto-formation

  1. Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. Si vous n'avez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pourrez toujours le modifier.
  • L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
  • Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.
  1. Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.

Configurer gcloud

Dans Cloud Shell, définissez l'ID et le numéro de votre projet. Enregistrez-les en tant que variables PROJECT_ID et PROJECT_NUMBER.

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

Activer les services 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

Obtenir le code source

Le code source de ce tutoriel se trouve dans l'organisation GoogleCloudPlatform sur GitHub. Clonez-le à l'aide de la commande ci-dessous.

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

3. Transférer des images de conteneur

Créer un dépôt Docker dans Artifact Registry

Comme indiqué précédemment, Artifact Registry est compatible avec différents formats de dépôts qui vous permettent de gérer les images de conteneurs et les packages de langages. Les interactions avec les différents types de dépôts d'artefacts sont définies dans des spécifications et sont des normes largement adoptées. Par exemple, les requêtes de dépendances Maven sont différentes des requêtes de dépendances Node.

Pour prendre en charge les spécifications d'API d'artefact spécifiques, Artifact Registry doit gérer vos artefacts dans les types de dépôts correspondants. Lorsque vous créez un dépôt, vous transmettez l'indicateur --repository-format pour indiquer le type de dépôt.

Pour créer un premier dépôt d'images Docker, exécutez la commande suivante dans Cloud Shell:

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

Cliquez sur "Autoriser" si l'invite d'autorisation de Cloud Shell s'affiche.

Accédez à la console Google Cloud - Artifact Registry - Repositories et examinez le dépôt Docker que vous venez de créer, nommé container-example. Si vous cliquez dessus, vous constaterez qu'il est vide pour le moment.

5b854eb010e891c2.png

Configurer l'authentification Docker auprès d'Artifact Registry

Lorsque vous vous connectez à Artifact Registry, des identifiants sont nécessaires pour accéder à l'outil. Plutôt que de configurer des identifiants distincts, vous pouvez configurer Docker pour qu'il utilise vos identifiants gcloud de manière transparente.

Dans Cloud Shell, exécutez la commande suivante pour configurer Docker afin qu'il utilise la Google Cloud CLI pour authentifier les requêtes envoyées à Artifact Registry dans la région us-central1 :

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

Si la commande vous invite à confirmer la modification de la configuration Docker de Cloud Shell, appuyez sur Entrée.

Explorer l'application exemple

Un exemple d'application est fourni dans le dépôt Git que vous avez cloné à une étape précédente. Accédez au répertoire Java et examinez le code de l'application.

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

Le dossier contient un exemple d'application Java qui affiche une page Web simple. En plus de divers fichiers non pertinents pour cet atelier spécifique, il contient le code source, dans le dossier src, et un Dockerfile que nous utiliserons pour créer une image de conteneur.

Créer l'image du conteneur

Avant de pouvoir stocker des images de conteneur dans Artifact Registry, vous devez en créer une.

Exécutez la commande suivante pour créer l'image du conteneur et la taguer avec le chemin d'accès complet du dépôt d'artefacts:

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

Transférer l'image de conteneur vers Artifact Registry

Exécutez la commande suivante pour transférer l'image de conteneur vers le dépôt créé précédemment:

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

Examiner l'image dans Artifact Registry

Accédez à la console Google Cloud - Artifact Registry - Repositories (Console Google Cloud - Artifact Registry - Repositories).. Ouvrez le dépôt container-example et vérifiez que l'image java-hello-world s'y trouve.

88e4b26e8536afb2.png

Cliquez sur l'image et notez l'image taguée tag1. Comme nous avons activé l'analyse automatique des images via le service containerscanning.googleapis.com, vous pouvez voir que l'analyse des failles est en cours ou déjà terminée. Une fois l'analyse terminée, vous pouvez voir le nombre de failles détectées pour cette révision d'image. Nous allons explorer les failles et d'autres insights sur les artefacts dans la section suivante.

55406d03cf0c96b8.png

4. Inspecter les images de conteneur

Maintenant que vous avez poussé votre première image vers le dépôt container-example, nous pouvons l'examiner plus en détail. Dans l'onglet "Versions", cliquez sur la version que vous venez de créer. Pour afficher l'image plus en détail:

44c3f28dd457ed1d.png

Le bouton de copie supérieur est particulièrement utile, car il permet d'accéder facilement à l'URI complet de l'image de cette version d'image, y compris au hachage SHA. Cet URI peut ensuite être utilisé pour extraire une version d'image spécifique ou comme référence d'image dans un déploiement Kubernetes ou un service Cloud Run. Pour tester l'URI de l'image, vous pouvez exécuter la commande suivante dans Cloud Shell:

docker pull $IMAGE_URI

Comprendre les dépendances

Dans l'onglet "Dépendances" en haut de la page, vous pouvez voir toutes les dépendances détectées dans votre image. Notez qu'il liste à la fois les dépendances au niveau de la langue et de l'OS. Vous pouvez également consulter les licences logicielles associées à chacune des dépendances.

af03348529575dbc.png

Si vous regardez attentivement, vous pouvez voir que les informations du SBOM ne sont pas encore renseignées. Pour renseigner la SOM de votre artefact, vous pouvez exécuter la commande suivante dans Cloud Shell à l'aide de l'URI de l'image complet que vous pouvez copier dans la barre de navigation en haut de l'écran.

gcloud artifacts sbom export --uri $IMAGE_URI

Une fois la page actualisée, elle contiendra un lien vers le SBOM généré automatiquement et stocké dans Cloud Storage. Si vous utilisez des SBOM pour vos images, vous pouvez générer automatiquement des SBOM pour vos artefacts et intégrer la génération à votre pipeline CI/CD.

Explorer les failles des images

Lorsque vous cliquez sur l'onglet "Failles" en haut de l'affichage, vous pouvez voir toutes les failles détectées dans votre image. En plus du résumé des failles en haut de la page, vous pouvez consulter la liste complète des failles dans le tableau en bas. Chaque ligne renvoie au bulletin CVE, indiquant sa gravité et le package à l'origine. Pour les failles pour lesquelles un correctif est disponible, il fournit également des instructions sur la façon de mettre à jour les dépendances pour corriger la faille.

fda03e6fd758ddef.png

5. Dépôts virtuels et distants

Dans la section précédente, nous avons utilisé un seul dépôt d'images pour transférer et extraire nos images. Cette approche fonctionne parfaitement pour les cas d'utilisation à petite échelle, mais pose des défis, en particulier pour les grandes entreprises qui comptent plusieurs équipes qui ont besoin d'autonomie sur leurs dépôts. Il est courant que les équipes ou les unités commerciales disposent de leur propre dépôt d'images avec leurs propres autorisations et leur propre configuration. Pour simplifier l'utilisation des images dans ces dépôts et protéger le consommateur de la structure organisationnelle sous-jacente, Artifact Registry fournit des dépôts virtuels pouvant agréger les ressources de plusieurs dépôts sous-jacents. Une architecture potentielle peut se présenter comme suit:

c6488dc5a6bfac3.png

Dépôt distant pour Docker Hub

Docker Hub est un registre d'images public populaire qui héberge de nombreuses images de conteneurs Open Source. Bien que l'utilisation directe du dépôt public soit simple, elle présente un certain nombre de défis dans un environnement de production que nous pouvons surmonter avec les dépôts distants dans Artifact Registry.

Les dépôts distants vous permettent de proxyer les requêtes vers le registre en amont et de mettre en cache les images en cours de route. Cela permet de réduire les temps de téléchargement des images, mais aussi de supprimer la dépendance vis-à-vis de la disponibilité du service externe et de pouvoir appliquer les mêmes règles de sécurité et d'accès que celles que vous appliquez à vos propres images.

Pour créer un dépôt distant pour Docker Hub, vous pouvez exécuter la commande suivante dans 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"

Un dépôt supplémentaire devrait maintenant s'afficher dans la liste des dépôts Artifact Registry:

7e174a9944c5f34c.png

Pour tester si votre dépôt distant peut proxyer les requêtes vers le dépôt distant, exécutez la commande suivante dans Cloud Shell pour extraire l'image nginx:

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

Une fois la récupération effectuée, vous pouvez également consulter le dépôt dans la console Cloud. L'image nginx mise en cache fournit désormais les mêmes rapports sur les dépendances et les failles que ceux que nous avons vus pour l'image que vous avez créée vous-même.

Créer un dépôt virtuel

En suivant les processus que nous avons utilisés jusqu'à présent, vous pouvez créer un certain nombre de dépôts pour chaque équipe ou entreprise, et définir clairement la propriété et les autorisations IAM pour chacun d'eux. Nous pouvons également créer des proxys pour les dépôts distants, ce qui facilite et sécurise la consommation d'images tierces. L'inconvénient de ce grand nombre de dépôts est évident si vous adoptez le point de vue du consommateur de ces images. Comment un développeur doit-il savoir quel dépôt d'images utiliser pour son déploiement ?

Pour simplifier la consommation et masquer les dépôts sous-jacents derrière une couche d'abstraction, vous pouvez créer un dépôt virtuel dans Artifact Registry à l'aide de la commande suivante dans 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"

Nous pouvons désormais extraire les images du dépôt virtuel sans exposer la structure sous-jacente. Pour vérifier que tout fonctionne comme prévu, vous pouvez exécuter les commandes suivantes dans 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. Déployer dans Cloud Run

Une fois les dépôts et les images respectifs en place, nous pouvons les utiliser dans un déploiement. Pour illustrer un cas d'utilisation et éviter de déployer une infrastructure supplémentaire, nous allons déployer notre conteneur sur Cloud Run. Dans sa forme la plus simple, le déploiement peut être effectué en exécutant la commande suivante dans 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

Une fois le déploiement terminé, l'URL générée automatiquement vous permettant d'accéder à votre service s'affiche.

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

Si vous ouvrez cette URL dans un nouvel onglet de navigateur, le message "Hello World" doit s'afficher.

852a8748c1543736.png

7. Renforcer la sécurité de la chaîne d&#39;approvisionnement

Maintenant que votre image de conteneur a été déployée, il est peut-être temps d'examiner comment renforcer notre chaîne d'approvisionnement de bout en bout. Dans la section précédente, nous avons vu comment l'analyse des conteneurs d'Artifact Registry fournit des insights sur les bibliothèques et les licences utilisées dans l'image. Toutefois, il est toujours possible que des acteurs malveillants introduisent du contenu nuisible dans votre image tout au long de la chaîne d'approvisionnement. Dans cette section, nous allons voir comment utiliser le framework SLSA pour introduire une attestation pour les artefacts de compilation et même exploiter les signatures cryptographiques des artefacts eux-mêmes pour nous assurer que seuls les artefacts approuvés peuvent être déployés dans notre environnement d'exécution Cloud Run.

Attestation SLSA avec Cloud Build

Le framework SLSA fournit différents niveaux de preuve pour les artefacts de la chaîne d'approvisionnement. La spécification et l'implémentation peuvent sembler intimidantes au premier abord, mais avec Cloud Build, créer une attestation SLSA est aussi simple que d'ajouter une spécification cloudbuild.yaml avec requestedVerifyOption défini sur VERIFIED.

Pour notre application, nous pouvons exécuter la commande suivante dans Cloud Shell pour créer un fichier cloudbuild.yaml dans le dossier 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

Nous allons maintenant créer un job Cloud Build qui compile une nouvelle version de notre image Java Hello World en exécutant la commande suivante dans Cloud Shell.

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

Une fois la compilation terminée, nous pouvons accéder à l'interface utilisateur de Cloud Build dans la console Google Cloud et afficher le niveau SLSA que nous avons atteint en ouvrant notre compilation, puis en examinant les artefacts de compilation sous "Récapitulatif de la compilation". L'image affichée comporte un bouton permettant d'afficher les "Insights de sécurité". Lorsque vous cliquez dessus, l'attestation SLSA s'affiche, ainsi que les rapports de vulnérabilité familiers que nous avons vus précédemment dans l'interface utilisateur d'Artifact Registry lorsque nous avons poussé notre build local.

f6154004bfcddc16.png

La provenance SLSA de notre image peut également être récupérée en exécutant la commande suivante dans Cloud Shell:

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

Exiger la provenance Cloud Build avec l'autorisation binaire

Avec le pipeline Cloud Build en place, ne serait-il pas judicieux de s'assurer que toutes les images que nous déployons en production ont été créées à l'aide de cet environnement de compilation programmable et reproductible ?

C'est là qu'intervient l'autorisation binaire. Il vous permet de placer un gardien devant vos environnements d'exécution de conteneur qui inspecte l'image du conteneur et vérifie l'existence d'une attestation fiable. Si aucune attestation n'est trouvée, des entrées de journal d'audit sont créées ou le déploiement est entièrement bloqué, selon la configuration.

Pour modifier la configuration par défaut de l'autorisation binaire de notre projet afin d'exiger l'attestation intégrée émise par Cloud Run, nous exécutons la commande suivante dans 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

Vous pouvez bien entendu également ajouter vos propres attesteurs personnalisés, mais cela dépasse le cadre de cet atelier de programmation et reste un exercice facultatif en dehors du cours.

Pour appliquer l'autorisation binaire à notre service Cloud Run, nous exécutons la commande suivante dans Cloud Shell:

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

Testons que notre autorisation binaire est appliquée correctement en redéployant d'abord l'image compilée localement.

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

Comme prévu, un message d'erreur s'affiche pour expliquer pourquoi l'image n'a pas pu être déployée. Il ressemble à ceci:

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

Pour déployer une nouvelle version dans notre service Cloud Run, nous devons donc fournir une image créée avec 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

Cette fois, le déploiement devrait réussir et un message semblable à celui ci-dessous s'afficher:

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. Gérer les packages de langage Java Maven

Dans cette section, vous allez découvrir comment configurer un dépôt Java Artifact Registry et y importer des packages, puis les utiliser dans différentes applications.

Créer un dépôt de packages Maven

Dans Cloud Shell, exécutez la commande suivante pour créer un dépôt d'artefacts Java:

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

Cliquez sur "Autoriser" si l'invite d'autorisation de Cloud Shell s'affiche.

Accédez à la console Google Cloud - Artifact Registry - Repositories (Registre d'artefacts - Dépôts) et examinez le dépôt Maven que vous venez de créer, nommé java-repo. Si vous cliquez dessus, vous constaterez qu'il est vide pour le moment.

Configurer l'authentification sur le dépôt d'artefacts

Utilisez la commande suivante pour mettre à jour l'emplacement connu des identifiants par défaut de l'application (ADC) avec les identifiants de votre compte utilisateur afin que l'assistant d'identification Artifact Registry puisse s'en servir pour s'authentifier lors de la connexion aux dépôts:

gcloud auth login --update-adc

Configurer Maven pour Artifact Registry

Exécutez la commande suivante pour imprimer la configuration du dépôt à ajouter à votre projet Java:

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

Ouvrez le fichier pom.xml dans l'éditeur Cloud Shell en exécutant la commande suivante dans Cloud Shell à partir du répertoire helloworld:

cloudshell edit pom.xml

et ajoutez les paramètres renvoyés aux sections appropriées du fichier.

Mettre à jour la section 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>

Mettre à jour la section Dépôts

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

Mettez à jour la section extensions sous build (compilation).

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

Voici un exemple de fichier complet pour référence. Veillez à remplacer <PROJECT> par l'ID de votre projet.

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

Importer votre package Java dans Artifact Registry

Maintenant qu'Artifact Registry est configuré dans Maven, vous pouvez l'utiliser pour stocker des fichiers JAR Java à utiliser par d'autres projets de votre organisation.

Exécutez la commande suivante pour importer votre package Java dans Artifact Registry:

mvn deploy

Vérifier le package Java dans Artifact Registry

Accédez à Cloud Console - Artifact Registry - Repositories (Console Cloud - Artifact Registry - Repositories). Cliquez sur java-repo et vérifiez que l'artefact binaire helloworld est présent:

a95d370ee0fd9af0.png

9. Félicitations !

Félicitations, vous avez terminé cet atelier de programmation.

Points abordés

  • Dépôts créés pour les conteneurs et les packages de langages
  • Images de conteneurs gérées avec Artifact Registry
  • Intégration d'Artifact Registry à Cloud Code
  • Vous avez configuré Maven pour qu'il utilise Artifact Registry pour les dépendances Java.

Nettoyage

Exécutez la commande suivante dans Cloud Shell pour supprimer l'intégralité du projet :

gcloud projects delete $PROJECT_ID