1. Visão geral
O Artifact Registry é o gerenciador de pacotes totalmente gerenciado para e fornece 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 vários outros serviços do Google Cloud, como nos exemplos a seguir:
- O Cloud Build pode fazer upload direto de artefatos de imagem para o Artifact Registry.
- O Cloud Deploy pode implantar as imagens do Artifact Registry diretamente em vários ambientes de execução.
- Ele fornece imagens para os ambientes de execução de contêineres, como o Cloud Run e o GKE, e permite 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 o Artifact Analysis monitorar continuamente vulnerabilidades conhecidas.
- O Cloud IAM oferece controle consistente e granular sobre o acesso e as permissões de artefatos.
Neste laboratório, você vai conhecer muitos desses recursos em 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 linguagem
- Criar e usar imagens de contêiner com o Artifact Registry
- Usar o Artifact Registry para analisar a postura e o conteúdo de segurança dos seus artefatos
- Configurar e usar o Artifact Registry para dependências do Java Maven
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á na organização GoogleCloudPlatform no GitHub. Clone 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 antes, 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 de API de artefato específicas, o Artifact Registry precisa gerenciar seus artefatos nos tipos de repositório correspondentes. Ao criar um repositório, transmita a flag --repository-format para indicar o tipo de repositório.
Para criar um primeiro repositório de 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 > Repositórios e observe o repositório Docker recém-criado chamado container-example. Se você clicar nele, verá que está vazio no momento.
Configurar a autenticação do Docker no 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 de maneira integrada.
No Cloud Shell, execute o comando a seguir 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 pedir uma confirmação para mudar a configuração do Docker do Cloud Shell, pressione "Enter".
Conheça o aplicativo de amostra
Um aplicativo de amostra é fornecido no repositório 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 que não são relevantes para este laboratório específico, ela contém o código-fonte, na pasta src, e um Dockerfile que vamos usar para criar uma imagem de contêiner.
Crie a imagem de contêiner
Antes de armazenar imagens de contêiner no Artifact Registry, você precisa criar um.
Execute o comando a seguir para criar a imagem do contêiner e marcá-la com o caminho completo do Artifact Registry:
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 para o 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 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 tag tag1. Como ativamos a verificação automática de imagens pelo serviço containerscanning.googleapis.com, você pode ver que a verificação de vulnerabilidades está em execução ou já foi concluída. Quando terminar, você poderá ver o número de vulnerabilidades detectadas para essa revisão de imagem. Vamos falar sobre vulnerabilidades e outros insights de artefatos na próxima seção.
4. Como 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 na parte de cima é especialmente útil porque oferece uma maneira fácil de acessar o URI totalmente qualificado da versão de imagem, incluindo o hash SHA. Esse URI pode ser usado para extrair uma versão de imagem específica ou como uma referência de imagem em uma implantação do Kubernetes ou 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 do SO e da linguagem. Também é possível conferir as licenças de software anexadas a cada uma das dependências.
Se você olhar com atenção, vai perceber que as informações da lista de materiais de software ainda não foram preenchidas. Para preencher a SOM do seu artefato, execute o seguinte comando no Cloud Shell usando o URI de imagem totalmente qualificado que pode ser copiado da barra de navegação na parte de cima.
gcloud artifacts sbom export --uri $IMAGE_URI
Depois de atualizar a página, ela vai conter um link para a lista de materiais de software (SBOM, na sigla em inglês) gerada automaticamente e armazenada no Cloud Storage. Se você usa SBOMs para suas imagens, talvez queira gerar automaticamente SBOMs para seus artefatos e tornar a geração parte do seu pipeline de CI/CD.
Como explorar vulnerabilidades de imagem
Ao clicar na guia "Vulnerabilidades" na parte de cima da visualização, você pode conferir todas as vulnerabilidades detectadas na sua imagem. Além do resumo das vulnerabilidades na parte de cima, você pode conferir a lista completa na tabela na parte de baixo. Cada linha tem um link para o boletim da CVE, indicando a gravidade e o pacote de origem. Para vulnerabilidades em que uma correção está disponível, ele também dá 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 extrair nossas imagens. Isso funciona muito bem para casos de uso em pequena escala, mas apresenta desafios, especialmente para organizações maiores com equipes diferentes que exigem autonomia sobre os repositórios. É comum que equipes ou unidades de negócios tenham um repositório de imagens próprio com permissões e configurações específicas. Para simplificar o uso das imagens nesses repositórios e proteger o consumidor da estrutura organizacional subjacente, o Artifact Registry oferece repositórios virtuais que podem agregar recursos de vários repositórios subjacentes. Uma possível arquitetura pode ter esta aparência:
Repositório remoto para o Docker Hub
O Docker Hub é um registro de imagens públicas muito usado e hospeda muitas imagens de contêiner de código aberto. Embora seja simples usar o repositório público diretamente, ele apresenta vários desafios em um ambiente de produção que podem ser superados com repositórios remotos no Artifact Registry.
Com os repositórios remotos, é possível fazer proxy das solicitações para o registro upstream e armazenar imagens em cache ao longo do caminho. Isso não apenas reduz os tempos de download das imagens, mas também remove a dependência do tempo de atividade do serviço externo e permite aplicar as mesmas políticas de segurança e acesso que você aplica às suas próprias 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 ver um repositório adicional na lista de repositórios do Artifact Registry:
Para testar se o repositório remoto consegue encaminhar solicitações 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á consultar o repositório no console do Cloud. A imagem nginx armazenada em cache agora fornece o mesmo relatório de dependência e vulnerabilidade que vimos para a imagem criada por você.
Como criar um repositório virtual
Seguindo 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 evidente se você mudar sua perspectiva para o consumidor dessas imagens. Como um desenvolvedor sabe qual repositório de imagens usar na implantação?
Para simplificar o consumo e ocultar os repositórios subjacentes em 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 funciona 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 no lugar, podemos usá-los em uma implantação. Para ilustrar um caso de uso de exemplo 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 terminar, o URL gerado automaticamente em que você pode acessar o serviço será exibido.
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, vai ver a mensagem "Hello World".
7. Fortalecer a segurança da cadeia de suprimentos
Agora que a imagem do contêiner chegou a uma implantação ativa, talvez seja uma boa hora para analisar como podemos fortalecer nossa cadeia de suprimentos de ponta a ponta. Na seção anterior, vimos como a análise de contêiner do Artifact Registry fornece insights sobre as bibliotecas e licenças usadas na imagem. No entanto, ainda é possível que usuários mal-intencionados introduzam conteúdo nocivo na sua imagem ao longo da cadeia de suprimentos. Nesta seção, vamos saber como usar o framework SLSA para introduzir o atestado dos 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 da 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 difíceis à primeira vista, mas com o Cloud Build, criar uma declaração do 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 job do Cloud Build que cria uma nova versão da nossa imagem Java Hello World executando o seguinte comando 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 da SLSA alcançado. Para isso, abra o build e consulte os artefatos em "Resumo do build". A imagem tem um botão para acessar os "Insights de segurança". Ao clicar nele, você vê a atestação do SLSA e os relatórios de vulnerabilidade conhecidos que vimos antes na interface do Artifact Registry ao enviar nosso build local.
A origem do 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 vigor, 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 colocar um gatekeeper na frente dos ambientes de execução de contêiner que inspecionam a imagem do contêiner e verificam a existência de uma atestação confiável. Se nenhuma comprovação for encontrada, o sistema vai criar entradas de registro de auditoria ou bloquear a implantação por completo, dependendo da configuração.
Para mudar a configuração padrão da autorização binária do nosso 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 atestadores personalizados, mas isso está fora do escopo deste codelab e fica como um exercício extracurricular opcional.
Para aplicar a autorização binária no nosso 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 está sendo aplicada corretamente reimplantando primeiro 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 explicando por que a imagem não pôde ser implantada, parecida com 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, é preciso 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 mostrar uma mensagem 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 nele, usando-os em diferentes aplicativos.
Criar um repositório de pacotes Maven
No Cloud Shell, execute o seguinte comando para criar um repositório para 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 > Repositórios e observe o repositório Maven recém-criado chamado java-repo. Se você clicar nele, verá que está vazio no momento.
Configurar a autenticação no Artifact Repository
Use o comando a seguir para atualizar o local conhecido do Application Default Credentials (ADC) com suas credenciais de conta de usuário para que o auxiliar de credenciais do Artifact Registry possa fazer a autenticação usando essas credenciais ao se conectar com repositórios:
gcloud auth login --update-adc
Configurar o Maven para o Artifact Registry
Execute o comando a seguir para mostrar a configuração do repositório para adicioná-la ao seu projeto Java.
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
Abra o arquivo 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>
Aqui está um exemplo do arquivo completo para referência. Substitua <PROJECT> pelo ID do 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 você pode usar o Artifact Registry para armazenar Jars Java para que outros projetos na sua organização os usem.
Execute o comando a seguir para fazer upload do pacote Java no 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á lá:
9. Parabéns!
Parabéns, você concluiu o codelab.
Conteúdo abordado
- Criou repositórios para contêineres e pacotes de linguagem
- Imagens de contêiner gerenciadas com o Artifact Registry
- Integração do Artifact Registry com o Cloud Code
- Configurou o Maven para usar o Artifact Registry para dependências Java
Limpeza
Execute o seguinte comando no Cloud Shell para excluir todo o projeto:
gcloud projects delete $PROJECT_ID