Como fazer uma transição do Container Registry

O Artifact Registry é o serviço recomendado para armazenamento e gerenciamento de imagens de contêiner no Google Cloud. Como um serviço totalmente gerenciado compatível com imagens de contêiner e artefatos que não são contêineres, o Artifact Registry estende os recursos do Container Registry.

Se você atualmente usa o Container Registry, veja as informações nesta página para saber como fazer a transição para o Artifact Registry. O Container Registry ainda está disponível e é compatível com a API Google Enterprise, mas novos recursos só estarão disponíveis no Artifact Registry. O Container Registry receberá apenas correções de segurança críticas.

Visão geral

O Artifact Registry oferece os mesmos recursos de gerenciamento de contêiner que o Container Registry e inclui mais recursos e benefícios:

Outros formatos de artefato

É possível criar repositórios para os seguintes formatos de artefato:

• Container images: Docker, Helm
• Language packages: Java, Node.js, Python
• OS packages: Debian, RPM

Repositórios regionais

O Container Registry fornece apenas hosts de registro multirregionais. O Artifact Registry fornece hosts de registro regionais e multirregionais.

Vários repositórios separados em um único local

No Container Registry, só é possível criar um único host de registro em uma multirregião, e todos os repositórios no registro compartilham o mesmo bucket de armazenamento. No Artifact Registry, cada repositório é um recurso separado. É possível aplicar diferentes políticas e marcadores do Identity and Access Management a cada repositório.

Permissões no nível do repositório

No Container Registry, você concede permissões para cada host de registro multirregional. Não é possível aplicar permissões separadas no nível do repositório. O Artifact Registry oferece controle de acesso no nível do repositório.

Papéis do IAM do Artifact Registry

No Container Registry, você usa os papéis do Cloud Storage para controlar o acesso e precisa enviar uma imagem para um host de registro antes de configurar as permissões do host. No Artifact Registry, você usa os papéis do Artifact Registry para conceder acesso, e há uma separação clara entre os papéis de administrador e de usuário do repositório.

Streaming de imagens do Google Kubernetes Engine

O GKE pode fazer streaming de dados de imagens qualificadas, conforme solicitado pelos aplicativos, para que as cargas de trabalho sejam inicializadas sem esperar o download completo da imagem. O streaming de imagens oferece escalonamento automático e inicialização de pods mais rápidos, além de latência reduzida ao extrair imagens grandes.

Implantação de origem do Cloud Run

Implante novos serviços e novas revisões no Cloud Run diretamente do código-fonte usando um único comando da CLI do Google Cloud. A implantação de origem cria uma imagem de contêiner com base no código, a armazena no Artifact Registry e a implanta no Cloud Run.

Compatibilidade com versões anteriores e coexistência

É possível usar o Artifact Registry e o Container Registry no mesmo projeto. Quando você visualiza uma lista de repositórios com gcloud ou o Console do Cloud, o Artifact Registry também lista os repositórios do Container Registry no mesmo projeto.

Para aproveitar os recursos expandidos no Artifact Registry, transfira seus contêineres e a automação para o Artifact Registry.

Opções de transição

Você pode fazer a transição para o Artifact Registry usando uma destas opções:

Repositórios padrão (recomendado)

Repositórios regulares do Artifact Registry que são compatíveis com todos os recursos e são totalmente independentes de qualquer host atual do Container Registry.

Repositórios com suporte para o domínio gcr.io

Repositórios especiais que são mapeados para nomes de host gcr.io do Container Registry. Esses repositórios são compatíveis com:

• gcloud container images commands
• redirecionar o tráfego de nomes de host gcr.io para os repositórios gcr.io correspondentes no seu projeto;

Esses repositórios têm algumas limitações de recurso. No entanto, se você tiver muitos configuramentos, scripts ou configuração de ferramentas com referências gcr.io, uma abordagem mais tática poderá ser necessária para fazer a transição para o Artifact Registry.

Os dois tipos de repositório podem coexistir para que você possa fazer a transição gradualmente. Exemplo:

• É possível criar repositórios gcr.io no Artifact Registry para fazer a transição da configuração atual do Container Registry e criar repositórios padrão para novos trabalhos.
• Você pode usar uma abordagem de vários estágios na transição. Faça a transição para repositórios gcr.io no Artifact Registry e, em seguida, passe a usar os repositórios padrão à medida que você atualiza a automação para oferecer compatibilidade total com o repositório do Artifact Registry e os caminhos de imagem.

Como configurar repositórios

No Artifact Registry, é preciso criar repositórios antes de enviar imagens para eles. Por isso, uma parte fundamental da migração para o Artifact Registry é configurar os repositórios do Artifact Registry e integrá-los à automação de CI/CD.

Para oferecer mais flexibilidade, há algumas mudanças na forma como o Artifact Registry representa repositórios.

Container Registry

Cada local multirregional está associado a um único bucket de armazenamento. Organizar suas imagens em repositórios em um nome de host é opcional. Considere o exemplo a seguir que mostra a imagem webapp em três locais:

us.gcr.io/my-project/webapp
us.gcr.io/my-project/team1/webapp
us.gcr.io/my-project/team2/webapp

Os repositórios são apenas um mecanismo de organização e não restringem o acesso. Qualquer usuário com acesso ao bucket de armazenamento para us.gcr.io neste projeto pode acessar todas as versões da imagem do contêiner webapp.

Artifact Registry

Cada repositório é um recurso separado no projeto. Como cada repositório é um recurso exclusivo, é possível:

• Dar a cada repositório um nome, descrição e rótulos
• Criar vários repositórios no mesmo local
• Configurar permissões específicas de repositório

Além disso, o local de um repositório pode ser uma região ou várias regiões.

Observação: só é possível criar repositórios gcr.io nas mesmas multirregiões dos hosts do Container Registry.

Essas alterações oferecem mais controle sobre seus repositórios. Por exemplo, se você tem equipes em São Paulo e Sydney, pode criar um repositório para cada equipe em uma região geograficamente mais próxima do que o local multirregional mais próximo.

southamerica-east1-docker.pkg.dev/my-project/team1/webapp
australia-southeast1-docker.pkg.dev/my-project/team2/webapp

Em seguida, você pode conceder a cada equipe permissões somente para o repositório da equipe.

Consulte o guia de configuração para ver instruções de transição para o Artifact Registry.

Como enviar e extrair imagens

Para adaptar a configuração, os comandos e a documentação existentes projetados para o Container Registry, as informações a seguir comparam a criação, o envio, o envio e a implantação de imagens.

• Mudanças na criação e implantação do Google Cloud
• Mudanças no processo de push e pull com o Docker

Comparação do recurso

Esta seção resume as alterações e melhorias nos recursos do Container Registry.

Recurso	Container Registry	Artifact Registry
Formatos compatíveis	Somente imagens de contêiner	Vários formatos de artefatos, incluindo imagens de contêiner, pacotes de linguagem e pacotes do SO.
Repositórios	Criação: cria um repositório automaticamente em uma multirregião se você não tiver enviado uma imagem para lá. Local: somente repositórios multirregionais. Organização: todos os repositórios no mesmo host multirregional em um projeto do Google Cloud compartilham um único bucket de armazenamento. Controle de acesso: conceda permissões no nível do projeto ou no bucket de armazenamento de cada host multirregional.	Criação: crie um repositório antes de enviar imagens para ele. Local: crie repositórios padrão em uma multirregião ou região. Por exemplo, a multirregião mais próxima da Austrália é a Ásia. Com o suporte regional, é possível criar um repositório no data center de Sydney. Organização: é possível criar diversos repositórios discretos em cada região ou multirregião. Aplique rótulos para agrupá-los por equipe, estágio de desenvolvimento ou outras categorias. Controle de acesso: conceda permissões no projeto ou em repositórios individuais.
Nomes de host	Os hosts estão no domínio gcr.io.	Os hosts estão no domínio pkg.dev. Para detalhes sobre o formato de nome, consulte Nomes de repositório e de artefato. É possível usar o suporte ao domínio gcr.io para redirecionar automaticamente o tráfego dos hosts gcr.io> para os repositórios correspondentes do Artifact Registry no mesmo projeto.
Permissões	Conceder acesso usando permissões do Cloud Storage. É possível restringir o acesso a todas as imagens armazenadas em uma multirregião, mas não para repositórios individuais. Por exemplo, é possível restringir o acesso a us.gcr.io no projeto my-project, mas não é possível conceder permissões específicas para imagens em us.gcr.io/my-project/team1 e us.gcr.io/my-project/team2	Conceder acesso usando as permissões do Artifact Registry. É possível restringir o acesso a repositórios individuais. Por exemplo, é possível controlar separadamente o acesso a imagens em us-docker.pkg.dev/my-project/team1 e us-docker.pkg.dev/my-project/team2.
Authentication	Fornece vários métodos de autenticação para enviar e extrair imagens com um cliente terceirizado.	O Artifact Registry é compatível com os mesmos métodos de autenticação do Container Registry. Consulte Como configurar a autenticação para o Docker para mais detalhes. Se você usar o auxiliar de credenciais do Docker: A versão 2.0.0 ou mais recente é obrigatória. As versões de cliente do Docker anteriores a v18.03 não são mais compatíveis. Adicione os locais do Artifact Registry que você usará para a configuração do assistente de credenciais.
Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês)	Use CMEK para criptografar os buckets de armazenamento que contêm suas imagens.	Use CMEK para criptografar repositórios individuais.
Como usar o Console do Google Cloud	Veja e gerencie imagens do Container Registry na seção Container Registry do Console do Cloud.	Veja uma lista dos seus repositórios do Artifact Registry e do Container Registry na seção Artifact Registry do Console do Cloud. Gerencie seus repositórios e imagens do Artifact Registry nesta página. Ao clicar em um repositório do Container Registry, você é direcionado para a lista de imagens na seção Container Registry do Console do Cloud.
Como usar os comandos gcloud e API	Usa comandos gcloud container images. Os comandos são compatíveis com resumos reduzidos. Se você não especificar a string de resumo completa, o Container Registry tentará localizar a imagem correta com base na string parcial.	Usa comandos gcloud artifacts docker. Os comandos não são compatíveis com resumos reduzidos. Para ver uma comparação dos comandos gcloud do Container Registry e do Artifact Registry, consulte a comparação do comando gcloud. O Artifact Registry também inclui uma API para gerenciar repositórios e artefatos em todos os formatos.
Notificações do Pub/Sub	Publica alterações no tópico gcr.	Publica alterações no tópico gcr. Se você criar repositórios no mesmo projeto que o serviço do Container Registry atual, a configuração atual do Pub/Sub funcionará automaticamente. Para saber mais, consulte Como configurar notificações do Pub/Sub.
Imagens do Docker Hub em cache	Armazena em cache as imagens do Docker Hub solicitadas com mais frequência em mirror.gcr.io.	mirror.gcr.io continua a armazenar em cache imagens do Docker Hub solicitadas com frequência.
VPC Service Controls	É possível adicionar o Container Registry a um perímetro de serviço.	É possível adicionar o Artifact Registry a um perímetro de serviço.
Armazenamento e análise de metadados	O Container Analysis fornece armazenamento de metadados, verificação de vulnerabilidades e integração com serviços que usam os metadados, como autorização binária. Os comandos da CLI do Google Cloud para trabalhar com notas e ocorrências estão no grupo gcloud container images.	O Container Analysis é compatível com o armazenamento de metadados e a verificação de vulnerabilidades para imagens de contêiner no Artifact Registry e no Container Registry. Os dois produtos usam as mesmas APIs do Container Analysis. Ao ativar as APIs do Container Analysis no Container Registry ou no Artifact Registry, as APIs são ativadas para os dois produtos. Os dois produtos usam os mesmos tópicos do Pub/Sub para notificações do Container Analysis. As assinaturas atuais incluirão notificações do Artifact Registry e do Container Registry. Os comandos da CLI do gcloud para trabalhar com notas e ocorrências estão no grupo gcloud artifacts docker.
Imagens fornecidas pelo Google	As imagens fornecidas pelo Google são hospedadas em gcr.io. Examples incluem: Imagens em cache no mirror.gcr.io. Builders do Cloud Build Imagens de base gerenciadas	As imagens fornecidas pelo Google continuam disponíveis em gcr.io.
Streaming de imagens	Indisponível	O GKE pode transmitir dados de imagens qualificadas no Artifact Registry para escalonamento automático mais rápido, inicialização mais rápida do pod e redução da latência ao extrair imagens grandes.
Implantação de origem do Cloud Run	Indisponível	A implantação de origem permite usar um único comando da CLI gcloud para criar uma imagem de contêiner do código-fonte, armazenar a imagem no Artifact Registry e implantá-la no Cloud Run.
Preços	Os preços do Container Registry são baseados no uso do Cloud Storage, incluindo armazenamento e saída de rede.	O Artifact Registry tem seu próprio preço, com base no armazenamento e na saída da rede.