Esta página foi traduzida pela API Cloud Translation.

gcr.io hospedado no Artifact Registry por padrão

Saiba como configurar repositórios gcr.io no Artifact Registry. saiba mais sobre as diferenças entre as permissões do Artifact Registry e do Container Registry e o bucket de armazenamento configuração do Terraform.

As etapas manuais descritas neste documento podem ser concluídas usando o ferramenta de migração automática. Se você quiser usar o modelo ferramenta de migração para fazer a transição dos projetos com uso ativo do Container Registry para repositórios padrão do Artifact Registry ou repositórios gcr.io, consulte Automatizar a migração para o Artifact Registry.

Descontinuação do Container Registry

Projetos do Google Cloud que nunca usaram o Container Registry A partir de 15 de maio de 2024, só será possível hospedar e gerenciar imagens no o Artifact Registry. Essa mudança afeta o seguinte:

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

Organizações que nunca usaram o Container Registry 8 de janeiro de 2024 terá novos repositórios gcr.io hospedados em o Artifact Registry por padrão.

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

O Container Registry permanecerá disponível nos projetos em que: ações ocorridas 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 próxima mudança, recomendamos que você faça o seguinte:

Siga as instruções neste documento para configurar projetos em que você não usam o Container Registry para estarem prontos para o processamento automático de gcr.io solicitações quando as alterações entram em vigor.
Testar o suporte ao domínio gcr.io para verificar se a automação atual vai continuar funcionando.

gcr.io repositórios hospedados no Artifact Registry são criados no mesmo multirregiões com suporte do Container Registry. Se você quer 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 ter 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 visualizar 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 inclua permissões equivalentes, como Administrador de pastas (roles/resourcemanager.folderAdmin) ou Administrador da organização (roles/resourcemanager.organizationAdmin) no projeto, na pasta ou na organização
Para listar serviços ativados em uma organização: Leitor de recursos do Cloud (roles/cloudasset.viewer) na organização

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

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

Antes de começar

É possível listar projetos em que pelo menos uma imagem está armazenada no Container Registry. Assim, você pode 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 para encontrar qualquer uso do Container Registry no seu organização do Google Cloud.

  gcloud container images list-gcr-usage \
      --organization=ORGANIZATION

Substitua ORGANIZATION pelo seu Google Cloud ID da organização.

Também é possível listar o uso do Container Registry no projeto ou na pasta. Para mais informações sobre o uso do Container Registry, consulte Verifique o uso do Container Registry.

Ativar a API

Ative a API Artifact Registry para que as solicitações para o domínio gcr.io sejam processados automaticamente pelo Artifact Registry quando a hospedagem automática do gcr.io entra 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; coloque a API Artifact Registry no perímetro também. Consulte Como proteger repositórios em um perímetro de serviço para obter instruções.

Conceder permissões a repositórios

O Container Registry usa os papéis do Cloud Storage para controlar o acesso. O Artifact Registry tem o próprio IAM papéis e esses papéis separam as funções de leitura, gravação e administração de repositório Container Registry.

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

Como alternativa, é possível conferir uma lista dos principais com acesso ao 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 visualizar. Nos nomes dos buckets, PROJECT-ID é o Google Cloud ID do projeto.
- 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 Visualizar por função.
Expanda um papel para consultar os principais que têm esse papel.

A lista inclui papéis do IAM concedidos diretamente no bucket e papéis herdados do projeto pai. Com base na função, é possível escolher o papel mais apropriado no Artifact Registry para conceder.

Cloud Storage e papéis básicos

Conceder aos usuários e contas de serviço que acessam o Container Registry com acesso aos repositórios do Artifact Registry. Para o Cloud Storage herdados do projeto pai, verifique se o principal usa o Container Registry. Alguns principais podem acessar apenas outros buckets do Cloud Storage que não estão relacionados ao Container Registry.

Os papéis básicos de Proprietário, Editor e Leitor que existiam antes o IAM tem acesso limitado a buckets de armazenamento. Elas não dão intrinsecamente todo o acesso ao Cloud Storage recursos que seus nomes indicam 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 usar a tabela de mapeamento de papéis para ajudar você concede os papéis corretos, se o acesso ao Artifact Registry for apropriado.

A tabela a seguir mapeia os 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 no Artifact Registry	Onde conceder o papel
Extrair apenas 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
Enviar e extrair imagens (leitura e gravação) Excluir imagens	Gravador de bucket legado do Storage (`roles/storage.legacyBucketWriter`)	Administrador de repositórios do Artifact Registry (`roles/artifactregistry.repoAdmin)`	Repositório do Artifact Registry ou projeto do Google Cloud
Criar um repositório gcr.io no Artifact Registry na primeira vez que uma imagem for enviado para um nome de host gcr.io em um projeto.	Administrador do Storage (`roles/storage.admin`)	Administrador de repositório de Create-on-push do Artifact Registry `(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 padrão de serviços do Google Cloud têm as próprias de papéis concedidos no nível do projeto. Por exemplo, o agente de serviço O Cloud Run tem o papel de agente de serviço do Cloud Run.

Na maioria dos casos, esses papéis de agente de serviço contêm as permissões do Container Registry e do Artifact Registry. não será necessário fazer alterações adicionais se você estiver executando Artifact Registry no mesmo projeto que o Container Registry atual serviço.

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

Papéis personalizados

Use a tabela de mapeamento de funções para ajudar você a decidir sobre o conceder a usuários ou contas de serviço com base no nível de acesso de acordo com as necessidades.

Para 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 interage diretamente com os buckets de armazenamento, é preciso atualizar para fazer as alterações correspondentes no repositório do Artifact Registry.

Por exemplo, se você conceder programaticamente permissões do Cloud Storage em buckets de armazenamento do Container Registry, é necessário atualizar essa automação para conceder Permissões do Artifact Registry nos repositórios do Artifact Registry que hospedam imagens 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 de gcr.io no Artifact Registry cria gcr.io repositórios criptografados com chaves de propriedade e gerenciadas pelo Google. Se você quiser usar chaves de criptografia gerenciadas pelo cliente (CMEK), será preciso criar gcr.io repositórios e especificar CMEK como o método de criptografia quando ao criá-los.

Para criar manualmente um repositório gcr.io:

Se você estiver usando CMEK, crie a chave que será usada com este 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 sensíveis, já que 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 propriedade e 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 incluem dados sensíveis, já que as descrições dos repositórios não são criptografadas.
- KMS-KEY é o caminho completo para a criptografia do Cloud KMS. chave, 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 seus repositórios pelo seguinte 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

Configurar o suporte ao domínio do gcr.io em um projeto de teste para verificar se a automação e a integração atuais como o Cloud Build, o Google Kubernetes Engine ou o Cloud Functions, funcionam como o esperado.