1. Visão geral
O Artifact Registry é o gerenciador de pacotes totalmente gerenciado e oferece uma ferramenta unificada para gerenciar suas imagens de contêiner OCI e pacotes de linguagem, como Maven e npm.
O Artifact Registry é totalmente integrado a uma ampla gama de outros serviços do Google Cloud, como nos exemplos abaixo:
- O Cloud Build pode fazer upload de artefatos de imagem diretamente no Artifact Registry.
- O Cloud Deploy pode implantar as imagens do Artifact Registry diretamente em vários ambientes de execução.
- Ele fornece imagens para ambientes de execução de contêineres, como o Cloud Run e o GKE, e ativa recursos avançados de otimização de desempenho, como o streaming de imagens.
- O Artifact Registry pode servir como um ponto de detecção para que o Artifact Analysis monitore continuamente as vulnerabilidades conhecidas.
- O Cloud IAM oferece controle consistente e granular sobre o acesso e as permissões de artefatos.
Este laboratório vai abordar muitos desses recursos na forma de um tutorial prático.
O que você vai aprender
Quais são os objetivos de aprendizado deste laboratório?
- Criar repositórios diferentes para contêineres e pacotes de idiomas
- Criar e usar imagens de contêiner com o Artifact Registry
- Usar o Artifact Registry para analisar a postura de segurança e o conteúdo dos seus artefatos
- Configurar e usar o Artifact Registry para dependências do Maven em Java
2. Configuração e requisitos
Configuração de ambiente personalizada
- Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.
- O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
- O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como
PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto. - Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
- Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.
Configurar a gcloud
No Cloud Shell, defina o ID e o número do projeto. Salve-as como variáveis PROJECT_ID e PROJECT_NUMBER.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
Ativar os Serviços do 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
Conseguir o código-fonte
O código-fonte deste laboratório está localizado na organização GoogleCloudPlatform no GitHub. Clone-o com o comando abaixo.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. Como enviar imagens de contêiner
Criar um repositório do Docker no Artifact Registry
Como mencionado anteriormente, o Artifact Registry oferece suporte a diferentes formatos de repositório que permitem gerenciar imagens de contêiner e pacotes de linguagem. As interações com os diferentes tipos de repositórios de artefatos são definidas em especificações e são padrões amplamente adotados. Por exemplo, as solicitações de dependências do Maven são diferentes das solicitações de dependências do Node.
Para oferecer suporte a especificações específicas da API de artefatos, o Artifact Registry precisa gerenciar seus artefatos nos tipos de repositório correspondentes. Ao criar um novo repositório, você transmite a flag --repository-format para indicar o tipo de repositório.
Para criar um primeiro repositório para imagens do Docker, execute o seguinte comando no Cloud Shell:
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
Clique em "Autorizar" se o prompt de autorização do Cloud Shell aparecer.
Acesse o console do Google Cloud - Artifact Registry - Repositories e observe o repositório do Docker recém-criado com o nome container-example. Se você clicar nele, vai notar que ele está vazio no momento.
Configurar a autenticação do Docker para o Artifact Registry
Ao se conectar ao Artifact Registry, as credenciais são necessárias para fornecer acesso. Em vez de configurar credenciais separadas, o Docker pode ser configurado para usar suas credenciais do gcloud sem problemas.
No Cloud Shell, execute o comando abaixo para configurar o Docker para usar a CLI do Google Cloud e autenticar solicitações ao Artifact Registry na região us-central1:
gcloud auth configure-docker us-central1-docker.pkg.dev
Se o comando solicitar uma confirmação para alterar a configuração do docker do Cloud Shell, pressione Enter.
Conheça o aplicativo de exemplo
Um aplicativo de exemplo é fornecido no repositório do Git que você clonou em uma etapa anterior. Mude para o diretório Java e revise o código do aplicativo.
cd java-docs-samples/run/helloworld/
ls
A pasta contém um exemplo de aplicativo Java que renderiza uma página da Web simples: além de vários arquivos não relevantes para este laboratório específico, ela contém o código-fonte, na pasta src, e um Dockerfile que usaremos para criar uma imagem de contêiner.
Criar a imagem do contêiner
Antes de armazenar imagens de contêiner no Artifact Registry, você precisa criar uma.
Execute o comando abaixo para criar a imagem do contêiner e marcá-la com o caminho completo do registro de artefatos:
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
Envie a imagem do contêiner para o Artifact Registry
Execute o comando a seguir para enviar a imagem do contêiner ao repositório criado anteriormente:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
Analisar a imagem no Artifact Registry
Acesse o console do Google Cloud - Artifact Registry - Repositórios. Abra o repositório container-example e verifique se a imagem java-hello-world está lá.
Clique na imagem e observe a imagem marcada como tag1. Como ativamos a verificação automática de imagens pelo serviço containerscanning.googleapis.com, a verificação de vulnerabilidades está em execução ou já foi concluída. Quando a verificação for concluída, você poderá conferir o número de vulnerabilidades detectadas na revisão da imagem. Vamos analisar vulnerabilidades e outros insights de artefato na próxima seção.
4. Inspecionar imagens de contêiner
Agora que você enviou sua primeira imagem para o repositório container-example, podemos analisar com mais detalhes. Na guia "Versões", clique na versão que acabamos de criar. Para mostrar a imagem com mais detalhes:
O botão de cópia superior é especialmente útil, porque oferece uma maneira fácil de acessar o URI da imagem totalmente qualificado para essa versão, incluindo o hash SHA. Esse URI pode ser usado para extrair uma versão específica da imagem ou como uma referência de imagem em uma implantação do Kubernetes ou em um serviço do Cloud Run. Para testar o URI da imagem, execute o seguinte comando no Cloud Shell:
docker pull $IMAGE_URI
Noções básicas sobre dependências
Na guia "Dependências", na parte de cima, você pode conferir todas as dependências detectadas na imagem. Ele lista as dependências no nível da linguagem e do SO. Também é possível conferir as licenças de software anexadas a cada uma das dependências.
Se você olhar com atenção, vai notar que as informações do SBOM ainda não foram preenchidas. Para preencher o SOM do artefato, execute o comando a seguir no Cloud Shell usando o URI da imagem totalmente qualificado que pode ser copiado na barra de breadcrumbs na parte de cima.
gcloud artifacts sbom export --uri $IMAGE_URI
Depois de atualizar a página, ela vai conter um link para o SBOM gerado automaticamente e armazenado no Cloud Storage. Se você usa SBOMs para suas imagens, é recomendável gerar automaticamente SBOMs para seus artefatos e fazer parte da geração do pipeline de CI/CD.
Como analisar vulnerabilidades de imagem
Ao clicar na guia "Vulnerabilidades" na parte de cima da visualização, você pode conferir todas as vulnerabilidades detectadas na imagem. Além do resumo das vulnerabilidades na parte de cima, você pode conferir a lista completa delas na tabela na parte de baixo. Cada linha faz referência ao boletim CVE, indicando a gravidade e o pacote de origem. Para vulnerabilidades em que uma correção está disponível, também são fornecidas instruções sobre como atualizar as dependências para corrigir a vulnerabilidade.
5. Repositórios virtuais e remotos
Na seção anterior, usamos um único repositório de imagens para enviar e receber nossas imagens. Isso funciona muito bem para casos de uso de pequena escala, mas apresenta desafios, especialmente para organizações maiores com diferentes equipes que precisam de autonomia sobre os repositórios. É comum que equipes ou unidades de negócios tenham repositórios de imagens com permissões e configurações próprias. Para simplificar o uso das imagens nesses repositórios e proteger o consumidor da estrutura organizacional, o Artifact Registry oferece repositórios virtuais que podem agregar recursos de vários repositórios. Uma possível arquitetura pode ser assim:
Repositório remoto para o Docker Hub
O Docker Hub é um registro de imagens públicas muito usado e hospeda muitas imagens de contêineres de código aberto. Embora o uso direto do repositório público seja simples, ele apresenta vários desafios em um ambiente de produção que podem ser superados com os repositórios remotos no Artifact Registry.
Os repositórios remotos permitem que você faça proxy das solicitações para o registro upstream e armazene imagens em cache ao longo do caminho. Isso não apenas reduz o tempo de download das imagens, mas também elimina a dependência do tempo de atividade do serviço externo e permite que você aplique as mesmas políticas de segurança e acesso às suas imagens.
Para criar um repositório remoto para o Docker Hub, execute o seguinte comando no 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"
Agora você vai encontrar um repositório adicional na lista de repositórios do Artifact Registry:
Para testar se o repositório remoto pode fazer solicitações de proxy para o repositório remoto, execute o seguinte comando no Cloud Shell para extrair a imagem nginx:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
Depois que o pull for concluído, você também poderá conferir o repositório no console do Cloud e verificar se a imagem do Nginx em cache agora fornece os mesmos relatórios de dependência e vulnerabilidade que vimos para a imagem que você criou.
Como criar um repositório virtual
Ao seguir os processos que usamos até agora, você pode criar vários repositórios para cada equipe ou empresa e definir claramente a propriedade e as permissões do IAM para cada um deles. Também podemos criar proxies para repositórios remotos, facilitando e tornando mais seguro o consumo de imagens de terceiros. A desvantagem desse grande número de repositórios fica aparente se você mudar sua perspectiva para o consumidor dessas imagens. Como um desenvolvedor pode saber qual repositório de imagens usar na implantação?
Para simplificar o consumo e ocultar os repositórios subjacentes atrás de uma camada de abstração, crie um repositório virtual no Artifact Registry com o seguinte comando no 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"
Agora podemos extrair as imagens do repositório virtual sem expor a estrutura subjacente. Para verificar se tudo está funcionando como esperado, execute os seguintes comandos no 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. Implantar no Cloud Run
Com os respectivos repositórios e imagens em vigor, agora podemos usá-los em uma implantação. Para ilustrar um exemplo de caso de uso e evitar a implantação de infraestrutura adicional, vamos implantar nosso contêiner no Cloud Run. Na forma mais simples, a implantação pode ser feita executando o seguinte comando no 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
Quando a implantação for concluída, o URL gerado automaticamente vai aparecer para você acessar o serviço.
Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1] OK Deploying... Done. OK Creating Revision... OK Routing traffic... OK Setting IAM Policy... Done. Service [hello-world] revision [hello-world-00001-wtc] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-world-13746229022.us-central1.run.app
Se você abrir esse URL em uma nova guia do navegador, a mensagem "Hello World" vai aparecer.
7. Fortalecer a segurança da cadeia de suprimentos
Agora que sua imagem de contêiner foi implantada, é uma boa hora para analisar como podemos fortalecer nossa cadeia de suprimentos de ponta a ponta. Na seção anterior, analisamos como a análise de contêineres do Artifact Registry fornece insights sobre as bibliotecas e licenças usadas na imagem. No entanto, ainda é possível que usuários de má-fé introduzam conteúdo prejudicial na sua imagem ao longo da cadeia de suprimentos. Nesta seção, vamos explorar como usar o framework SLSA para introduzir atestados para os artefatos de build e até mesmo aproveitar as assinaturas criptográficas dos próprios artefatos para garantir que apenas artefatos confiáveis possam ser implantados no ambiente de execução do Cloud Run.
Atestado de SLSA com o Cloud Build
O framework SLSA oferece diferentes níveis de evidência para artefatos da cadeia de suprimentos. A especificação e a implementação podem parecer assustadoras à primeira vista, mas com o Cloud Build, criar um atestado de SLSA é tão simples quanto adicionar uma especificação cloudbuild.yaml com o requestedVerifyOption definido como VERIFIED.
Para nosso aplicativo, podemos executar o seguinte comando no Cloud Shell para criar um arquivo cloudbuild.yaml na pasta 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
Agora vamos criar um novo job do Cloud Build que vai criar uma nova versão da nossa imagem Java Hello World executando o comando abaixo no Cloud Shell.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
Depois que o build for concluído, acesse a interface do Cloud Build no console do Google Cloud e confira o nível de SLSA que alcançamos abrindo o build e, em seguida, analisando os artefatos do build em "Resumo do build". A imagem mostrada tem um botão para acessar os "Insights de segurança". Ao clicar nele, você verá o atestado SLSA e os relatórios de vulnerabilidade conhecidos que vimos antes na interface do Artifact Registry quando enviamos nosso build local.
A procedência da SLSA da nossa imagem também pode ser recuperada executando o seguinte comando no Cloud Shell:
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
Exigir a origem do Cloud Build com a autorização binária
Com o pipeline do Cloud Build em funcionamento, não seria ótimo garantir que todas as imagens implantadas na produção foram criadas usando esse ambiente de build programável e reproduzível?
É aí que entra a autorização binária. Ele permite que você coloque um gatekeeper na frente dos ambientes de execução de contêineres que inspeciona a imagem do contêiner e verifica a existência de um atestado confiável. Se nenhuma atestação for encontrada, ele vai criar entradas de registro de auditoria ou bloquear a implantação completamente, dependendo da configuração.
Para mudar a configuração padrão de autorização binária do projeto e exigir o atestado integrado emitido pelo Cloud Run, execute o seguinte comando no 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
Aqui, você também pode adicionar seus próprios Attestors personalizados, mas isso está fora do escopo deste codelab e é deixado como um exercício opcional de dever de casa extracurricular.
Para aplicar a autorização binária no serviço do Cloud Run, execute o seguinte comando no Cloud Shell:
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
Vamos testar se a Autorização binária foi aplicada corretamente reimplantando a imagem criada localmente
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
Como esperado, você vai receber uma mensagem de erro que explica por que a imagem não pôde ser implantada, como esta:
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
Para implantar uma nova versão no serviço do Cloud Run, precisamos fornecer uma imagem criada com o 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
Desta vez, a implantação vai ser bem-sucedida e vai mostrar uma mensagem de sucesso semelhante a esta:
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. Como gerenciar pacotes de linguagem Java Maven
Nesta seção, você vai aprender a configurar um repositório Java do Artifact Registry e fazer upload de pacotes para ele, aproveitando-os em diferentes aplicativos.
Criar um repositório de pacotes Maven
No Cloud Shell, execute o seguinte comando para criar um repositório de artefatos Java:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Clique em "Autorizar" se o prompt de autorização do Cloud Shell aparecer.
Acesse o console do Google Cloud - Artifact Registry - Repositories e observe o repositório Maven recém-criado com o nome java-repo. Se você clicar nele, vai notar que ele está vazio no momento.
Configurar a autenticação no repositório de artefatos
Use o comando a seguir para atualizar o local conhecido para as credenciais padrão do aplicativo (ADC) com as credenciais da sua conta de usuário para que o auxiliar de credenciais do Artifact Registry possa fazer a autenticação usando-as ao se conectar com os repositórios:
gcloud auth login --update-adc
Configurar o Maven para o Artifact Registry
Execute o comando a seguir para imprimir a configuração do repositório a ser adicionada ao projeto Java:
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
Abra o pom.xml no Editor do Cloud Shell executando o seguinte comando no Cloud Shell no diretório helloworld:
cloudshell edit pom.xml
e adicione as configurações retornadas às seções apropriadas no arquivo.
Atualize a seção 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>
Atualize a seção 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>
Atualize a seção extensions em build.
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.1.0</version>
</extension>
</extensions>
Confira um exemplo do arquivo completo para sua referência. Substitua <PROJECT> pelo ID do seu projeto.
<?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>
Fazer upload do pacote Java para o Artifact Registry
Com o Artifact Registry configurado no Maven, agora é possível usar o Artifact Registry para armazenar Java Jars para uso em outros projetos da sua organização.
Execute o comando a seguir para fazer upload do pacote Java para o Artifact Registry:
mvn deploy
Verificar o pacote Java no Artifact Registry
Acesse Console do Cloud - Artifact Registry - Repositórios. Clique em java-repo e verifique se o artefato binário helloworld está presente:
9. Parabéns!
Parabéns, você concluiu o codelab.
Conteúdo abordado
- Criação de repositórios para contêineres e pacotes de linguagem
- Imagens de contêiner gerenciadas com o Artifact Registry
- Artifact Registry integrado ao Cloud Code
- Configurou o Maven para usar o Artifact Registry para dependências Java
Limpeza
Execute o comando a seguir no Cloud Shell para excluir todo o projeto
gcloud projects delete $PROJECT_ID