O Container Registry foi descontinuado e está programado para ser desativado. A partir de 15 de maio de 2024, o Artifact Registry vai hospedar imagens para o domínio gcr.io em projetos sem uso anterior do Container Registry. O Container Registry será desativado em 18 de março de 2025.

Para começar a gerenciar contêineres no Google Cloud, use o Artifact Registry. Se você usa o Container Registry, saiba como fazer a transição para o Artifact Registry e gerenciar seus contêineres no Google Cloud.

Para mais informações sobre a descontinuação e o encerramento, consulte a página descontinuações e as notas da versão.

Esta página foi traduzida pela API Cloud Translation.

Como migrar contêineres de um registro de terceiros

Se você extrair algumas imagens de contêiner diretamente de registros de terceiros para implantar em ambientes do Google Cloud, como o Google Kubernetes Engine ou o Cloud Run, os limites de taxa em pulls de imagens ou interrupções de terceiros poderão interromper suas criações e implantações. Esta página descreve como identificar e copiar essas imagens para um registro no Google Cloud para um gerenciamento de imagem de contêiner consolidado e consistente.

Além disso, você pode aproveitar outros recursos, incluindo a proteção da sua cadeia de suprimentos de software com a verificação de vulnerabilidades e a aplicação de políticas de implantação com a autorização binária.

Como escolher um registro

O Artifact Registry é o serviço recomendado para armazenar e gerenciar imagens de contêiner e outros artefatos de build no Google Cloud.

Se você não estiver usando o Container Registry, migre as imagens para o Artifact Registry. O Artifact Registry oferece maior flexibilidade e controle, incluindo armazenamento de imagens em uma região em vez de uma multirregião, controle de acesso mais granular e suporte a outros formatos de artefato.
Se você estiver usando o Container Registry, faça a transição para o Artifact Registry.

Visão geral da migração

A migração das imagens de contêiner inclui as seguintes etapas:

Pré-requisitos.
Identifique imagens para migrar.
- Pesquisar nos arquivos do Dockerfile e nos manifestos de implantação para fins de referência a registros de terceiros
- Determine a frequência de pull de imagens de registros de terceiros usando o Cloud Logging e o BigQuery.
Copie imagens identificadas para o Container Registry.
Verifique se as permissões ao registro estão configuradas corretamente, especialmente se o Container Registry e o ambiente de implantação do Google Cloud estiverem em projetos diferentes.
Atualize os manifestos das implantações.
Reimplante as cargas de trabalho.
(Opcional) Bloqueie as implantações de imagens de fontes de terceiros.

O Container Registry não monitora registros de terceiros para atualizações de imagens copiadas para o Container Registry. Se você quiser incorporar uma versão mais recente de uma imagem ao seu pipeline, envie-a para o Container Registry.

Antes de começar

Verifique suas permissões. Você precisa ter o papel de IAM Proprietário ou Editor nos projetos em que está migrando imagens para o Container Registry.
Acessar a página do seletor de projetos
1. Selecione o projeto do Google Cloud em que você quer usar o Container Registry.
2. No console do Google Cloud, acesse o Cloud Shell.
3. Encontre o ID do projeto e configure-o no Cloud Shell. Substitua YOUR_PROJECT_IDpelo código do projeto:
```
gcloud config set project YOUR_PROJECT_ID
```

Exporte as seguintes variáveis de ambiente:

  export PROJECT=$(gcloud config get-value project)

Ative as APIs do BigQuery, Container Registry e Cloud Monitoring com o seguinte comando:

gcloud services enable \
containerregistry.googleapis.com \
stackdriver.googleapis.com \
logging.googleapis.com \
monitoring.googleapis.com

Verifique se o Go versão 1.13 ou mais recente está instalado.
- Verifique a versão de uma instalação em Go com o comando:
```
go version
```
- Se você precisar instalar ou atualizar o Go, consulte a documentação de instalação.

Custos

Neste guia, usamos os seguintes componentes faturáveis do Google Cloud:

Identificar imagens para migrar

Pesquise os arquivos que você usa para criar e implantar as imagens de contêiner para se referir a referências a registros de terceiros. Depois, verifique a frequência com que você extrai as imagens.

Identificar referências em Dockerfiles

Execute esta etapa em um local em que seus Dockerfiles estão armazenados. Pode ser aqui que o código será verificado localmente ou no Cloud Shell se os arquivos estiverem disponíveis em uma VM.

No diretório com Dockerfiles, execute o comando:

grep -inr -H --include Dockerfile\* "FROM" . | grep -i -v -E 'docker.pkg.dev|gcr.io'

A resposta tem a aparência do exemplo a seguir.

./code/build/baseimage/Dockerfile:1:FROM debian:stretch
./code/build/ubuntubase/Dockerfile:1:FROM ubuntu:latest
./code/build/pythonbase/Dockerfile:1:FROM python:3.5-buster

Esse comando pesquisa todos os Dockerfiles no seu diretório e identifica a linha "FROM". Ajuste o comando conforme necessário para corresponder à maneira como você armazena os Dockerfiles.

Identificar referências em manifestos

Execute esta etapa em um local em que seus manifestos do GKE ou do Cloud Run estão armazenados. Pode ser aqui que o código será disponibilizado localmente ou no Cloud Shell se os arquivos estiverem disponíveis em uma VM.

No diretório com seus manifestos do GKE ou do Cloud Run, execute o comando a seguir:
```
grep -inr -H --include \*.yaml "image:" . | grep -i -v -E 'docker.pkg.dev|gcr.io'
```
Exemplo de saída:
```
./code/deploy/k8s/ubuntu16-04.yaml:63: image: busybox:1.31.1-uclibc
./code/deploy/k8s/master.yaml:26:      image: kubernetes/redis:v1
```
Esse comando analisa todos os arquivos YAML no diretório e identifica a linha image:. Ajuste conforme o necessário para trabalhar com a forma como os manifestos são armazenados.
Para listar as imagens em execução no cluster, execute o comando:
```
  kubectl get all --all-namespaces -o yaml | grep image: | grep -i -v -E 'docker.pkg.dev|gcr.io'
```
Esse comando retorna todos os objetos em execução no cluster do Kubernetes selecionado atualmente e recebe os nomes das imagens.

Exemplo de saída:
```
- image: nginx
  image: nginx:latest
    - image: nginx
    - image: nginx
```

Execute este comando para todos os clusters do GKE em todos os projetos do Google Cloud para cobertura total.

Identificar a frequência de pull de um registro de terceiros

Em projetos que extraem registros de terceiros, use informações sobre a frequência de extração de imagens para determinar se o uso está próximo ou acima do limite de taxa que o registro de terceiros impõe.

Coletar dados do registro

Crie um coletor de registros para exportar dados para o BigQuery. Um coletor de registro inclui um destino e uma consulta que seleciona as entradas de registro a serem exportadas. É possível criar um coletor consultando projetos individuais ou usar um script para coletar dados entre projetos.

Para criar um coletor para um único projeto:

Estas instruções são para a interface de visualização do Logging.

Acesse o Explorador de registros
Escolha um projeto do Google Cloud.

Na guia Criador de consultas, insira a seguinte consulta:

  resource.type="k8s_pod"
  jsonPayload.reason="Pulling"

Filtro do histórico de alterações de Lastltima hora para Lastltimos sete dias.
Clique em Run.
Depois de verificar se os resultados aparecem corretamente, clique em Ações > Criar coletor.
Na lista de coletores, selecione Conjunto de dados do BigQuery e clique em Avançar.
No painel Editar coletor, execute as seguintes etapas:
- No campo Nome do coletor, digite image_pull_logs.
- No campo Destino do coletor, crie um novo conjunto de dados ou escolha um conjunto de dados de destino em outro projeto.
Clique em Criar coletor.

Para criar um coletor para vários projetos:

Abra o Cloud Shell.

Execute os comandos a seguir no Cloud Shell:

PROJECTS="PROJECT-LIST"
DESTINATION_PROJECT="DATASET-PROJECT"
DATASET="DATASET-NAME"

for source_project in $PROJECTS
do
  gcloud logging --project="${source_project}" sinks create image_pull_logs bigquery.googleapis.com/projects/${DESTINATION_PROJECT}/datasets/${DATASET} --log-filter='resource.type="k8s_pod" jsonPayload.reason="Pulling"'
done

em que

PROJECT-LIST é uma lista de IDs de projeto do Google Cloud, separados por espaços. Por exemplo, project1 project2 project3.
DATASET-PROJECT é o projeto em que você quer armazenar o conjunto de dados.
DATASET-NAME é o nome do conjunto de dados, por exemplo, image_pull_logs;

Depois de criar um coletor, leva um tempo para que os dados fluam para as tabelas do BigQuery, dependendo da frequência com que imagens são extraídas.

Consultar frequência de pull

Depois que você tiver uma amostra representativa de pulls de imagens feitas por suas compilações, execute uma consulta para a frequência de pull.

Acesse o console do BigQuery.

Execute a seguinte consulta:

SELECT
  REGEXP_EXTRACT(jsonPayload.message, r'"(.*?)"') AS imageName,
  COUNT(*) AS numberOfPulls
FROM
      `DATASET-PROJECT.DATASET-NAME.events_*`
GROUP BY
      imageName
ORDER BY
      numberOfPulls DESC

em que

DATASET-PROJECT é o projeto que contém seu conjunto de dados.
DATASET-NAME é o nome do conjunto de dados.

No exemplo a seguir, mostramos a saída da consulta. Na coluna imageName, é possível revisar a frequência de pull para imagens que não estão armazenadas no Container Registry ou no Artifact Registry.

Copiar imagens para o Container Registry

Depois de identificar imagens de registros de terceiros, será possível copiá-las para o Container Registry. A ferramenta gcrane ajuda no processo de cópia.

Crie um arquivo de texto images.txt no Cloud Shell com os nomes das imagens identificadas. Por exemplo:
```
ubuntu:18.04
debian:buster
hello-world:latest
redis:buster
jupyter/tensorflow-notebook
```

Faça o download de gcrane.

  GO111MODULE=on go get github.com/google/go-containerregistry/cmd/gcrane

Crie um script chamado copy_images.sh para copiar sua lista de arquivos.

Observação: este script e as instruções nesta página presumem que você esteja copiando imagens para gcr.io. Se você quiser usar um host multirregional diferente, como eu.gcr.io, atualize as configurações e os scripts de exemplo de acordo com isso.
```
#!/bin/bash

images=$(cat images.txt)

if [ -z "${GCR_PROJECT}" ]
then
    echo ERROR: GCR_PROJECT must be set before running this
    exit 1
fi

for img in ${images}
do
    gcrane cp ${img} gcr.io/${GCR_PROJECT}/${img}
done
```
Torne o script executável:
```
  chmod +x copy_images.sh
```

Execute o script para copiar os arquivos:

GCR_PROJECT=${PROJECT}
./copy_images.sh

Verificar permissões

Por padrão, os serviços de CI/CD do Google Cloud têm acesso ao Container Registry no mesmo projeto do Google Cloud.

O Cloud Build pode enviar e extrair imagens
Ambientes de execução como GKE, Cloud Run, o ambiente flexível do App Engine e o Compute Engine podem extrair imagens.

Se você precisar enviar ou extrair imagens entre projetos ou usar ferramentas de terceiros no pipeline que precisem acessar o Container Registry, verifique se as permissões estão configuradas corretamente antes da atualização. reimplante as cargas de trabalho.

Para mais informações, consulte a documentação de controle de acesso.

Atualizar manifestos para se referir ao Container Registry

Atualize seus Dockerfiles e seus manifestos para se referir ao Container Registry em vez do registro de terceiros.

O exemplo a seguir mostra o manifesto que referencia um registro de terceiros:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Essa versão atualizada do manifesto aponta para a imagem no Container Registry:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: gcr.io/<GCR_PROJECT>/nginx:1.14.2
        ports:
        - containerPort: 80

Para um grande número de manifestos, use sed ou outra ferramenta que processe atualizações em vários arquivos de texto.

Reimplantar cargas de trabalho

Reimplante as cargas de trabalho com os manifestos atualizados.

Acompanhe os novos pulls de imagem executando a seguinte consulta no console do BigQuery:

SELECT`

FORMAT_TIMESTAMP("%D %R", timestamp) as timeOfImagePull,
REGEXP_EXTRACT(jsonPayload.message, r'"(.*?)"') AS imageName,
COUNT(*) AS numberOfPulls
FROM
  `image_pull_logs.events_*`
GROUP BY
  timeOfImagePull,
  imageName
ORDER BY
  timeOfImagePull DESC,
  numberOfPulls DESC

Todos os novos pulls de imagem precisam ser do Container Registry e conter a string gcr.io.

(Opcional) Bloquear a extração de imagens de registros de terceiros

Para clusters do GKE que usam a autorização binária, a política definida bloqueia automaticamente pulls de fontes não confiáveis. Verifique se as imagens migradas não estão bloqueadas pela política adicionando-as à lista de isenções. Nestas instruções, descrevemos como especificar uma isenção para todas as imagens armazenadas no Container Registry no seu projeto.

Ao atualizar a política inicialmente, ative o modo de execução seca. Em vez de bloquear imagens, a autorização binária cria entradas de registro de auditoria para que seja possível identificar imagens pendentes de registros de terceiros que você precisa migrar para o Container Registry.

Para mais informações sobre como configurar políticas de implantação, consulte a documentação da autorização binária.

Acessar a página de autorização binária
Clique em Editar política.
Em Regra padrão do projeto, ative o Modo de execução do Dry.
Em Imagens isentas de regras de implantação, deixe Confiar em todas as imagens de sistema fornecidas pelo Google selecionadas.
Expanda Caminhos da imagem.
Adicione o caminho às imagens como uma isenção à regra padrão do projeto:
1. Na parte inferior da lista de imagens, clique em Adicionar imagens.
2. Insira o caminho da imagem do projeto do Google Cloud. Por exemplo, gcr.io/my-project/* isenta todas as imagens no projeto my-project.
Repita a etapa anterior para outros projetos que contêm imagens que você quer implantar.

Revise os eventos de simulação no Logging para suas implantações. Migre todas as imagens restantes que você recebe regularmente de registros de terceiros. Quando todas as imagens forem migradas, edite a política para desativar o modo de simulação e bloquear as imagens em fontes não confiáveis.