1. Descripción general
Artifact Registry es el administrador de paquetes completamente administrado para OCI y proporciona una herramienta unificada para administrar tus imágenes de contenedor 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 directamente artefactos de imágenes 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 tiempos de ejecución de contenedores, como Cloud Run y GKE, y habilita capacidades 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 continuamente las vulnerabilidades conocidas.
- Cloud IAM proporciona un control coherente y detallado sobre el acceso y los permisos de los artefactos.
En este lab, se te guiará por muchas de estas funciones en forma de un instructivo práctico.
Qué aprenderás
¿Cuáles son los objetivos de aprendizaje de este lab?
- Crea diferentes repositorios para contenedores y paquetes de lenguajes
- Crea y usa imágenes de contenedor con Artifact Registry
- Usa Artifact Registry para analizar la postura y el contenido de seguridad de tus artefactos
- Configura y usa Artifact Registry para dependencias de Java Maven
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 en GitHub. Clónalo con el siguiente comando.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. Envío de imágenes de contenedor
Crea un repositorio de Docker en Artifact Registry
Como se mencionó anteriormente, Artifact Registry admite diferentes formatos de repositorios que te permiten administrar imágenes de contenedores y paquetes de lenguajes. Las interacciones con los diferentes tipos de repositorios de artefactos se definen en especificaciones y son estándares ampliamente adoptados. Por ejemplo, las solicitudes de dependencias de Maven son diferentes de las de Node.
Para admitir especificaciones de APIs de artefactos específicas, Artifact Registry necesita administrar tus artefactos en los tipos de repositorios correspondientes. Cuando creas un repositorio nuevo, pasas la marca --repository-format para indicar el tipo de repositorio.
Para crear un primer repositorio de 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 la solicitud de autorización de Cloud Shell.
Ve a la consola de Google Cloud > Artifact Registry > Repositorios y observa tu repositorio de Docker recién creado con el nombre container-example. Si le haces clic, verás que está vacío por el 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 establecer credenciales separadas, Docker puede configurarse para usar tus credenciales de gcloud sin problemas.
Desde Cloud Shell, ejecuta el siguiente comando para configurar Docker de modo que use Google Cloud CLI para autenticar 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 sencilla: 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, debes crear una.
Ejecuta el siguiente comando para compilar la imagen del contenedor y etiquetarla con la ruta de acceso completa de Artifact Registry:
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 del contenedor al repositorio que creaste anteriormente:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
Revisa la imagen en Artifact Registry
Ve a Google Cloud Console > Artifact Registry > Repositorios. Abre el repositorio container-example y verifica que la imagen java-hello-world esté allí.
Haz clic en la imagen y ten en cuenta la presencia de 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 en esta revisión de la imagen. En la siguiente sección, exploraremos las vulnerabilidades y otras estadísticas de artefactos.
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 de 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 copiar superior es especialmente útil, ya que proporciona una forma sencilla de acceder al URI de imagen completamente calificado para esa versión de la imagen, incluido el hash SHA. Luego, 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 te desplazas a la pestaña "Dependencies" 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 SO y del lenguaje. También puedes ver las licencias de software adjuntas a cada una de las dependencias.
Si observas con atención, verás que la información de la SBOM aún no se propagó. Para completar el SOM de tu artefacto, puedes ejecutar el siguiente comando en Cloud Shell con el URI de imagen completamente calificado que podemos copiar desde la barra de rutas de navegación en la parte superior.
gcloud artifacts sbom export --uri $IMAGE_URI
Una vez que actualices la página, contendrá un vínculo a la SBOM generada automáticamente y almacenada en Cloud Storage. Si dependes de las SBOM para tus imágenes, es posible que desees generar automáticamente SBOM para tus artefactos y hacer que la generación forme parte de tu canalización de CI/CD.
Explora las vulnerabilidades de las 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 que se encuentra en la parte inferior. Cada fila vincula al boletín de la CVE, lo que indica su gravedad y el paquete del que se originó. En el caso de las vulnerabilidades para las que hay una corrección disponible, también se proporcionan instrucciones para actualizar las dependencias y corregir la vulnerabilidad.
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, especialmente 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 negocios 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 que aloja muchas imágenes de contenedores de código abierto. Si bien usar el repositorio público directamente es sencillo, presenta varios desafíos en un entorno de producción que podemos superar con los repositorios remotos en Artifact Registry.
Los repositorios remotos te permiten redireccionar las solicitudes al registro upstream y almacenar en caché las imágenes en el proceso. Esto no solo reduce los tiempos de descarga de las imágenes, sino que también elimina 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 tu lista de repositorios de Artifact Registry:
Para probar si tu repositorio remoto puede redireccionar 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 la extracción se realice correctamente, también podrás ver el repositorio en Cloud Console y comprobar que la imagen de nginx almacenada en caché ahora proporciona los mismos informes de vulnerabilidades y dependencias que habíamos visto para la imagen que compilaste tú mismo.
Crea un repositorio virtual
Si sigues los procesos que usamos hasta ahora, puedes crear varios 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 se hace evidente si cambias tu perspectiva a la del consumidor de estas imágenes. ¿Cómo puede un desarrollador saber 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 según lo esperado, 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 respectivos en su lugar, 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 exitoso “Hello World”.
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 integral. 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, los agentes maliciosos aún pueden introducir contenido dañino en tu imagen a lo largo de la cadena de suministro. En esta sección, exploraremos cómo podemos usar el marco de SLSA para introducir la certificación de los artefactos de compilación y, también, 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 desalentadoras a primera vista, pero con Cloud Build, crear una certificación de SLSA es tan simple como agregar una especificación cloudbuild.yaml con el parámetro 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 crearemos un nuevo trabajo de Cloud Build que compile una nueva versión de nuestra imagen de Hello World de Java. Para ello, ejecuta el siguiente comando en Cloud Shell.
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 dirigirnos a la IU de Cloud Build en la consola de Google Cloud y ver el nivel de SLSA que alcanzamos. Para ello, abrimos nuestra compilación y, luego, observamos los artefactos de compilación en el resumen de la compilación. La imagen que se ve allí tiene un botón para ver las "Estadísticas de seguridad". Cuando haces clic en él, ves 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.
La procedencia de SLSA de nuestra imagen también se puede recuperar 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 implementamos 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 confiable. 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 Autorización Binaria de nuestro proyecto de modo 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
Obviamente, aquí también podrías agregar tus propios certificadores personalizados, pero eso está fuera del alcance de este codelab y se deja como un ejercicio extracurricular opcional.
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
Primero, volvamos a implementar la imagen compilada de forma local para probar que la Autorización binaria se aplicó correctamente.
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, similar al siguiente:
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 éxito 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 de 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 de 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 la solicitud de autorización de Cloud Shell.
Ve a la consola de Google Cloud: Artifact Registry > Repositorios y observa el repositorio de Maven recién creado con el nombre java-repo. Si le haces clic, verás que está vacío por el momento.
Configura la autenticación en Artifact Repository
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 al conectarse a los 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
Abre pom.xml en el Editor de Cloud Shell ejecutando 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 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>
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 como 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 y usarlos en 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 > Repositorios. Haz clic en java-repo y verifica que el artefacto binario helloworld esté allí:
9. ¡Felicitaciones!
¡Felicitaciones! Completaste el codelab.
Temas abordados
- Repositorios creados para contenedores y paquetes de lenguajes
- Imágenes de contenedor administradas con Artifact Registry
- Integraste Artifact Registry con Cloud Code
- Configuraste Maven para usar Artifact Registry como repositorio de dependencias Java.
Limpieza
Ejecuta el siguiente comando en Cloud Shell para borrar todo el proyecto:
gcloud projects delete $PROJECT_ID