Este documento orienta você sobre as diferenças entre o Container Registry e o Artifact Registry ao criar imagens de contêiner com o Cloud Build e implantá-las em ambientes de execução do Google Cloud, como o Cloud Run ou o Google Kubernetes Engine.
Neste guia, as comparações se concentram no Artifact Registry padrão
repositórios regulares do Artifact Registry que são independentes
do Container Registry e oferecer suporte a todos os recursos do Artifact Registry. Se as
configuração do administrador
repositórios com suporte ao domínio gcr.io, as solicitações
para nomes de host gcr.io
são redirecionados automaticamente para um
O repositório do Artifact Registry e as contas de serviço padrão que têm acesso
ao Container Registry têm permissões padrão equivalentes para o Artifact Registry.
Para saber mais sobre as diferenças entre o Container Registry e o do Artifact Registry usando um cliente Docker, consulte Alterações para push e pull com o Docker.
Use essas informações para adaptar comandos, configurações ou documentação existentes com foco no Container Registry com o Cloud Build.
Antes de começar
Este documento pressupõe que você já tenha:
- Ative o Artifact Registry no projeto.
- Ative a API Cloud Build e a API de qualquer outro serviço do Google Cloud que você estiver usando com o Artifact Registry.
Mudanças no fluxo de trabalho
Quando você usa o Cloud Build com o Container Registry no mesmo projeto, o fluxo de trabalho é assim:
Criar, marcar e enviar uma imagem para o repositório com o Cloud Build usando um
Dockerfile
ou um arquivo de configuração do build.O exemplo a seguir cria a imagem
my-image
, a marca comtag1
e a envia para o hostgcr.io
no projetomy-project
:gcloud builds submit --tag gcr.io/my-project/my-image:tag1
ambientes de execução do Google Cloud, como o Cloud Run e O Google Kubernetes Engine extrai imagens do registro.
Por exemplo, este comando implanta a imagem da etapa 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 criação e implantação.
- Quando você ativa algumas APIs do Google Cloud, a A API Container Registry é ativada automaticamente. Isso significa que os usuários desses e serviços têm acesso implícito ao Container Registry no mesmo projeto. Para Por exemplo, os usuários que podem executar builds no Cloud Build podem enviar imagens para registros e adicionar hosts de registro por padrão.
- A conta de serviço do Cloud Build tem permissões para criar buckets de armazenamento do Cloud Storage. Isso significa que pode adicionar automaticamente hosts do Container Registry a um projeto à primeira que envia uma imagem ao host. Isso também significa que a conta pode criar, ler e gravar em buckets de armazenamento em todo o projeto incluindo buckets que não são usados pelo Container Registry.
No Artifact Registry, há uma separação clara entre as funções de administrador e de build que muda as etapas no fluxo de trabalho de build e implantação. Para adaptar o fluxo de trabalho do Container Registry ao Artifact Registry, faça as seguintes mudanças. Cada etapa está vinculada a informações adicionais sobre como modificar o fluxo de trabalho.
Novo: ative a API Artifact Registry.
Ative a API Artifact Registry. Cloud Build e ambientes de execução, como o Cloud Run e o GKE não ativar a API automaticamente para você.
Novo: crie o repositório de destino do Docker, se ele ainda não existir. É necessário criar um repositório antes de enviar imagens para reimplantá-lo. O envio de uma imagem não aciona a criação de um repositório, e a A conta de serviço do Cloud Build não tem permissões para criar repositórios.
Alterados: Criar, marcar e enviar uma imagem para o repositório com o Cloud Build, usando um
Dockerfile
ou um arquivo de configuração de build.O comando de exemplo a seguir é 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
Mudou: implante a imagem em um ambiente de execução do Google Cloud, como o Cloud Run ou o GKE.
O comando de exemplo a seguir é 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 a imagens. Você precisa configurar as permissões. nas seguintes situações:
- Os ambientes de execução Cloud Build ou Google Cloud estão um projeto diferente do Artifact Registry.
- Você usa contas de serviço personalizadas para serviços do Google Cloud, como Cloud Build ou GKE, em vez do serviço padrão contas de serviço.
- Você concedeu permissões a outras contas de usuário ou de serviço.
Ative a API
Pontos principais
- É preciso ativar a API Artifact Registry além da API para outros serviços do Google Cloud, como Cloud Build, Cloud Run e GKE.
A comparação a seguir descreve como ativar a API para cada serviço:
Container Registry
Quando você ativa as seguintes APIs do Google Cloud, a API Container Registry também é ativada automaticamente:
- Ambiente flexível do App Engine
- Cloud Build
- Funções do Cloud Run
- Cloud Run
- Verificação de contêiner ou verificação sob demanda no Artifact Analysis
- Google Kubernetes Engine
Com as permissões padrão, os usuários que podem executar builds no Cloud Build, verificar contêineres com o Artifact Analysis ou implantar contêineres em Os ambientes de execução do Google Cloud têm acesso implícito a imagens Container Registry quando o registro estiver no mesmo projeto.
Artifact Registry
Ative a API Artifact Registry. Serviços como como o Cloud Build, o Cloud Run e o GKE não ativar automaticamente a API Artifact Registry.
É possível ativar várias APIs no mesmo projeto usando a gcloud. Por exemplo, para ativar a API Cloud Build e o API Artifact Registry, execute o comando:
gcloud services enable
artifactregistry.googleapis.com \
cloudbuild.googleapis.com
Como adicionar registros e repositórios
Pontos principais
- É preciso criar um repositório Docker do Artifact Registry antes de enviar uma imagem a ele.
- O Container Registry armazena todas as imagens em uma única multirregião no mesmo do Google Cloud Storage. No Artifact Registry, é possível criar várias na mesma região ou multirregião com políticas de acesso separadas.
A comparação a seguir descreve a configuração do repositório em cada serviço:
Container Registry
No Container Registry, é possível adicionar até quatro hosts de registro ao projeto. Você adiciona um host de registro enviando a primeira imagem.
Para adicionar um registro, como
gcr.io
, ao seu projeto, uma conta com a função de administrador do Storage no nível do projeto envia uma imagem inicial.Por exemplo, se o host
gcr.io
não existir no projetomy-project
, enviando a imagemgcr.io/my-project/my-image:1.0
acionadas as seguintes etapas:- Adicionar o host
gcr.io
ao projeto - Crie um bucket de armazenamento para
gcr.io
no projeto. - Armazenar a imagem como
gcr.io/my-project/my-image:1.0
- Adicionar o host
Após esse envio inicial, é possível conceder permissões. para o bucket de armazenamento para outros usuários.
Por padrão, o Cloud Build tem as permissões necessárias permissões para criar um bucket de armazenamento. Assim, o push da imagem inicial e os push subsequentes são indistinguíveis.
Em um projeto, um host de registro guarda todas as imagens no mesmo armazenamento
do Google Cloud. No exemplo a seguir, o projeto my-project
tem duas imagens chamadas
web-app
no registro gcr.io
. Um deles 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 permissões para criar um
repositório no domínio pkg.dev
do Artifact Registry.
Uma conta com o repositório do Artifact Registry A função de administrador deve criar a função antes de enviar imagens para ele. É possível conceder permissões ao repositório para outros usuários.
No Artifact Registry, cada repositório é um recurso separado. Portanto, todos os caminhos de imagem precisam incluir um repositório.
Caminhos de imagem 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 de imagem inválido (não inclui um repositório) :
us-central1-docker.pkg.dev/my-project/web-app:1.0
Os exemplos a seguir mostram situações em que enviar uma imagem para um repositório ausente.
- Enviar uma imagem para
us-central1-docker.pkg.dev/my-project/team1
seus-central1-docker.pkg.dev/my-project/team1
não existe. - Enviar uma imagem para
us-central1-docker.pkg.dev/my-project/team2
quandous-central1-docker.pkg.dev/my-project/team1
existe, masus-central1-docker.pkg.dev/my-project/team2
não existe.
Como conceder permissões
Pontos principais
- Os serviços do Google Cloud têm acesso de leitura ou gravação equivalente
Container Registry e Artifact Registry. No entanto, o padrão
A conta de serviço do Cloud Build não pode criar repositórios padrão
no domínio
pkg.dev
. - Conceda os papéis apropriados do Artifact Registry a outras contas que acessar o Artifact Registry.
- O Container Registry oferece suporte ao controle de acesso no nível do bucket de armazenamento. O Artifact Registry oferece suporte ao controle de acesso no nível do repositório.
A comparação a seguir descreve as permissões de cada serviço:
Container Registry
O Container Registry usa os papéis do Cloud Storage para controlar o acesso. O Cloud Build tem as permissões necessárias. o papel Administrador do Storage para adicionar hosts do Container Registry a um projeto.
- Leitor de objetos do Storage no nível do bucket de armazenamento
- Extrair (ler) imagens de hosts de registro no projeto.
- Gravador de bucket legado do Storage no nível do bucket de armazenamento
- Enviar (gravar) e extrair (ler) imagens de hosts de registro existentes no projeto.
- Administrador de armazenamento no nível do projeto
- Adicione um host de registro a um projeto enviando uma imagem inicial para o host.
Após o envio inicial da imagem para um registro, você concede papéis do Cloud Storage a outras contas que precisam de acesso ao bucket de armazenamento. Observe que qualquer com todas as permissões do papel de Administrador do Storage. Pode ler, gravar e excluir buckets e objetos de armazenamento em todo o projeto.
As permissões em um bucket de armazenamento se aplicam a todos os repositórios no registro.
Por exemplo, qualquer usuário com permissões de Leitor de objetos do Storage no
O bucket de 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 papéis próprios para controlar o acesso. Esses papéis fornecer uma separação clara entre os papéis de administrador e de usuário do repositório.
O Cloud Build tem permissões
no papel Gravador do Artifact Registry, porque ele só precisa enviar
e extrair imagens com repositórios padrão no domínio pkg.dev
.
Somente contas que gerenciam repositórios devem ter o Artifact Registry Administrador de repositório ou Administrador do Artifact Registry.
- Leitor do Artifact Registry
- Listar artefatos e repositórios. Faça o download dos artefatos.
- Gravador do Artifact Registry
- Listar artefatos e repositórios. Fazer o download de artefatos, fazer upload de novos artefatos versões e adicionar ou atualizar tags.
- Administrador do repositório do Artifact Registry
- Permissões de escritor do Artifact Registry e permissões para excluir artefatos e tags.
- Administrador do Artifact Registry
- Permissões de administrador do repositório do Artifact Registry e permissões para criar, atualizar, excluir e conceder permissões a repositórios.
É possível aplicar essas permissões no nível do repositório. Exemplo:
- Conceder acesso à Equipe 1 para
us-central1-docker.pkg.dev/my-project/team1
- Conceda acesso a Equipe 2 para
us-central1-docker.pkg.dev/my-project/team2
.
Para mais detalhes sobre a concessão de permissões do Artifact Registry, consulte documentação de controle de acesso.
Como criar e enviar imagens
Pontos principais
- É preciso criar um repositório Docker do Artifact Registry antes de enviar uma imagem a ele.
- Os nomes de host do Artifact Registry são diferentes do que o do Container Registry nomes de host.
O Cloud Build pode criar, incluir tags e enviar uma imagem em uma única etapa.
Com o Container Registry, o Cloud Build consegue enviar uma imagem para um host de registro que ainda não existe no projeto do Google Cloud. Para esse envio de imagem inicial, o Cloud Build tem permissões para adicionar o host de registro ao projeto.
Para adaptar um fluxo de trabalho do Container Registry:
- Configure seus repositórios antes de enviar imagens para eles.
- Atualize os caminhos da imagem no arquivo de configuração do build ou no
gcloud builds submit
. comandos
Como criar com um arquivo de configuração de compilação
Substitua os caminhos do Container Registry pelas imagens que você criar com o caminho para um repositório atual do Artifact Registry.
O arquivo cloudbuild.yaml
de exemplo a seguir cria a imagem
us-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, você pode criar a imagem com o comando:
gcloud builds submit --config cloudbuild.yaml
Como criar com um Dockerfile
Substitua os caminhos do Container Registry para imagens que você cria pelo caminho para um repositório do Artifact Registry.
O comando de exemplo a seguir 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
Como implantar imagens
Ponto-chave:
- Os nomes de host do Artifact Registry são diferentes do que o do Container Registry nomes de host.
Para adaptar um fluxo de trabalho do Container Registry, atualize os caminhos de imagem na implantação comandos de configuração e implantação. As seções a seguir mostram exemplos Cloud Build, Cloud Run e GKE, mas os mesmos se aplica a todos os outros serviços do Google Cloud que implantam imagens.
Cloud Build
Substitua os caminhos do Container Registry pelas imagens implantadas com o caminho para um repositório atual do Artifact Registry.
O exemplo de arquivo cloudbuild.yaml
a seguir implanta a imagem de amostra
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 pelas imagens implantadas com o caminho para um repositório atual do Artifact Registry.
Por exemplo, este comando implanta a imagem de amostra
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 pelas imagens que você criar com o caminho para um repositório atual do Artifact Registry.
Os seguintes exemplos do Artifact Registry usam a imagem de amostra
us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0
:
Como criar um cluster na linha de comando:
kubectl create deployment hello-server --image=us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0
Especificar uma imagem em um manifesto de implantaçã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/artifact-registry-samples/containers/gke/hello-app:1.0