Esta página foi traduzida pela API Cloud Translation.

Automatizar a reconstrução da imagem do contêiner para sincronizar as atualizações da imagem de base

Com o Cloud Workstations, é possível criar e usar imagens personalizadas para suas estações de trabalho. Depois que uma imagem personalizada está em uso, é útil automatizar uma recriação dela para extrair correções e atualizações disponíveis nas imagens de base.

Neste tutorial, você vai aprender a criar um pipeline automatizado para garantir que você inclua atualizações e patches de segurança nas imagens personalizadas da estação de trabalho.

Prepare o ambiente

Antes de continuar, defina as seguintes variáveis de ambiente.

Defina o ID do projeto do Cloud que você planeja usar:
```
PROJECT_ID=$PROJECT_ID
```
Defina o nome de usuário do GitHub em que você planeja armazenar o repositório:
```
GITHUB_USER=$GITHUB_ID
```
Defina as variáveis PROJECT_NUMBER e REGION para usar durante o processo:
```
PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

REGION=$REGION
```
No exemplo anterior, substitua $REGION pelo nome da região que você planeja usar, por exemplo, us-central1.

Para mais informações sobre as regiões disponíveis, consulte Locais do Cloud Workstations.

Crie um repositório do Artifact Registry

Neste tutorial, você vai usar o Artifact Registry para armazenar e verificar suas imagens.

Crie um repositório com o seguinte comando:

gcloud artifacts repositories create custom-images \
      --repository-format=docker \
      --location=$REGION \
      --description="Docker repository"

Substitua $REGION pelo nome da região que você planeja usar.

Configure o Docker para usar as credenciais da CLI gcloud ao acessar o Artifact Registry.
```
gcloud auth configure-docker $REGION-docker.pkg.dev
```
Observação: essa configuração também ativa a verificação automática de contêineres, que oferece verificação de vulnerabilidades, mas tem um preço extra por imagem verificada. Confira os detalhes de preços.

Para desativar Artifact Analysis, execute o seguinte comando:
```
gcloud services disable containerscanning.googleapis.com
```

Configurar seu repositório do GitHub

Na prática, você mantém o Dockerfile das suas imagens personalizadas em um repositório Git. O processo automatizado acessa esse repositório durante o processo de build para extrair as configurações relevantes e o Dockerfile.

Bifurcar o repositório de amostra

Para bifurcar um repositório de exemplo que fornece definições de contêiner, siga estas etapas:

Clique neste link para Criar um novo fork do repositório software-delivery-workshop.
Se solicitado, faça login no GitHub.
Selecione seu nome de usuário do GitHub como proprietário. O nome do repositório aparece como software-delivery-workshop.
Clique em Criar fork e aguarde alguns segundos até que o processo seja concluído.

Conectar o Cloud Build ao GitHub

Em seguida, conecte esse repositório ao Cloud Build usando o recurso de conexão do GitHub integrado. Clique no link para o repositório do GitHub e siga as instruções que descrevem como concluir o processo. Não é necessário criar o gatilho na última etapa do assistente. Você pode pular as últimas etapas porque é possível fazer isso mais tarde na linha de comando.

Conecte o Cloud Build ao repositório do GitHub

Se você usa outra solução de repositório Git, siga as instruções para conectar o Cloud Build ao GitLab ou ao Bitbucket.

Criar um gatilho do Cloud Build

O repositório de exemplo contém uma definição de contêiner e uma configuração do Cloud Build usada para criar a imagem do contêiner. Nesta etapa, você cria um gatilho do Cloud Build que executa as instruções no arquivo cloudbuild.yaml, que pode ser encontrado na pasta labs/cloudbuild-scheduled-jobs/code-oss-java.

gcloud builds triggers create manual \
    --name=custom-image-trigger \
    --repo=$GITHUB_USER/software-delivery-workshop \
    --repo-type=GITHUB \
    --branch=main \
    --build-config=labs/cloudbuild-scheduled-jobs/code-oss-java/cloudbuild.yaml \
    --substitutions=_REGION=$REGION,_AR_REPO_NAME=custom-images,_AR_IMAGE_NAME=code-oss-java,_IMAGE_DIR=labs/cloudbuild-scheduled-jobs/code-oss-java

TRIGGER_ID=$(gcloud builds triggers list \
    --filter=name="custom-image-trigger" --format="value(id)")

Este exemplo configura o seguinte:

O comando da CLI gcloud cria um gatilho manual no Cloud Build chamado custom-image-trigger, conforme indicado pela flag name na segunda linha.
As três linhas seguintes contêm flags relacionadas ao repositório de origem do GitHub:
- Caminho para o repositório
- Tipo do repositório
- Ramificação do Git para build
A flag build-config indica o caminho para o arquivo do Cloud Build no repositório Git.
Para tornar o job dinâmico, use a flag substitutions. Para esse job, o comando transmite as seguintes variáveis:
- Região, $_REGION
- Nome do repositório do Artifact Registry, $_AR_REPO_NAME
- Nome da imagem do contêiner, $_AR_IMAGE_NAME
- Local do Dockerfile a ser criado, $_IMAGE_DIR
Consulte o arquivo cloudbuild.yaml para saber como essas variáveis são usadas no processo.
Depois que o gatilho é criado, o nome exclusivo dele é recuperado e armazenado na variável de ambiente $TRIGGER_ID para uso posterior.

Configurar o Cloud Scheduler

Para garantir que suas imagens estejam atualizadas com os patches e atualizações mais recentes, use o Cloud Scheduler para executar o gatilho do Cloud Build em uma frequência definida. Neste tutorial, o job é executado todos os dias. Na prática, defina uma frequência alinhada às necessidades da sua organização para garantir que as atualizações mais recentes sejam sempre incluídas.

Conceda um papel necessário à conta de serviço padrão para invocar o gatilho do Cloud Build:

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/cloudbuild.builds.editor"

Conceda um papel necessário à conta de serviço do Cloud Build para fazer upload de imagens no Artifact Registry:

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role="roles/artifactregistry.admin"

Crie o job do Cloud Scheduler com o seguinte comando:

gcloud scheduler jobs create http run-build \
    --schedule='0 1 * * *' \
    --uri=https://cloudbuild.googleapis.com/v1/projects/$PROJECT_ID/locations/global/triggers/$TRIGGER_ID:run \
    --location=us-central1 \
    --oauth-service-account-email=$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --oauth-token-scope=https://www.googleapis.com/auth/cloud-platform

O job está definido para ser executado uma vez por dia. No entanto, para testar o recurso imediatamente, execute o job manualmente no Cloud Scheduler:

Acessar o Cloud Scheduler
1. Na página do Cloud Scheduler, encontre a entrada que você acabou de criar chamada run-build.
2. Na coluna "Ações", clique no menu de opções more_vertMais dessa linha.
3. Clique em Forçar a execução de um job para testar o sistema manualmente.
4. Depois que o comando for executado, acesse a página de histórico do Cloud Build para revisar o progresso:
  
  Acesse Histórico do Cloud Build

Analisar os resultados

Como você ativou a API Container Scanning como parte do processo de configuração, o Artifact Registry verifica automaticamente as imagens em busca de vulnerabilidades de segurança.

Para analisar as vulnerabilidades:

Abra a página "Repositórios do Artifact Registry":

Acessar repositórios do Artifact Registry
Na lista de repositórios, clique em um deles.
Clique no nome de uma imagem. O total de vulnerabilidades de cada resumo de imagem aparece na coluna Vulnerabilidades.
Para ver a lista de vulnerabilidades de uma imagem, clique no link na coluna Vulnerabilidades. A lista de vulnerabilidades mostra a gravidade, se há alguma correção disponível e o nome do pacote que contém a vulnerabilidade.