1. Présentation
Artifact Registry est un gestionnaire de packages 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é à un large éventail 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 différents environnements d'exécution.
- Il fournit des images aux environnements d'exécution de conteneurs tels que Cloud Run et GKE, et permet des fonctionnalités d'optimisation des performances avancées telles que le streaming d'images.
- Artifact Registry peut servir de point de détection pour Artifact Analysis afin de surveiller en permanence les failles connues.
- Cloud IAM fournit un contrôle cohérent et précis des accès et des autorisations pour les artefacts.
Cet atelier vous présentera un grand nombre de ces 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 langages
- Créer et utiliser des images de conteneurs 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 Java Maven
2. Préparation
Configuration de l'environnement d'auto-formation
- 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.
- 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.
- 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 cet atelier 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 conteneurs
Créez un dépôt Docker dans Artifact Registry :
Comme mentionné précédemment, Artifact Registry est compatible avec différents formats de dépôt 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 des spécifications d'API d'artefacts 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 le flag --repository-format pour indiquer le type de dépôt.
Pour créer un premier dépôt pour les images Docker, exécutez la commande suivante depuis 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 > Dépôts. Vous devriez voir 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.
Configurer l'authentification Docker pour Artifact Registry
Lorsque vous vous connectez à Artifact Registry, des identifiants sont nécessaires pour vous donner accès. 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 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 demande de confirmer la modification de la configuration Docker de Cloud Shell, appuyez sur Entrée.
Explorer l'exemple d'application
Un exemple d'application est fourni dans le dépôt Git que vous avez cloné lors d'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. Outre divers fichiers qui ne sont pas pertinents pour cet atelier, 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 de 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 de conteneur et lui attribuer le tag avec le chemin d'accès complet à Artifact Registry :
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
Vérifier l'image dans Artifact Registry
Accédez à la console Google Cloud > Artifact Registry > Dépôts.. Ouvrez le dépôt container-example et vérifiez que l'image java-hello-world s'y trouve.
Cliquez sur l'image et notez qu'elle est taguée tag1. Comme nous avons activé l'analyse automatique des images via le service containerscanning.googleapis.com, vous pouvez constater 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 examinerons les failles et autres informations sur les artefacts dans la section suivante.
4. Inspecter les images de conteneurs
Maintenant que vous avez envoyé votre première image au dépôt container-example, nous pouvons l'examiner plus en détail. Dans l'onglet "Versions", cliquez sur la version que nous venons de créer. Pour afficher l'image plus en détail :
Le bouton "Copier" situé en haut est particulièrement utile, car il permet d'accéder facilement à l'URI complet de la version de l'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
En passant à l'onglet "Dépendances" en haut de l'écran, vous pouvez voir toutes les dépendances détectées dans votre image. Notez qu'il liste les dépendances au niveau des dépendances linguistiques et de l'OS. Vous pouvez également consulter les licences logicielles associées à chacune des dépendances.
Si vous regardez attentivement, vous verrez que les informations de la SBOM ne sont pas encore renseignées. Pour remplir la SOM de votre artefact, vous pouvez exécuter la commande suivante dans Cloud Shell en utilisant l'URI d'image complet que vous pouvez copier à partir de la barre de navigation en haut de la page.
gcloud artifacts sbom export --uri $IMAGE_URI
Une fois la page actualisée, elle contient un lien vers la SBOM générée automatiquement et stockée dans Cloud Storage. Si vous vous appuyez sur les SBOM pour vos images, vous pouvez générer automatiquement des SBOM pour vos artefacts et intégrer cette génération à votre pipeline CI/CD.
Explorer les failles d'image
Lorsque vous cliquez sur l'onglet "Failles" en haut de la vue, vous pouvez voir toutes les failles détectées dans votre image. En plus du récapitulatif des failles en haut de la page, vous pouvez consulter la liste complète des failles dans le tableau en bas de la page. Chaque ligne renvoie au bulletin CVE, indiquant sa gravité et le package dont il est issu. Pour les failles pour lesquelles une correction est disponible, il fournit également des instructions sur la manière de mettre à jour les dépendances pour corriger la faille.
5. Dépôts virtuels et à distance
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 très bien pour les cas d'utilisation à petite échelle, mais pose des problèmes, en particulier pour les grandes organisations avec différentes é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 configurations. 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 qui peuvent agréger des ressources provenant de plusieurs dépôts sous-jacents. Voici un exemple d'architecture possible :
Dépôt distant pour Docker Hub
Docker Hub est un registre d'images publiques populaire qui héberge de nombreuses images de conteneurs Open Source. Bien qu'il soit simple d'utiliser directement le dépôt public, cela pose plusieurs problèmes dans un environnement de production. Nous pouvons les résoudre grâce aux dépôts distants dans Artifact Registry.
Les dépôts distants vous permettent de transférer les requêtes vers le registre en amont et de mettre en cache les images en cours de route. Cela permet non seulement de réduire les temps de téléchargement des images, mais aussi de supprimer la dépendance vis-à-vis du temps d'activité du service externe. Vous pouvez ainsi 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 de vos dépôts Artifact Registry :
Pour tester si votre dépôt distant est capable de transférer 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 l'extraction réussie, vous pouvez également consulter le dépôt dans la console Cloud et constater que l'image nginx mise en cache fournit désormais les mêmes rapports sur les dépendances et les failles que ceux que nous avions 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 plusieurs 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 l'utilisation d'images tierces. L'inconvénient de ce grand nombre de dépôts est évident si vous vous mettez à la place du consommateur de ces images. Comment un développeur peut-il savoir quel dépôt d'images utiliser dans 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
Maintenant que les dépôts et les images sont 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 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" devrait s'afficher.
7. Renforcer la sécurité de la chaîne d'approvisionnement
Maintenant que votre image de conteneur a été déployée, il est peut-être temps de voir 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 informations sur les bibliothèques et les licences utilisées dans l'image. Toutefois, des personnes malveillantes peuvent toujours introduire du contenu dangereux 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 l'attestation des artefacts de compilation et même tirer parti des signatures cryptographiques des artefacts eux-mêmes pour s'assurer que seuls les artefacts fiables 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, la création d'une attestation SLSA est aussi simple que l'ajout d'une spécification cloudbuild.yaml avec requestedVerifyOption défini sur VERIFIED.
Pour notre application, nous pouvons exécuter la commande suivante dans Cloud Shell afin de 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 compilera 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 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ésumé de la compilation". L'image qui s'y affiche comporte un bouton permettant d'accéder aux "Informations sur la sécurité". Lorsque vous cliquez dessus, vous voyez l'attestation SLSA ainsi que les rapports de failles habituels que nous avons vus précédemment dans l'interface utilisateur d'Artifact Registry lorsque nous avons envoyé notre build local.
Vous pouvez également récupérer la provenance SLSA de notre image 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
Maintenant que le pipeline Cloud Build est 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 gatekeeper devant vos environnements d'exécution de conteneurs, qui inspecte l'image du conteneur et vérifie l'existence d'une attestation de confiance. 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 également ajouter vos propres attestataires personnalisés, mais cela dépasse le cadre de cet atelier de programmation et est laissé comme exercice supplémentaire facultatif.
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 l'application correcte de l'autorisation binaire en redéployant d'abord l'image créé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 devrait s'afficher pour expliquer pourquoi l'image n'a pas pu être déployée. Il devrait ressembler à 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 sur 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-ci, le déploiement devrait réussir et afficher un message de réussite semblable à celui ci-dessous :
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 pour les 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 > Dépôts. Vous devriez voir 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 auprès du dépôt Artifact
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. L'assistant d'identification Artifact Registry pourra ainsi 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 de 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>
Mettez à jour la section repositories.
<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.
<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 qui pourront être utilisés 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 à Console Cloud > Artifact Registry > Dépôts. Cliquez sur java-repo et vérifiez que l'artefact binaire helloworld s'y trouve :
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
- Gérer des images de conteneurs avec Artifact Registry
- Intégrer Artifact Registry à Cloud Code
- Configurer Maven pour utiliser 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