Mudanças para criar e implantar no Google Cloud

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:

1. Ative o Artifact Registry no projeto.
2. 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:

1. 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 com tag1 e a envia para o host gcr.io no projeto my-project:

   gcloud builds submit --tag gcr.io/my-project/my-image:tag1
   

2. 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.

1. 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ê.

2. 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.

3. 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
   

4. 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:

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:

gcr.io/my-project/web-app
gcr.io/my-project/team1/web-app

us-central1-docker.pkg.dev/my-project/team1/web-app:1.0
us-central1-docker.pkg.dev/my-project/team2/web-app:1.0

us-central1-docker.pkg.dev/my-project/web-app:1.0

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:

gcr.io/my-project/team1
gcr.io/my-project/team2
gcr.io/my-project/test
gcr.io/my-project/production

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:

1. Configure seus repositórios antes de enviar imagens para eles.
2. 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