Acerca de este codelab
1. Descripción general
Artifact Registry es el administrador de paquetes completamente administrado que proporciona una herramienta unificada para administrar tus imágenes de contenedores OCI y paquetes de lenguajes (como Maven y npm).
Artifact Registry está completamente integrado en la amplia variedad de otros servicios de Google Cloud, como en los siguientes ejemplos:
- Cloud Build puede subir artefactos de imagen directamente a Artifact Registry.
- Cloud Deploy puede implementar las imágenes de Artifact Registry directamente en varios entornos de ejecución.
- Proporciona imágenes a los entornos de ejecución de contenedores, como Cloud Run y GKE, y habilita funciones avanzadas de optimización del rendimiento, como la transmisión de imágenes.
- Artifact Registry puede servir como punto de detección para que Artifact Analysis supervise de forma continua las vulnerabilidades conocidas.
- Cloud IAM proporciona un control coherente y detallado sobre el acceso y los permisos de los artefactos.
En este lab, se explicarán muchas de estas funciones en forma de instructivo práctico.
Qué aprenderás
¿Cuáles son los objetivos de aprendizaje de este lab?
- Crea repositorios diferentes para contenedores y paquetes de lenguaje
- Crea y usa imágenes de contenedor con Artifact Registry
- Usa Artifact Registry para analizar la postura de seguridad y el contenido de tus artefactos
- Configura y usa Artifact Registry para dependencias de Maven de Java
2. Configuración y requisitos
Cómo configurar el entorno a tu propio ritmo
- Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.
- El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
- El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como
PROJECT_ID
). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto. - Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.
- A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.
Configura gcloud
Establece el ID y número del proyecto en Cloud Shell. Guárdalos como variables PROJECT_ID
y PROJECT_NUMBER
.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
Habilita los Servicios de 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
Obtén el código fuente
El código fuente de este lab se encuentra en la organización GoogleCloudPlatform de GitHub. Clónalo con el siguiente comando.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. Cómo enviar imágenes de contenedor
Crea un repositorio de Docker en Artifact Registry
Como se mencionó antes, Artifact Registry admite diferentes formatos de repositorio que te permiten administrar imágenes de contenedores y paquetes de lenguaje. Las interacciones con los diferentes tipos de repositorios de artefactos se definen en las especificaciones y son estándares ampliamente adoptados. Por ejemplo, las solicitudes de dependencias de Maven son diferentes de las solicitudes de dependencias de Node.
Para admitir especificaciones de API de artefactos específicas, Artifact Registry debe administrar tus artefactos en los tipos de repositorio correspondientes. Cuando creas un repositorio nuevo, pasas la marca --repository-format
para indicar el tipo de repositorio.
Para crear un primer repositorio para imágenes de Docker, ejecuta el siguiente comando desde Cloud Shell:
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
Haz clic en Autorizar si aparece el mensaje de autorización de Cloud Shell.
Ve a la consola de Google Cloud - Artifact Registry - Repositories y observa el repositorio de Docker que acabas de crear llamado container-example
. Si haces clic en él, verás que está vacío en este momento.
Configura la autenticación de Docker en Artifact Registry
Cuando te conectas a Artifact Registry, se requieren credenciales para proporcionar acceso. En lugar de configurar credenciales independientes, Docker se puede configurar para usar tus credenciales de gcloud sin problemas.
Desde Cloud Shell, ejecuta el siguiente comando para configurar Docker para que use Google Cloud CLI y autentique las solicitudes a Artifact Registry en la región us-central1
:
gcloud auth configure-docker us-central1-docker.pkg.dev
Si el comando solicita una confirmación para cambiar la configuración de Docker de Cloud Shell, presiona Intro.
Explora la aplicación de ejemplo
Se proporciona una aplicación de ejemplo en el repositorio de git que clonaste en un paso anterior. Cambia al directorio de Java y revisa el código de la aplicación.
cd java-docs-samples/run/helloworld/
ls
La carpeta contiene una aplicación de Java de ejemplo que renderiza una página web simple: además de varios archivos que no son relevantes para este lab específico, contiene el código fuente, en la carpeta src
, y un Dockerfile que usaremos para compilar una imagen de contenedor.
Compila la imagen del contenedor
Antes de poder almacenar imágenes de contenedor en Artifact Registry, deberás crear una.
Ejecuta el siguiente comando para compilar la imagen de contenedor y etiquetarla con la ruta de acceso completa del registro de artefactos:
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
Envía la imagen del contenedor a Artifact Registry
Ejecuta el siguiente comando para enviar la imagen de contenedor al repositorio creado anteriormente:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
Revisa la imagen en Artifact Registry
Ve a la consola de Google Cloud - Artifact Registry - Repositories.
Abre el repositorio container-example
y verifica que la imagen java-hello-world
esté allí.
Haz clic en la imagen y anota la imagen etiquetada como tag1
. Como habilitamos el análisis automático de imágenes a través del servicio containerscanning.googleapis.com
, puedes ver que el análisis de vulnerabilidades se está ejecutando o ya se completó. Una vez que se complete, podrás ver la cantidad de vulnerabilidades que se detectaron para esta revisión de imagen. Exploraremos las vulnerabilidades y otras estadísticas de artefactos en la siguiente sección.
4. Cómo inspeccionar imágenes de contenedor
Ahora que enviaste tu primera imagen al repositorio de container-example
, podemos analizarla con más detalle. En la pestaña Versiones, haz clic en la versión que acabamos de crear. Para mostrar la imagen con más detalle, haz lo siguiente:
El botón de copia superior es especialmente útil, ya que proporciona una forma fácil de acceder al URI de imagen completamente calificado de esa versión de imagen, incluido el hash SHA. Este URI se puede usar para extraer una versión de imagen específica o como referencia de imagen en una implementación de Kubernetes o un servicio de Cloud Run. Para probar el URI de la imagen, puedes ejecutar el siguiente comando en Cloud Shell:
docker pull $IMAGE_URI
Información sobre las dependencias
Si vas a la pestaña "Dependencias" en la parte superior, puedes ver todas las dependencias que se detectaron en tu imagen. Ten en cuenta que se enumeran las dependencias a nivel del lenguaje y del SO. También puedes ver las licencias de software que se adjuntan a cada una de las dependencias.
Si observas con atención, verás que la información de la SBOM aún no se propaga. Para propagar el SOM de tu artefacto, puedes ejecutar el siguiente comando en Cloud Shell con el URI de imagen completamente calificado que podemos copiar de la barra de ruta de acceso en la parte superior.
gcloud artifacts sbom export --uri $IMAGE_URI
Una vez que actualices la página, esta contendrá un vínculo al SBOM generado automáticamente y almacenado en Cloud Storage. Si dependes de las SBOM para tus imágenes, te recomendamos que generes SBOM automáticamente para tus artefactos y que la generación forme parte de tu canalización de CI/CD.
Exploración de vulnerabilidades de imágenes
Cuando haces clic en la pestaña “Vulnerabilidades” en la parte superior de la vista, puedes ver todas las vulnerabilidades que se detectaron en tu imagen. Además del resumen de las vulnerabilidades en la parte superior, puedes ver la lista completa de vulnerabilidades en la tabla de la parte inferior. Cada fila incluye un vínculo al boletín CVE, que indica su gravedad y el paquete del que se originó. En el caso de las vulnerabilidades para las que hay una solución disponible, también se proporcionan instrucciones para actualizar las dependencias y solucionarlas.
5. Repositorios virtuales y remotos
En la sección anterior, usamos un solo repositorio de imágenes para enviar y extraer nuestras imágenes. Esto funciona muy bien para casos de uso a pequeña escala, pero presenta desafíos, en especial, para organizaciones más grandes con diferentes equipos que requieren autonomía sobre sus repositorios. Es común que los equipos o las unidades de negocio tengan su propio repositorio de imágenes con sus propios permisos y configuración. Para simplificar el uso de las imágenes en estos repositorios y proteger al consumidor de la estructura organizativa subyacente, Artifact Registry proporciona repositorios virtuales que pueden agregar recursos de varios repositorios subyacentes. Una posible arquitectura podría verse de la siguiente manera:
Repositorio remoto para Docker Hub
Docker Hub es un registro de imágenes públicas popular y aloja muchas imágenes de contenedores de código abierto. Si bien usar el repositorio público directamente es sencillo, presenta una serie de desafíos en un entorno de producción que podemos superar con los repositorios remotos en Artifact Registry.
Los repositorios remotos te permiten usar un proxy para las solicitudes al registro ascendente y almacenar en caché las imágenes en el camino. Esto no solo reduce los tiempos de descarga de las imágenes, sino que también quita la dependencia del tiempo de actividad del servicio externo y te permite aplicar las mismas políticas de seguridad y acceso que aplicas a tus propias imágenes.
Para crear un repositorio remoto para Docker Hub, puedes ejecutar el siguiente comando en 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"
Ahora deberías ver un repositorio adicional en la lista de repositorios de Artifact Registry:
Para probar si tu repositorio remoto puede usar un proxy para las solicitudes al repositorio remoto, ejecuta el siguiente comando en Cloud Shell para extraer la imagen de nginx:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
Una vez que se complete la extracción, también podrás ver el repositorio en la consola de Cloud y comprobar que la imagen de nginx almacenada en caché ahora proporciona los mismos informes de dependencias y vulnerabilidades que vimos para la imagen que compilaste.
Cómo crear un repositorio virtual
Si sigues los procesos que usamos hasta ahora, puedes crear una serie de repositorios para cada equipo o empresa y definir claramente la propiedad y los permisos de IAM para cada uno. También podemos crear proxies para repositorios remotos, lo que facilita y hace más seguro el consumo de imágenes de terceros. La desventaja de esta gran cantidad de repositorios es evidente si cambias tu perspectiva al consumidor de estas imágenes. ¿Cómo debe saber un desarrollador qué repositorio de imágenes debe usar en su implementación?
Para simplificar el consumo y ocultar los repositorios subyacentes detrás de una capa de abstracción, puedes crear un repositorio virtual en Artifact Registry con el siguiente comando en 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"
Ahora podemos extraer las imágenes del repositorio virtual sin exponer la estructura subyacente. Para verificar que todo funcione como se espera, puedes ejecutar los siguientes comandos en 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. Implementa en Cloud Run
Con los repositorios y las imágenes correspondientes, ahora podemos usarlos en una implementación. Para ilustrar un caso de uso de ejemplo y evitar implementar infraestructura adicional, implementaremos nuestro contenedor en Cloud Run. En su forma más simple, la implementación se puede lograr ejecutando el siguiente comando en 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
Una vez que finalice la implementación, se mostrará la URL generada automáticamente con la que puedes acceder a tu servicio.
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 abres esa URL en una pestaña nueva del navegador, deberías ver el mensaje “Hello World” correcto.
7. Fortalece la seguridad de la cadena de suministro
Ahora que tu imagen de contenedor llegó a una implementación activa, podría ser un buen momento para analizar cómo podemos fortalecer nuestra cadena de suministro de extremo a extremo. En la sección anterior, vimos cómo el análisis de contenedores de Artifact Registry proporciona estadísticas sobre las bibliotecas y las licencias que se usan en la imagen. Sin embargo, es posible que personas que actúan de mala fe introduzcan contenido dañino en tu imagen a lo largo de la cadena de suministro. En esta sección, exploraremos cómo podemos usar el framework de SLSA para introducir la certificación de los artefactos de compilación y aprovechar las firmas criptográficas de los artefactos para garantizar que solo se puedan implementar artefactos de confianza en nuestro entorno de ejecución de Cloud Run.
Certificación de SLSA con Cloud Build
El framework de SLSA proporciona diferentes niveles de evidencia para los artefactos de la cadena de suministro. La especificación y la implementación pueden parecer abrumadoras a primera vista, pero con Cloud Build, crear la certificación de SLSA es tan simple como agregar la creación de una especificación cloudbuild.yaml
con el requestedVerifyOption
establecido en VERIFIED
.
Para nuestra aplicación, podemos ejecutar el siguiente comando en Cloud Shell para crear un archivo cloudbuild.yaml
en la carpeta 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
Ahora, ejecutamos el siguiente comando en Cloud Shell para crear un nuevo trabajo de Cloud Build que compile una versión nueva de nuestra imagen de Hello World de Java.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
Una vez que se complete la compilación, podemos ir a la IU de Cloud Build en la consola de Google Cloud y ver el nivel de SLSA que logramos abriendo nuestra compilación y, luego, mirando los artefactos de compilación en Resumen de compilación. La imagen que se ve allí tiene un botón para ver las "Estadísticas de seguridad". Cuando hagas clic en él, verás la certificación de SLSA, así como los informes de vulnerabilidades conocidos que vimos antes en la IU de Artifact Registry cuando enviamos nuestra compilación local.
También puedes recuperar la procedencia de SLSA de nuestra imagen ejecutando el siguiente comando en Cloud Shell:
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
Exige la procedencia de Cloud Build con la autorización binaria
Con la canalización de Cloud Build implementada, ¿no sería genial asegurarnos de que todas las imágenes que implementemos en producción se hayan compilado con ese entorno de compilación programable y reproducible?
Aquí es donde entra en juego la Autorización Binaria. Te permite colocar un gatekeeper frente a los tiempos de ejecución de tu contenedor que inspecciona la imagen del contenedor y verifica la existencia de una certificación de confianza. Si no se encuentra ninguna certificación, se crean entradas de registro de auditoría o se bloquea la implementación por completo, según la configuración.
Para cambiar la configuración predeterminada de la Autorización Binaria de nuestro proyecto para que requiera la certificación integrada que emite Cloud Run, ejecutamos el siguiente comando en 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
Por supuesto, también puedes agregar tus propios verificadores personalizados, pero eso está fuera del alcance de este codelab y se deja como ejercicio opcional para el hogar.
Para aplicar la autorización binaria en nuestro servicio de Cloud Run, ejecutamos el siguiente comando en Cloud Shell:
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
Para probar que nuestra Autorización binaria se aplica correctamente, volvamos a implementar la imagen compilada de forma local.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
Como se esperaba, deberías recibir un mensaje de error que explique por qué no se pudo implementar la imagen, que se ve de la siguiente manera:
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
Por lo tanto, para implementar una versión nueva en nuestro servicio de Cloud Run, debemos proporcionar una imagen que se haya compilado 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
Esta vez, la implementación debería realizarse correctamente y mostrar un mensaje de implementación exitosa similar al siguiente:
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. Administra paquetes de lenguaje Java Maven
En esta sección, verás cómo configurar un repositorio de Java de Artifact Registry y subir paquetes a él para aprovecharlos en diferentes aplicaciones.
Crea un repositorio de paquetes de Maven
Desde Cloud Shell, ejecuta el siguiente comando para crear un repositorio para artefactos de Java:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Haz clic en Autorizar si aparece el mensaje de autorización de Cloud Shell.
Ve a la consola de Google Cloud - Artifact Registry - Repositories y observa el repositorio de Maven que acabas de crear llamado java-repo
. Si haces clic en él, verás que está vacío en este momento.
Configura la autenticación en el repositorio de artefactos
Usa el siguiente comando para actualizar la ubicación conocida de las credenciales predeterminadas de la aplicación (ADC) con las credenciales de tu cuenta de usuario, de modo que el auxiliar de credenciales de Artifact Registry pueda autenticarse con ellas cuando se conecte con repositorios:
gcloud auth login --update-adc
Configura Maven para Artifact Registry
Ejecuta el siguiente comando para imprimir la configuración del repositorio que deseas agregar a tu proyecto de Java:
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
Para abrir pom.xml en el Editor de Cloud Shell, ejecuta el siguiente comando en Cloud Shell desde el directorio helloworld:
cloudshell edit pom.xml
y agrega la configuración que se muestra a las secciones correspondientes del archivo.
Actualiza la sección 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>
Actualiza la sección repositorios
<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>
Actualiza la sección extensions en build.
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.1.0</version>
</extension>
</extensions>
Este es un ejemplo del archivo completo para tu referencia. Asegúrate de reemplazar <PROJECT> por el ID de tu proyecto.
<?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>
Sube tu paquete de Java a Artifact Registry
Con Artifact Registry configurado en Maven, ahora puedes usar Artifact Registry para almacenar archivos JAR de Java para que los usen otros proyectos de tu organización.
Ejecuta el siguiente comando para subir tu paquete de Java a Artifact Registry:
mvn deploy
Verifica el paquete de Java en Artifact Registry
Ve a consola de Cloud - Artifact Registry - Repositories Haz clic en java-repo
y verifica que el artefacto binario helloworld
esté allí:
9. ¡Felicitaciones!
¡Felicitaciones! Completaste el codelab.
Temas abordados
- Creación de repositorios para contenedores y paquetes de lenguaje
- Imágenes de contenedor administradas con Artifact Registry
- Integración de Artifact Registry con Cloud Code
- Se configuró Maven para usar Artifact Registry para dependencias de Java
Limpieza
Ejecuta el siguiente comando en Cloud Shell para borrar todo el proyecto
gcloud projects delete $PROJECT_ID