Esta página foi traduzida pela API Cloud Translation.

Preparar-se para o gcr.io hospedado no Artifact Registry por padrão

Os projetos do Google Cloud que não usaram o Container Registry antes de 15 de maio de 2024 só serão compatíveis com a hospedagem e o gerenciamento de imagens no Artifact Registry. Essa alteração afeta:

Projetos recém-criados.
Projetos atuais em que você não enviou uma imagem ao Container Registry.

Quando você ativa a API Artifact Registry nesses projetos, o Artifact Registry processa automaticamente a criação de repositórios gcr.io no Artifact Registry e redireciona as solicitações para o domínio gcr.io no repositório apropriado do Artifact Registry. Ao contrário do suporte ao domínio gcr.io existente em projetos com uso ativo do Container Registry, o redirecionamento para o Artifact Registry será automático.

O Container Registry permanecerá disponível em projetos em que uma das seguintes ações ocorreu antes de 15 de maio de 2024:

Você ativou a API Container Registry no projeto.
Você enviou uma imagem para um host de registro no projeto.

Para se preparar para a mudança, recomendamos que você:

Siga as instruções neste documento para configurar projetos em que você não está usando o Container Registry para que estejam prontos para o processamento automático de solicitações gcr.io quando as alterações entrarem em vigor.
Teste o suporte ao domínio gcr.io antes que a hospedagem automática de domínio gcr.io no Artifact Registry entre em vigor para verificar se sua automação existente continuará funcionando.

Os repositórios gcr.io hospedados no Artifact Registry são criados nas mesmas multirregiões compatíveis com o Container Registry. Se quiser armazenar suas imagens em outras regiões, será necessário fazer a transição para repositórios padrão no domínio pkg.dev.

Funções exigidas

Para receber as permissões necessárias para configurar repositórios gcr.io, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para criar repositórios do Artifact Registry e conceder acesso a repositórios individuais: Administrador do Artifact Registry (roles/artifactregistry.admin) no projeto
Para ver e gerenciar a configuração atual do Container Registry aplicada aos buckets de armazenamento do Cloud Storage: Administrador do Storage (roles/storage.admin) no projeto
Para conceder acesso ao repositório no nível do projeto: Administrador de IAM do projeto (roles/resourcemanager.projectIamAdmin) ou um papel que inclui permissões equivalentes, como Administrador de pastas (roles/resourcemanager.folderAdmin) ou Administrador de organização (roles/resourcemanager.organizationAdmin) no projeto, pasta ou organização
Para listar os serviços ativados em uma organização: Visualizador de recursos do Cloud (roles/cloudasset.viewer) na organização

Para mais informações sobre como conceder papéis, consulte Gerenciar o acesso.

Também é possível conseguir as permissões necessárias com papéis personalizados ou outros papéis predefinidos.

Antes de começar

Você pode listar projetos em que pelo menos uma imagem está armazenada no Container Registry. Assim, é possível se concentrar na configuração de outros projetos para hospedar solicitações gcr.io no Artifact Registry usando as instruções deste documento.

Execute o comando a seguir, substituindo ORGANIZATION pelo ID da organização do Google Cloud:

gcloud asset search-all-resources \
    --scope='organizations/ORGANIZATION' \
    --asset-types='containerregistry.googleapis.com/Image' \
    --format=json \
    | jq ".[].project" | sort | uniq

Ativar a API

Ative a API Artifact Registry para que as solicitações para o domínio gcr.io sejam processadas automaticamente pelo Artifact Registry quando a hospedagem automática do gcr.io entrar em vigor.

Execute este comando:

gcloud services enable \
    artifactregistry.googleapis.com

Se você normalmente coloca a API Container Registry em um perímetro de serviço do VPC Service Controls, também coloque a API Artifact Registry no perímetro. Consulte Como proteger repositórios em um perímetro de serviço para ver instruções.

Conceder permissões aos repositórios

O Container Registry usa papéis do Cloud Storage para controlar o acesso. O Artifact Registry tem os próprios papéis do IAM. Esses papéis separam os papéis de administração de leitura, gravação e repositório de maneira mais clara do que o Container Registry.

Para mapear rapidamente as permissões atuais concedidas em buckets de armazenamento para os papéis sugeridos do Artifact Registry, use a ferramenta de mapeamento de papéis.

Como alternativa, é possível ver uma lista de principais com acesso a buckets de armazenamento usando o console do Google Cloud.

No Console do Google Cloud, acesse a página Buckets do Cloud Storage.

Acessar buckets
Clique no bucket de armazenamento do host de registro que você quer ver. Nos nomes de bucket, PROJECT-ID é o ID do projeto do Google Cloud.
- gcr.io: artifacts.PROJECT-ID.appspot.com
- asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
- eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
- us.gcr.io: us.artifacts.PROJECT-ID.appspot.com
Clique na guia Permissões..
Na guia "Permissões", clique na subguia Ver por papel.
Expanda um papel para ver os principais que o têm.

A lista inclui papéis do IAM concedidos diretamente no bucket e papéis herdados do projeto pai. Com base no papel, é possível escolher o papel mais apropriado do Artifact Registry a ser concedido.

Cloud Storage e papéis básicos

Conceda a usuários e contas de serviço que acessam o Container Registry com acesso aos repositórios do Artifact Registry. Para os papéis do Cloud Storage herdados do projeto pai, verifique se o principal usa o Container Registry atualmente. Algumas principais só podem acessar outros buckets do Cloud Storage não relacionados ao Container Registry.

Os papéis básicos de proprietário, editor e Leitor que existiam antes do IAM têm acesso limitado aos buckets de armazenamento. Eles não dão intrínseca todo o acesso aos recursos do Cloud Storage que os nomes implicam e fornecem permissões adicionais para outros serviços do Google Cloud. Verifique quais usuários e contas de serviço exigem acesso ao Artifact Registry e use a tabela de mapeamento de papéis para ajudar a conceder os papéis corretos se o acesso ao Artifact Registry for apropriado.

A tabela a seguir mapeia papéis do Artifact Registry com base nas permissões concedidas por papéis predefinidos do Cloud Storage para acesso ao Container Registry.

Acesso necessário	Papel atual	Papel do Artifact Registry	Onde conceder papel
Extrair somente imagens (somente leitura)	Leitor de objetos do Storage (`roles/storage.objectViewer`)	Leitor do Artifact Registry (`roles/artifactregistry.reader)`	Repositório do Artifact Registry ou projeto do Google Cloud
imagens push e pull (leitura e gravação) Excluir imagens	Gravador de bucket legado do Storage (`roles/storage.legacyBucketWriter`)	Administrador do repositório do Artifact Registry (`roles/artifactregistry.repoAdmin)`	Repositório do Artifact Registry ou projeto do Google Cloud
Crie um repositório gcr.io no Artifact Registry na primeira vez que uma imagem for enviada para um nome de host gcr.io em um projeto.	Administrador do Storage (`roles/storage.admin`)	Administrador de repositórios do Artifact Registry para criação por push `(roles/artifactregistry.createOnPushRepoAdmin)`	Projeto do Google Cloud
Criar, gerenciar e excluir repositórios	Administrador do Storage (`roles/storage.admin`)	Administrador do Artifact Registry `(roles/artifactregistry.Admin)`	Projeto do Google Cloud

Papéis de agente de serviço herdados do projeto

As contas de serviço padrão para serviços do Google Cloud têm os próprios papéis concedidos no nível do projeto. Por exemplo, o agente de serviço do Cloud Run tem o papel de agente de serviço do Cloud Run.

Na maioria dos casos, esses papéis contêm permissões padrão equivalentes para o Container Registry e o Artifact Registry, e não será necessário fazer outras alterações se você estiver executando o Artifact Registry no mesmo projeto do serviço do Container Registry.

Consulte a referência do papel de agente de serviço para detalhes sobre as permissões nos papéis dele.

Papéis personalizados

Use a tabela de mapeamento de papéis para decidir qual papel conceder a usuários ou contas de serviço com base no nível de acesso exigido.

Para ver instruções sobre como conceder papéis do Artifact Registry, consulte Configurar papéis e permissões.

Configuração do bucket de armazenamento

Quando você cria um repositório no Artifact Registry, ele não cria buckets correspondentes do Cloud Storage no projeto. Se você tiver automação para o Container Registry que interaja diretamente com buckets de armazenamento, será necessário atualizá-la para fazer alterações correspondentes no repositório do Artifact Registry.

Por exemplo, se você conceder de maneira programática permissões do Cloud Storage em buckets de armazenamento para o Container Registry, será necessário atualizar essa automação para conceder permissões ao Artifact Registry nos repositórios do Artifact Registry que hospedam imagens para o domínio gcr.io.

No Artifact Registry, você define o método de criptografia para dados armazenados em um repositório em vez de um bucket de armazenamento. A hospedagem automática do gcr.io no Artifact Registry cria repositórios do gcr.io que são criptografados com chaves gerenciadas pelo Google. Se você quiser usar chaves de criptografia gerenciadas pelo cliente (CMEK), crie os repositórios gcr.io você mesmo e especifique o CMEK como o método de criptografia ao criá-los.

Para criar manualmente um repositório gcr.io:

Se você estiver usando CMEK, crie a chave que será usada com esse repositório e conceda permissões para usá-la. Consulte Como ativar chaves de criptografia gerenciadas pelo cliente.
Adicione o repositório.
Console
1. Abra a página Repositórios no Console do Google Cloud.
  
  Abrir a página Repositórios
2. Clique em Criar repositório.
3. Especifique o nome do repositório.
  
  Nome do host do Container Registry Nome do repositório do Artifact Registry
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
4. Especifique o Docker como o formato do repositório.
5. Em Tipo de local, especifique a multirregião do repositório:
  
  Nome do host do Container Registry Local do repositório do Artifact Registry
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
6. Adicione uma descrição para o repositório. Não inclua dados confidenciais, porque as descrições do repositório não são criptografadas.
7. Na seção Criptografia, escolha o mecanismo de criptografia do repositório.
  - Chave gerenciada pelo Google: criptografe o conteúdo do repositório com uma chave de criptografia gerenciada pelo Google.
  - Chave gerenciada pelo cliente: criptografe o conteúdo do repositório com uma chave controlada por você por meio do Cloud Key Management Service. Para instruções de configuração de chaves, consulte Como configurar CMEK para repositórios.
8. Clique em Criar.
gcloud
Execute o comando abaixo para criar um novo repositório.
```
gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description=DESCRIPTION \
    --kms-key=KMS-KEY
```
Substitua os seguintes valores:
- REPOSITORY é o nome do repositório.
  
  Nome do host do Container Registry Nome do repositório do Artifact Registry
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
- LOCATION é a multirregião do repositório:
  
  Nome do host do Container Registry Local do repositório do Artifact Registry
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
- DESCRIPTION é uma descrição do repositório. Não inclua dados confidenciais, porque as descrições do repositório não são criptografadas.
- KMS-KEY é o caminho completo para a chave de criptografia do Cloud KMS se você estiver usando uma chave de criptografia gerenciada pelo cliente para criptografar o conteúdo do repositório. O caminho está no formato:
```
projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY
```
  Substitua os seguintes valores:
  - KMS-PROJECT é o projeto em que a chave está armazenada.
  - KMS-LOCATION é o local da chave.
  - KEY-RING é o nome do keyring.
  - KEY é o nome da chave.
Para confirmar se o repositório foi criado, liste-os com o comando:
```
gcloud artifacts repositories list
```

Nome do host do Container Registry	Nome do repositório do Artifact Registry
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

Nome do host do Container Registry	Local do repositório do Artifact Registry
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

Nome do host do Container Registry	Nome do repositório do Artifact Registry
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

Nome do host do Container Registry	Local do repositório do Artifact Registry
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

A seguir

Antes que as alterações entrem em vigor para projetos que não usam ativamente o Container Registry, configure o suporte ao domínio gcr.io em um projeto de teste para verificar se a automação e a integração atuais com serviços como o Cloud Build, o Google Kubernetes Engine ou o Cloud Functions funcionam conforme o esperado. Se ocorrerem problemas quando o redirecionamento estiver ativado, será possível redirecionar o tráfego do gcr.io de volta para o Container Registry e fazer as alterações necessárias para resolver o problema.