Esta página foi traduzida pela API Cloud Translation.

Alterações para a criação e a implementação no Google Cloud

Este documento explica as diferenças entre o Container Registry e o Artifact Registry quando cria imagens de contentores com o Cloud Build e as implementa em Google Cloud ambientes de tempo de execução, como o Cloud Run ou o Google Kubernetes Engine.

Neste guia, as comparações focam-se nos repositórios do Artifact Registry padrão, que são repositórios normais do Artifact Registry independentes do Container Registry e que suportam todas as funcionalidades do Artifact Registry. Se o seu administrador tiver configurado repositórios com suporte do domínio gcr.io, os pedidos aos nomes de anfitrião gcr.io são automaticamente redirecionados para um repositório do Artifact Registry correspondente, e as contas de serviço predefinidas que têm acesso ao Container Registry têm permissões predefinidas equivalentes para o Artifact Registry.

Para saber mais sobre as diferenças entre o Container Registry e o Artifact Registry através de um cliente Docker, consulte o artigo Alterações ao envio e à obtenção com o Docker.

Use estas informações para ajudar a adaptar os comandos, a configuração ou a documentação existentes focados no Container Registry com o Cloud Build.

Antes de começar

Este documento pressupõe que:

Ativou o Artifact Registry no seu projeto.
Ativou a API Cloud Build e a API para qualquer outro serviço que esteja a usar com o Artifact Registry. Google Cloud

Alterações ao fluxo de trabalho

Quando usa o Cloud Build com o Container Registry no mesmo projeto, o fluxo de trabalho tem o seguinte aspeto:

Crie, etiquete e envie uma imagem para o repositório com o Cloud Build, usando um Dockerfile ou um ficheiro de configuração de compilação.

O exemplo seguinte cria a imagem my-image, etiqueta-a com tag1 e envia-a para o anfitrião gcr.io no projeto my-project:
```
gcloud builds submit --tag gcr.io/my-project/my-image:tag1
```
Google Cloud ambientes de tempo de execução, como o Cloud Run e o Google Kubernetes Engine, extraem imagens do registo.

Por exemplo, este comando implementa a imagem do passo anterior no Cloud Run como my-service.
```
gcloud run deploy my-service --image gcr.io/my-project/my-image:tag1
```

O fluxo de trabalho do Container Registry combina as responsabilidades do administrador com a criação e a implementação.

Quando ativa algumas Google Cloud APIs, a API Container Registry é ativada automaticamente. Isto significa que os utilizadores destes serviços têm acesso implícito ao Container Registry no mesmo projeto. Por exemplo, os utilizadores que podem executar compilações no Cloud Build podem enviar imagens para registos e adicionar anfitriões de registos por predefinição.
A conta de serviço do Cloud Build tem autorizações para criar contentores de armazenamento do Cloud Storage. Isto significa que a conta pode adicionar automaticamente anfitriões do Container Registry a um projeto na primeira vez que envia uma imagem para o anfitrião. Também significa que a conta pode criar, ler e escrever em contentores de armazenamento em todo o projeto, incluindo contentores que não são usados pelo Container Registry.

No Artifact Registry, existe uma separação clara das funções de administrador e de compilação que altera os passos no fluxo de trabalho de compilação e implementação. Para adaptar o fluxo de trabalho do Container Registry para o Artifact Registry, faça as seguintes alterações. Cada passo inclui um link para informações adicionais sobre a modificação do fluxo de trabalho.

Novo: ative a API Artifact Registry.

Tem de ativar a API Artifact Registry. O Cloud Build e os ambientes de tempo de execução, como o Cloud Run e o GKE, não ativam automaticamente a API por si.
Novo: crie o repositório Docker de destino, se ainda não existir. Tem de criar um repositório antes de poder enviar imagens para o mesmo. O envio de uma imagem não pode acionar a criação de um repositório e a conta de serviço do Cloud Build não tem autorizações para criar repositórios.
Alterado: compile, etiquete e envie uma imagem para o repositório com o Cloud Build, usando um Dockerfile ou um ficheiro de configuração de compilação.

O comando de exemplo seguinte é igual ao exemplo do Container Registry, mas usa um caminho do repositório do Artifact Registry para a imagem.
```
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
```
Alterado: implemente a imagem num ambiente de Google Cloud tempo de execução como o Cloud Run ou o GKE.

O comando de exemplo seguinte é igual ao exemplo do Container Registry, mas usa o caminho do repositório do Artifact Registry para a imagem.
```
gcloud run deploy my-service --image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
```

Além disso, o Artifact Registry usa funções diferentes do Container Registry para controlar o acesso às imagens. Tem de configurar as autorizações nas seguintes situações:

O Cloud Build ou os Google Cloud ambientes de tempo de execução estão num projeto diferente do Artifact Registry.
Usa contas de serviço personalizadas para Google Cloud serviços como o Cloud Build ou o GKE em vez das contas de serviço predefinidas.
Concedeu autorizações a outras contas de utilizador ou de serviço.

Ativar a API

Pontos-chave:

Tem de ativar a API Artifact Registry além da API para outros Google Cloud serviços, como o Cloud Build, o Cloud Run e o GKE.

A comparação seguinte descreve a ativação da API para cada serviço:

Container Registry

Quando ativa as seguintes Google Cloud APIs, a API Container Registry também é ativada automaticamente:

Ambiente flexível do App Engine
Cloud Build
Funções do Cloud Run
Cloud Run
Análise de contentores ou análise a pedido na análise de artefactos
Google Kubernetes Engine

Com as autorizações predefinidas, os utilizadores que podem executar compilações no Cloud Build, analisar contentores com a análise de artefactos ou implementar contentores emGoogle Cloud tempos de execução têm implicitamente acesso a imagens no Container Registry quando o registo está no mesmo projeto.

Artifact Registry

Tem de ativar a API Artifact Registry. Serviços como o Cloud Build, o Cloud Run e o GKE não ativam automaticamente a API Artifact Registry.

Pode ativar várias APIs no mesmo projeto através do gcloud. Por exemplo, para ativar a API Cloud Build e a API Artifact Registry, execute o comando:

gcloud services enable
    artifactregistry.googleapis.com \
    cloudbuild.googleapis.com

Adicionar registos e repositórios

Pontos-chave:

Tem de criar um repositório Docker do Artifact Registry antes de enviar uma imagem para o mesmo.
O Container Registry armazena todas as imagens numa única região múltipla no mesmo contentor de armazenamento. No Artifact Registry, pode criar vários repositórios na mesma região ou multirregião com políticas de acesso separadas.

A comparação seguinte descreve a configuração do repositório em cada serviço:

Container Registry

No Container Registry, pode adicionar até quatro anfitriões de registo ao seu projeto. Adiciona um anfitrião do registo enviando a primeira imagem.

Para adicionar um registo, como gcr.io, ao seu projeto, uma conta com a função de administrador do armazenamento ao nível do projeto envia uma imagem inicial.

Por exemplo, se o anfitrião gcr.io não existir no projeto my-project, o envio da imagem gcr.io/my-project/my-image:1.0 aciona os seguintes passos:
1. Adicione o anfitrião gcr.io ao projeto
2. Crie um contentor de armazenamento para gcr.io no projeto.
3. Armazene a imagem como gcr.io/my-project/my-image:1.0
Após este envio inicial, pode conceder autorizações ao contentor de armazenamento para outros utilizadores.

Por predefinição, o Cloud Build tem as autorizações necessárias para criar um contentor de armazenamento, pelo que o envio inicial de imagens e os envios subsequentes são indistinguíveis.

Num projeto, um anfitrião do registo armazena todas as imagens no mesmo contentor de armazenamento. No exemplo seguinte, o projeto my-project tem duas imagens denominadas web-app no registo gcr.io. Um está diretamente abaixo do ID do projeto my-project. A outra imagem está no repositório team1.

gcr.io/my-project/web-app
gcr.io/my-project/team1/web-app

Artifact Registry

O Cloud Build não tem autorizações para criar um repositório padrão no domínio do Artifact Registry pkg.dev.

Uma conta com a função de administrador do repositório do Artifact Registry tem de criar o repositório antes de enviar imagens para o mesmo. Em seguida, pode conceder autorizações ao repositório para outros utilizadores.

No Artifact Registry, cada repositório é um recurso separado. Por conseguinte, todos os caminhos de imagens têm de incluir um repositório.

Caminhos de imagens válidos:

us-central1-docker.pkg.dev/my-project/team1/web-app:1.0
us-central1-docker.pkg.dev/my-project/team2/web-app:1.0

Caminho da imagem inválido (não inclui um repositório) :

us-central1-docker.pkg.dev/my-project/web-app:1.0

Os exemplos seguintes mostram situações em que o envio de uma imagem para um repositório em falta falha.

Enviar uma imagem para us-central1-docker.pkg.dev/my-project/team1 se us-central1-docker.pkg.dev/my-project/team1 não existir.
Enviar uma imagem para us-central1-docker.pkg.dev/my-project/team2 quando us-central1-docker.pkg.dev/my-project/team1 existe, mas us-central1-docker.pkg.dev/my-project/team2 não existe.

Conceder autorizações

Pontos-chave:

Google Cloud serviços têm acesso de leitura ou escrita equivalente a ambos os registos: o Container Registry e o Artifact Registry. No entanto, a conta de serviço predefinida do Cloud Build não pode criar repositórios padrão no domínio pkg.dev.
Conceda as funções adequadas do Artifact Registry a outras contas que acedam ao Artifact Registry.
O Container Registry suporta o controlo de acesso ao nível do contentor de armazenamento. O Artifact Registry suporta o controlo de acesso ao nível do repositório.

A comparação seguinte descreve as autorizações para cada serviço:

Container Registry

O Container Registry usa as funções do Cloud Storage para controlar o acesso. O Cloud Build tem as autorizações necessárias na função de administrador do armazenamento para adicionar anfitriões do Container Registry a um projeto.

Storage Object Viewer ao nível do contentor de armazenamento: Extrair (ler) imagens de anfitriões de registo existentes no projeto.
Storage Legacy Bucket Writer ao nível do contentor de armazenamento: Enviar (escrever) e extrair (ler) imagens para anfitriões de registo existentes no projeto.
Administrador de armazenamento ao nível do projeto: Adicione um anfitrião de registo a um projeto enviando uma imagem inicial para o anfitrião.

Após o envio inicial da imagem para um registo, concede funções do Cloud Storage a outras contas que requerem acesso ao contentor de armazenamento. Tenha em atenção que qualquer conta com todas as autorizações na função de administrador de armazenamento pode ler, escrever e eliminar contentores de armazenamento e objetos de armazenamento em todo o projeto.

As autorizações num contentor de armazenamento aplicam-se a todos os repositórios no registo. Por exemplo, qualquer utilizador com autorizações de visualizador de objetos de armazenamento no contentor para gcr.io/my-project pode ler imagens em todos estes repositórios:

gcr.io/my-project/team1
gcr.io/my-project/team2
gcr.io/my-project/test
gcr.io/my-project/production

Artifact Registry

O Artifact Registry tem as suas próprias funções para controlar o acesso. Estas funções permitem uma separação clara entre as funções de utilizador de administrador e de repositório.

O Cloud Build tem autorizações na função de escritor do Artifact Registry, uma vez que só precisa de enviar e extrair imagens com repositórios padrão no domínio pkg.dev.

Apenas as contas que gerem repositórios devem ter a função de administrador do repositório do Artifact Registry ou administrador do Artifact Registry.

Leitor do Artifact Registry: Apresentar artefactos e repositórios. Transferir artefactos.
Escritor do Artifact Registry: Apresentar artefactos e repositórios. Transferir artefactos, carregar novas versões de artefactos e adicionar ou atualizar etiquetas.
Administrador do repositório do Artifact Registry: Autorizações de gravação do Artifact Registry e autorizações para eliminar artefactos e etiquetas.
Administrador do Artifact Registry: Autorizações de administrador do repositório do Artifact Registry e autorizações para criar, atualizar, eliminar e conceder autorizações a repositórios.

Pode aplicar estas autorizações ao nível do repositório. Por exemplo:

Conceda acesso à equipa 1 para us-central1-docker.pkg.dev/my-project/team1
Conceda acesso à equipa 2 para us-central1-docker.pkg.dev/my-project/team2.

Para ver detalhes sobre a concessão de autorizações do Artifact Registry, consulte a documentação de controlo de acesso.

Criar e enviar imagens

Pontos-chave:

Tem de criar um repositório Docker do Artifact Registry antes de enviar uma imagem para o mesmo.
Os nomes de anfitrião do Artifact Registry são diferentes dos nomes de anfitrião do Container Registry.

O Cloud Build pode criar, etiquetar e enviar uma imagem num único passo.

Com o Container Registry, o Cloud Build pode enviar com êxito uma imagem para um anfitrião de registo que ainda não existe no Google Cloud projeto. Para este envio inicial de imagens, o Cloud Build tem autorizações para adicionar automaticamente o anfitrião do registo ao projeto.

Para adaptar um fluxo de trabalho do Container Registry:

Configure os repositórios antes de enviar imagens para os mesmos.
Atualize os caminhos das imagens no ficheiro de configuração de compilação ou nos gcloud builds submit comandos.

Criar um edifício com um ficheiro de configuração de criação

Substitua os caminhos do Container Registry para imagens que cria com o caminho para um repositório do Artifact Registry existente.

O ficheiro de exemplo cloudbuild.yamlseguinte cria a imagemus-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1', '.' ]
images:
- 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1'

Em seguida, pode criar a imagem com o comando:

gcloud builds submit --config cloudbuild.yaml

Criar com um ficheiro Docker

Substitua os caminhos do Container Registry para imagens que cria com o caminho para um repositório do Artifact Registry existente.

O seguinte comando de exemplo cria a imagem us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1 com um Dockerfile no diretório atual:

gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1

Implementar imagens

Ponto-chave:

Os nomes de anfitrião do Artifact Registry são diferentes dos nomes de anfitrião do Container Registry.

Para adaptar um fluxo de trabalho do Container Registry, atualize os caminhos das imagens na configuração de implementação e nos comandos de implementação. As secções seguintes mostram exemplos para o Cloud Build, o Cloud Run e o GKE, mas a mesma abordagem aplica-se a quaisquer outros serviços que implementem imagens. Google Cloud

Cloud Build

Substitua os caminhos do Container Registry para as imagens que implementa com o caminho para um repositório do Artifact Registry existente.

O ficheiro cloudbuild.yaml de exemplo seguinte implementa a imagem de exemplo us-docker.pkg.dev/cloudrun/container/hello.

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args:
  - 'run'
  - 'deploy'
  - 'cloudrunservice'
  - '--image'
  - 'us-docker.pkg.dev/cloudrun/container/hello'
  - '--region'
  - 'us-central1'
  - '--platform'
  - 'managed'
  - '--allow-unauthenticated'

Cloud Run

Substitua os caminhos do Container Registry para as imagens que implementa com o caminho para um repositório do Artifact Registry existente.

Por exemplo, este comando implementa a imagem de exemplo us-docker.pkg.dev/cloudrun/container/hello.

gcloud run deploy my-service --image us-docker.pkg.dev/cloudrun/container/hello

GKE

Substitua os caminhos do Container Registry para imagens que cria com o caminho para um repositório do Artifact Registry existente.

Os exemplos seguintes para o Artifact Registry usam a imagem de exemplo us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0.

Criar um cluster a partir da linha de comandos:

kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Especificar uma imagem num manifesto de implementação:

In a deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Alterações para a criação e a implementação no Google Cloud Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Alterações ao fluxo de trabalho

Ativar a API

Container Registry

Artifact Registry

Adicionar registos e repositórios

Container Registry

Artifact Registry

Conceder autorizações

Container Registry

Artifact Registry

Criar e enviar imagens

Criar um edifício com um ficheiro de configuração de criação

Criar com um ficheiro Docker

Implementar imagens

Cloud Build

Cloud Run

GKE

Alterações para a criação e a implementação no Google Cloud