Como usar recomendações para infraestrutura como código

---

Visão geral

O Google Cloud Policy Intelligence ajuda as empresas a entender e gerenciar políticas para reduzir riscos. Ao fornecer mais visibilidade e automação, os clientes podem aumentar a segurança sem aumentar a carga de trabalho.

O recomendador permite que você recupere recomendações para recursos do Google Cloud e ajuda a economizar, melhorar a segurança na nuvem e muito mais. Para ver uma lista de recomendações compatíveis, consulte a documentação do recomendador. Neste tutorial, descrevemos o uso de recomendações de dimensionamento para instâncias de VM e recomendações de gerenciamento de identidade e acesso (IAM). O recomendador usa machine learning para fornecer aos administradores recomendações para remover o acesso desnecessário a recursos do Google Cloud e para redimensionar instâncias do Compute Engine e ter uma utilização de recursos mais eficiente.

Cada recomendação inclui uma ação sugerida e seu impacto. Depois de analisar as recomendações para os impactos identificados, bem como outras considerações específicas para seu ambiente, selecione as recomendações que você quer aplicar. É possível aplicar recomendações manualmente do console do Google Cloud ou aplicá-las de maneira programática, integrando-as ao pipeline de infraestrutura como código (IaC, na sigla em inglês).

A infraestrutura como código (IaC, na sigla em inglês) permite automatizar a criação dos recursos do Google Cloud. É preciso manter o repositório de IaC atualizado e encaminhar as alterações feitas na organização do Google Cloud por meio dele. As estratégias de IaC nas organizações geralmente são vantajosas quando implementadas com rigor e atuam como a única versão da verdade para a infraestrutura em nuvem. Manter o repositório de IaC atualizado é essencial para evitar desvios entre a versão da infraestrutura que o repositório de IaC reflete e a versão que você tem na organização.

Recomendações de IAM

Entre outras práticas recomendadas, uma prática comum é o princípio de segurança de menor privilégio e uma consideração cuidadosa em como as alterações na sua organização são implantadas e sincronizadas com seu repositório de IaC.

Recomendação de dimensionamento para VMs

As recomendações de dimensionamento ajudam a reduzir custos fornecendo sugestões para redimensionar o tipo de máquina das instâncias para usar recursos de instância com mais eficiência.

Este tutorial descreve como arquitetar e criar um pipeline de automação para aplicar uma recomendação de inteligência de política de maneira programática. Como parte desse pipeline de automação, você aprenderá como manter seu repositório de infraestrutura como código (IaC, na sigla em inglês) atualizado com as alterações que decidir fazer na sua organização do Google Cloud com base no dimensionamento da VM e na recomendação das vinculações de política de IAM disponibilizadas pelo recomendador.

Neste tutorial, usamos o Hashicorp Terraform como a ferramenta de IaC. No entanto, os padrões e componentes de arquitetura usados no pipeline de automação descrito podem ser aproveitados, mesmo se você estiver usando uma ferramenta de gerenciamento de IaC diferente, como o Deployment Manager. Será necessário modificar a base de código aberto disponibilizada neste tutorial para atender à implementação específica de IaC.

Este guia é direcionado a arquitetos, proprietários de produtos e desenvolvedores que podem ser responsáveis pela administração, segurança e planejamento de infraestrutura do Google Cloud.

Arquitetura do pipeline de automação

O diagrama a seguir mostra os componentes que você usa nesse pipeline de automação.

Um job programado do Cloud Scheduler executa o serviço do analisador do recomendador. O serviço chama a API Recommender para recuperar recomendações do recomendador para os projetos que você especificar. Em seguida, ele analisa o dimensionamento da VM e as recomendações do IAM para mapeá-las para a configuração dos manifestos do Terraform. O serviço atualiza os manifestos de IaC para refletir essas recomendações. Ele gera uma solicitação de envio com as alterações para que você possa analisar as atualizações. Depois de analisar e mesclar a solicitação de envio, um job do Cloud Build implantará as alterações na infraestrutura da sua organização do Google Cloud.

Vários serviços complementares do Google Cloud são usados no pipeline para rastrear recomendações processadas, gerando notificações sobre a conclusão da versão e armazenando o estado do Terraform. Você aprenderá mais sobre esses serviços ao longo deste tutorial.

A lista a seguir descreve os propósito dos componentes e os requisitos de controle de acesso:

Recomendadores do Platform Intelligence

Purpose: gere recomendações de segurança e de dimensionamento de VM

Controle de acesso: a conta de serviço do Google Cloud precisa ter as permissões de IAM necessárias para recuperar recomendações usando a API Recommender.

Analise os papéis e as permissões do recomendador para selecionar o papel mais adequado aplicável à conta de serviço que você usa para executar o serviço do analisador do recomendador.

• Permissões para o recomendador do IAM
• Permissões para dimensionamento de instâncias do Compute Engine

Cloud Scheduler

Finalidade: o Cloud Scheduler aciona o serviço do analisador do recomendador. Com o Cloud Scheduler, é possível configurar vários jobs que invocam quantas instâncias do serviço do analisador forem necessárias. Cada invocação precisa transmitir as seguintes entradas

• Lista de projetos para os quais as recomendações precisam ser processadas
• Tipo de recomendação
• Nome do repositório de IaC

Observação: se tiver mais de um repositório de IaC na sua empresa, talvez você queira configurar vários jobs do programador. Geralmente, esse é um padrão comum em grandes empresas.

Controle de acesso: crie ou identifique uma conta de serviço do Google Cloud para usar nas chamadas do Cloud Scheduler para o serviço do analisador do recomendador.

Conceda à conta de serviço o papel de agente de serviço do Cloud Scheduler para que seja possível executar jobs do Cloud Scheduler. Além disso, conceda à conta de serviço o papel de chamador do Cloud Run, já que essa conta invoca um serviço do Cloud Run

Para saber mais detalhes, consulte a documentação sobre como configurar o acesso autenticado para jobs do programador.

Serviço do Cloud Run

Propósito: o serviço do analisador do recomendador é o local em que reside toda a lógica de processamento. Ele tem várias rotas, cada uma com uma finalidade específica:

• Como analisar recomendações para cada tipo de recomendação.
• Como atualizar o status das recomendações que estão sendo processadas

Controle de acesso: use o IAM para gerenciar o acesso a esse serviço.

Além disso, atribua o serviço a uma conta de serviço dedicada. Isso garante que somente o serviço possa invocar outros serviços, como o Firestore.

Hashicorp Terraform

Objetivo: o Terraform 0.12 é a ferramenta IaC.

Um criador do Cloud Build para o Terraform é usado para invocar comandos do Terraform e a conta de serviço do Cloud Build é usada para essa finalidade.

Cloud Build

Propósito: o Google Cloud Build automatiza a implantação de infraestrutura com base nas alterações feitas nos manifestos do IaC por recomendações de inteligência de política.

Controle de acesso: a conta de serviço do Cloud Build precisa ter o conjunto certo de permissões para interagir com os recursos no projeto de teste.

Veja a documentação sobre como configurar uma conta de serviço do Cloud Build.

GitHub

Propósito: o repositório de IaC usa o GitHub para controle de origem. O repositório de IaC no GitHub é integrado ao Cloud Build. Quando as confirmações são feitas na ramificação mestre, um job do Cloud Build é acionado para executar um conjunto de tarefas pré-configuradas.

Controle de acesso: você precisará gerar chaves SSH para ativar o acesso ao repositório de IaC.

Além disso, você precisa gerar um token de acesso pessoal para enviar confirmações para o GitHub.

Observação: chaves SSH e um token de acesso pessoal são necessários ao interagir com repositórios particulares hospedados no GitHub. Se o repositório for público (não recomendado), esta etapa não se aplicará a você.

Firestore

O Firestore é um banco de dados de documentos NoSQL escalonável e totalmente gerenciado usado nesta arquitetura para manter informações relacionadas aos IDs de recomendação analisados pelo serviço do analisador do recomendador com os detalhes correspondentes pertinentes à confirmação do Git.

Os detalhes mantidos no Firestore desempenham um papel fundamental no Feedback Loop, que faz parte do pipeline completo. Depois de escolher uma recomendação gerada pela API Recommender e antes de processá-la, o serviço marca o estado da recomendação como CLAIMED. Depois que a recomendação é aplicada com sucesso, o serviço consulta o banco de dados para recuperar os IDs de recomendação que foram aplicados com êxito pelo job do Cloud Build e altera o estado da recomendação para SUCCEEDED. Se o job do Cloud Build falhar, o estado da recomendação será alterado para FAILED.

Controle de acesso: consulte os papéis do Firestore para mais detalhes. O serviço do analisador do recomendador lê dados do Firestore e precisa do papel roles/datastore.user para fazer isso.

Pub/Sub

Propósito: o Cloud Build publica mensagens em um tópico do Pub/Sub quando o estado da versão é alterado, como quando a versão é criada, quando a versão é transferida para um estado de trabalho e quando a versão é concluída.

O tópico do Pub/Sub no qual o Cloud Build publica mensagens é chamado de cloud-builds. Ele é criado automaticamente quando você ativa a API Cloud Build no projeto.

Controle de acesso: as assinaturas de push podem ser configuradas para fornecer um cabeçalho de autenticação para permitir que o serviço autorize a solicitação. Consulte Como usar assinaturas de push para mais detalhes.

Objetivos

• Criar um pipeline de automação para
  • Monitorar proativamente as recomendações do Policy Intelligence da plataforma
  • Analisar recomendações e aplicar atualizações a um repositório de IaC existente
• Saiba como usar um conjunto de serviços do Google Cloud, Hashicorp Terraform e GitHub para criar esse pipeline.
• Entenda as suposições e as práticas recomendadas que você precisa ter em mente para criar esse pipeline
• Testar o pipeline

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• Cloud Run
• Cloud Build
• Compute Engine
• Cloud Storage
• Firestore
• Pub/Sub
• Cloud Scheduler
• Recommender

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Antes de começar

Neste tutorial, presume-se que você tenha uma conta do GitHub e esteja familiarizado com Git, Node.js, Terraform e Docker

Notas de lançamento e suposições

O funcionamento de ferramentas e manifestos da IaC tem muita variabilidade.

Consulte as informações a seguir para determinar como este tutorial pode se adequar ao seu pipeline de IaC e quais tipos de alteração podem ser necessários.

• Esse pipeline usa o Terraform versão 0.12. Alterações significativas na sintaxe de configuração da HCL ou alterações na estrutura do arquivo de estado do Terraform podem apresentar problemas de interrupção.
• Para este pipeline, presume-se que as estruturas de diretório de IaC não estejam aninhadas e que um repositório de IaC gerencie recursos em um ou mais projetos do Google Cloud.
• As variáveis do Terraform são transmitidas como variáveis de ambiente e os argumentos da linha de comando não são compatíveis. O protótipo pressupõe a configuração declarativa das variáveis do Terraform em um arquivo tfvars.
• O Recommender gera recomendações do IAM quando um subconjunto de permissões para um papel não é usado por 60 dias e as recomendações de dimensionamento de VM seguem um padrão semelhante. Para a finalidade deste tutorial, foram fornecidos payloads de recomendação de amostra que podem ser usados para testar o pipeline.
• Esta versão não é compatível com loops no Terraform
• Os módulos do Terraform não são compatíveis. A base do código é aberta e pressupõe-se que você realizará melhorias específicas necessárias no fluxo de análise para se adequar à estrutura de diretório e ao uso de módulos.

A versão atual do serviço do analisador do recomendador de código aberto está alinhada às seguintes limitações conhecidas das recomendações do IAM:

• Só é possível fazer recomendações para vinculações de política do IAM que sejam:
  • no nível do projeto;
  • associadas a contas de usuários e contas de serviço gerenciadas pelos usuários;
• As recomendações do IAM são compatíveis apenas com papéis básicos e predefinidos. Papéis personalizados e vinculações condicionais não podem ser avaliados ou recomendados.
• Os papéis recomendados contêm apenas um subconjunto das permissões do papel atual. Nenhuma nova permissão é introduzida por um papel recomendado.

Pré-requisitos

1. Selecione ou crie dois projetos do Google Cloud.

   Acessar a página do seletor de projetos

   • Um projeto de versão que hospeda e executa o pipeline de automação.
   • Um projeto de teste que hospeda recursos do Google Cloud usados para testar o pipeline de automação.

2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

3. No projeto de teste, ative a API Recommender e o Compute Engine.

   Enable the APIs

4. No projeto de versão, ative as APIs Cloud Run, Firestore, Pub/Sub e Cloud Scheduler, IAM e CloudResourceManager.

   Enable the APIs

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Veja mais detalhes em Como fazer a limpeza.

configure o ambiente

1. No console do Google Cloud, selecione seu projeto build.

2. No console do Google Cloud, acesse o Cloud Shell.

   Acesse o Cloud Shell

   Na parte debaixo do console do Google Cloud, uma sessão do Cloud Shell é aberta e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a Google Cloud CLI já instalada e com valores já definidos para seu projeto atual. A inicialização da sessão pode levar alguns segundos.

   Use o Cloud Shell para todos os comandos do terminal neste tutorial.

3. Crie uma variável de ambiente para manter o número do projeto build usando o comando abaixo:

   export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
   

4. Crie uma variável de ambiente para manter o número do seu projeto test. Copie o ID do projeto de teste manualmente e substitua PROJECT-ID por ele.

   export TEST_PROJECT_ID=PROJECT-ID
   

5. Atribua configurações padrão aos valores usados em todo o tutorial, como região e zona. Neste tutorial, us-central1 é usada como região padrão e us-central1-b como zona padrão.

6. Defina a região e a zona padrão deste tutorial executando o seguinte comando:

   gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID
   gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID
   

7. Defina seu projeto build como o projeto padrão:

   gcloud config set project $BUILD_PROJECT_ID
   

8. Crie uma variável de ambiente chamada BUILD_PROJECT_NUMBER para o número do projeto build

   export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
   

9. Clone o repositório do GitHub para este tutorial:

   Observação: execute todos os comandos deste tutorial no Cloud Shell, a menos que especificado o contrário.

Crie um bucket para o estado do Terraform

Crie um bucket do Cloud Storage no projeto de criação para armazenar o arquivo de estado do Terraform.

gcloud storage buckets create gs://recommender-tf-state-$BUILD_PROJECT_ID \
  --project=${BUILD_PROJECT_ID} --location=us-central1

Crie um repositório do GitHub

Crie um repositório do GitHub para servir de exemplo de repositório de IaC

1. Crie um novo repositório particular do GitHub. Este repositório do IAC-REPO-NAME funciona como seu repositório de IaC para a finalidade deste tutorial

2. Nas próximas etapas, você enviará os arquivos no subdiretório sample-iac do repositório clonado para sua conta do GitHub.

   1. No Cloud Shell, copie o diretório sample-iac para seu diretório principal. Você usará esse diretório para criar um novo repositório local e enviá-lo para o GitHub.

      cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
      

   2. Navegue até o novo diretório

      cd $HOME/sample-iac
      

   3. Inicialize o repositório na sua máquina local.

      git init
      

   4. Adicione IAC-REPO-NAME como o repositório remoto, substituindo IAC-REPO-NAME e GITHUB-ACCOUNT pelos valores apropriados

      git remote add origin https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME
      

   5. Substitua os marcadores nos arquivos neste repositório pelo ID do projeto test e pelo nome do bucket do Cloud Storage do Terraform.

      sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./terraform.tfvars
      
      sed -i "s|__STATE_BUCKET_NAME__|recommender-tf-state-$BUILD_PROJECT_ID|g" ./backend.tf
      

   6. Adicione, confirme e envie para o GitHub.

      git add .
      git commit -m "First Commit"
      git push origin master
      

   7. Faça login na sua conta do GitHub quando solicitado.

Gere chaves SSH para o repositório

Configure a autenticação de chave SSH com seu repositório de IaC no GitHub e faça upload das chaves no Cloud Storage.

1. Gere chaves SSH para seu repositório do GitHub.

   1. Gere um par de chaves SSH. Substitua [e-mail] pelo seu endereço de e-mail do GitHub. No Cloud Shell, faça o seguinte:

      ssh-keygen -t rsa -b 4096 -m PEM -C "[e-mail]"
      

   2. Quando for solicitado a "Inserir um arquivo em que a chave seja salva", pressione Enter. Isso aceita o local padrão do arquivo.

   3. No prompt para inserir uma senha longa, pressione Enter.

2. Anote o diretório SSH-KEYS-DIR em que você colocou as chaves SSH salvas. Por padrão, o local é $HOME/.ssh/

3. Copie a chave pública SSH que você gerou para o repositório do GitHub como uma Chave de implantação.

   1. Copie a chave pública SSH que você gerou no Cloud Shell. Substitua SSH-KEYS-DIR pelo caminho do diretório.

      cat SSH-KEYS-DIR/id_rsa.pub
      

   2. Na sua conta do GitHub, navegue até o repositório IAC-REPO-NAME

   3. Clique em Configurações > Implantar chaves.

   4. Clique em adicionar chave de implantação e cole a chave pública SSH que você copiou. Escolha um Título para a chave.

   5. Marque a caixa de seleção "Permitir acesso de gravação"

   6. Clique em Salvar.

4. Volte para a sessão do Cloud Shell

5. Crie o arquivo known_hosts para o GitHub. Na sessão do Cloud Shell, execute o comando:

   ssh-keyscan github.com >> ~/.ssh/known_hosts
   

6. Crie um bucket do Cloud Storage no projeto build e faça upload das chaves SSH e do arquivo known_hosts para ele. Substitua SSH-KEYS-DIR pelo caminho para o diretório em que você gerou as chaves SSH.

   gcloud storage buckets create gs://github-keys-$BUILD_PROJECT_ID --project=${BUILD_PROJECT_ID} --location=us-central1
   
   gcloud storage cp SSH-KEYS-DIR/id_rsa* gs://github-keys-$BUILD_PROJECT_ID
   gcloud storage cp SSH-KEYS-DIR/known_hosts gs://github-keys-$BUILD_PROJECT_ID
   

7. Gere um token de acesso pessoal para o GitHub. Esse token é usado ao executar operações do Git que utilizam chamadas de API que o serviço do analisador do recomendador realiza para gerar solicitações de envio e manifestos de IaC atualizados.

   1. Na sua conta do GitHub, no canto superior direito de qualquer página, clique na sua foto de perfil e depois em Configurações.

   2. Na barra lateral esquerda, clique em Configurações do desenvolvedor.

   3. Na barra lateral esquerda, clique em Tokens de acesso pessoal

   4. Clique em "Gerar novo token".

   5. Dê ao token um nome descritivo.

   6. Selecione os escopos como repo.

   7. Clique em Gerar token.

   8. Copie o token para a área de transferência.

   9. Na sessão do Cloud Shell, crie uma variável de ambiente.

      export GITHUB_PAT=personal-access-token-you-copied
      

Configurar o Cloud Build

1. Conecte seu repositório Git IAC-REPO-NAME para se integrar ao Cloud Build.

   1. Acesse a página do aplicativo Cloud Build no GitHub Marketplace.
   2. Role para baixo e clique em Configuração com o Google Cloud Build na parte inferior da página.
   3. Se solicitado, faça login no GitHub.
   4. Selecione Somente repositórios selecionados. Use a lista suspensa Selecionar repositórios para ativar apenas o acesso ao IAC-REPO-NAME no aplicativo Cloud Build.
   5. Clique em Instalar.

   6. Faça login no Google Cloud.

      A página "Autorização" é exibida onde você precisa autorizar o aplicativo Google Cloud Build para se conectar ao Google Cloud.

   7. Clique em Authorize Google Cloud Build by GoogleCloudBuild. Você será redirecionado para o Console do Google Cloud.

   8. Selecione seu projeto do Google Cloud.

   9. Ative a caixa de seleção de consentimento e clique em Avançar.

   10. Na página Selecionar repositório exibida, selecione o repo IAC-REPO-NAME do GitHub.

   11. Clique em Conectar repositório.

   12. Clique em Criar um gatilho. Isso criará uma definição de gatilho para você.

   13. Clique em Criar para salvar o gatilho de compilação.

   Para mais informações, consulte Como executar versões no GitHub.

2. O diretório que você copiou tem um arquivo cloudbuild.yaml. Este arquivo de configuração descreve as etapas que um job do Cloud Build executa quando acionado.

   steps:
   - name: hashicorp/terraform:0.12.0
     args: ['init']
   - name: hashicorp/terraform:0.12.0
     args: ['apply', '-auto-approve']
   

3. Adicionar permissões à sua conta de serviço do Cloud Build para permitir que ela crie contas de serviço, associe papéis e máquinas virtuais (instâncias do Compute Engine) no projeto de teste

   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/compute.admin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/iam.serviceAccountAdmin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
   --member serviceAccount:$[e-mail] \
   --role roles/iam.securityAdmin \
   --project $TEST_PROJECT_ID
   

4. Abra a página "Gatilhos de compilação" no console do Google Cloud.

5. Selecione o projeto build e clique em Abrir.

6. Atualize a definição do gatilho:

   1. Clique no menu e em Editar.
   2. Em Configuração, selecione a opção Arquivo de configuração do Cloud Build (yaml ou json) e digite cloudbuild.yaml no campo de texto.
   3. Clique em Salvar.

7. Para testar manualmente o gatilho de compilação, clique em Executar na entrada do gatilho na lista.

8. Verifique se uma instância do Compute Engine chamada tf-compute-1 e uma conta de serviço chamada Terraform Recommender Test foram criadas no seu projeto de teste pelo job do Cloud Build executado na etapa anterior

Observação: aguarde alguns instantes para que o job do Cloud Build seja concluído antes de verificar a criação de recursos no seu projeto de teste.

Implante o serviço do analisador do recomendador do Cloud Run

1. No Cloud Shell, altere os diretórios para o diretório criado clonando o repositório

   cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
   

2. Configure o Google Cloud para usar uma região padrão nos serviços do Cloud Run. Neste tutorial, use a região us-central1, mas também é possível escolher uma região compatível diferente, se preferir.

   gcloud config set run/region us-central1
   

3. O diretório parser-service tem um subdiretório de stub com alguns JSONs de payload de amostra para você testar o serviço do analisador do recomendador. Execute os seguintes comandos sed para substituir os marcadores PROJECT_ID nesses JSONs pelo ID do projeto de teste.

   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/iam.json
   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/vm.json
   

4. Execute o seguinte comando para criar uma variável de ambiente para a imagem do Docker.

   export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
   

5. Crie a imagem e faça o upload para o Container Registry.

   gcloud builds submit --tag $IMAGE .
   

6. Crie uma conta de serviço para que o serviço do analisador do recomendador interaja com outros serviços do Google Cloud no pipeline. É uma boa prática conceder permissões granulares aos serviços do Cloud Run. Para mais detalhes, consulte a identidade do serviço do Cloud Run.

   gcloud beta iam service-accounts create recommender-parser-sa \
     --description "Service account that the recommender-parser service uses to invoke other Google Cloud services" \
     --display-name "recommender-parser-sa" \
     --project $BUILD_PROJECT_ID
   

7. O serviço do analisador do recomendador precisa acessar as chaves SSH do GitHub e o estado do Terraform que você enviou para os buckets do Cloud Storage criados anteriormente. Adicione a conta de serviço como um membro ao bucket do Cloud Storage.

   gcloud storage buckets add-iam-policy-binding gs://github-keys-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   
   gcloud storage buckets add-iam-policy-binding gs://recommender-tf-state-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   

8. Conceda à conta de serviço do analisador do recomendador o acesso ao Firestore, ao Recommender e à API Service Usage.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/datastore.user
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamViewer
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.computeAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/serviceusage.serviceUsageConsumer
   

9. Para implantar o serviço do Cloud Run, chamado recommender-parser, execute o comando. Substitua GITHUB-ACCOUNT pelo nome de usuário da sua conta do GitHub, e não por e-mail. Aceite todas as solicitações do sistema.

   gcloud run deploy \
    --image=${IMAGE} \
    --no-allow-unauthenticated \
    --region us-central1 \
    --platform managed \
    --service-account recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --set-env-vars="GITHUB_ACCOUNT=github.com:GITHUB-ACCOUNT,GITHUB_PAT=${GITHUB_PAT},SSH_KEYS_BUCKET=github-keys-${BUILD_PROJECT_ID},TERRAFORM_STATE_BUCKET=recommender-tf-state-$BUILD_PROJECT_ID" \
    --project $BUILD_PROJECT_ID \
    recommender-parser
   

Configurar o Firestore

1. No Console do Google Cloud, em seu projeto build, navegue até a página Firestore.
2. Quando a seleção do modo for solicitada, clique em Selecionar modo nativo.
3. Selecione us-east1 como o local padrão.
4. Clique em Criar banco de dados.

O serviço recommender-parser grava documentos nesta banco de dados para as seguintes finalidades:

• Para acompanhar as recomendações recuperadas da API Recommender
• Chame a API Recommender depois que as recomendações forem processadas para atualizar o status de cada recomendação processada para SUCCEEDED ou FAILED, conforme apropriado. Essa é uma etapa importante que torna o pipeline idempotente, garantindo que as recomendações não sejam processadas de maneira incompleta ou várias vezes.

Configurar um job do Cloud Scheduler

1. Crie uma conta de serviço que os jobs do Cloud Scheduler usem para executar o serviço do analisador do recomendador.

   gcloud beta iam service-accounts create recommender-scheduler-sa \
     --description "Service Account used by Cloud Scheduler to invoke the recommender-parser service" \
     --display-name "recommender-scheduler-sa" \
     --project $BUILD_PROJECT_ID
   

2. Dê o papel de execução/invoker da conta de serviço para invocar o serviço do Cloud Run.

   gcloud beta run services add-iam-policy-binding recommender-parser \
   --member=serviceAccount:recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/run.invoker \
   --region=us-central1
   

3. Receba o URL do serviço do recomendador:

   gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
   

   O job do Cloud Scheduler invoca a rota /recommendation/iam do serviço do analisador do recomendador para analisar as recomendações do IAM e a rota /recommender/vm para analisar as recomendações de dimensionamento da VM.

4. Crie uma variável para o endpoint invocado pelos jobs do Cloud Scheduler. Substitua RECOMMENDER-SERVICE-URL pelo URL do serviço do recomendador que você copiou na etapa anterior.

   export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam
   

   O URL será parecido com esta amostra de URL depois da anexação das informações da rota:

   RECOMMENDER-SERVICE-URL/recommendation/iam
   

5. Crie um job do Cloud Scheduler chamado recommender-iam-scheduler.

   • Altere o fuso horário selecionado com base no seu local.
   • Substitua IAC-REPO-NAME pelo nome do repositório do GitHub que você criou.

   O corpo da mensagem recebe três entradas, e você precisa construí-la conforme descrito abaixo:

   • repo: é o nome do repositório IAC-REPO-NAME do GitHub que você criou em Criar um repositório do GitHub.

   • projects: uma lista/matriz de IDs de projetos do Google Cloud para o qual esse repositório do IaC do GitHub será mapeado. Neste tutorial, este é seu projeto test.

   • stub: o recomendador gera recomendações do IAM quando um subconjunto de permissões para um papel não é usado por 60 dias e quando recomendações de dimensionamento da VM seguem um padrão semelhante. Para testar esse pipeline sob demanda, stub pode ser transmitido como true para que o pipeline seja testado usando os payloads do recomendador de amostra fornecidos no repositório que você clonou para este tutorial.

   gcloud beta scheduler jobs create http recommender-iam-scheduler \
     --project $BUILD_PROJECT_ID \
     --time-zone "America/Los_Angeles" \
     --schedule="0 */3 * * *" \
     --uri=$RECOMMENDER_ROUTE_TO_INVOKE_IAM \
     --description="Scheduler job to invoke recommendation pipeline" \
     --oidc-service-account-email="recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com" \
     --headers="Content-Type=application/json" \
     --http-method="POST" \
     --message-body="{ \"repo\": \"IAC-REPO-NAME\", \"projects\": [\"$TEST_PROJECT_ID\"], \"location\": \"global\", \"stub\": true }"
   

Observação: --schedule="0 */3 * * *" executa o job do Scheduler a cada três horas. Altere-o de acordo com seus requisitos. Além disso, se você precisar criar um job do programador para analisar as recomendações de dimensionamento de VM, anexe o URL de serviço your-recommender-parser com /recommendation/vm e defina o atributo location na --message-body para uma zona válida.

Etapas adicionais

O Cloud Build publica informações de versão em um tópico do Pub/Sub chamado cloud-builds que foi criado automaticamente quando você ativou a API Cloud Build no seu projeto de versão.

1. Execute o seguinte comando para verificar se o tópico do cloud-builds existe no seu projeto build:

   gcloud pubsub topics describe cloud-builds
   

   Se o tópico existir, você verá a saída a seguir, em que BUILD-PROJECT-ID é o ID do projeto do build:

   name: projects/BUILD-PROJECT-ID/topics/cloud-builds
   

   Se você receber uma mensagem de erro informando que o recurso não foi encontrado, siga as instruções para inscrever-se para criar notificações e criar o tópico manualmente.

2. Crie uma conta de serviço que o Pub/Sub possa usa para invocar o endpoint de serviço do analisador do recomendador.

   gcloud beta iam service-accounts create recommender-ci-subscription-sa \
     --description "Service Account used by Cloud Pub/Sub to push Cloud Build events to the recommender-parser service" \
     --display-name "recommender-ci-subscription-sa" \
     --project $BUILD_PROJECT_ID
   

3. A conta de serviço do Pub/Sub precisa estar associada aos papéis necessários para publicar mensagens e invocar o serviço do analisador do recomendador.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.publisher \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.subscriber \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/run.invoker \
     --project $BUILD_PROJECT_ID
   

4. Adicione a conta de serviço recommender-ci-subscription-sa criada para o serviço do analisador do recomendador como membro usando o papel invoker

   gcloud beta run services add-iam-policy-binding recommender-parser \
     --member=serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/run.invoker --region=us-central1
   

5. Navegue até o Pub/Sub no Console do Google Cloud.

6. Clique no tópico cloud-builds.

7. Clique em Criar assinatura.

8. Para o ID da assinatura, digite recommender-service-build-events.

9. Em Tipo de entrega, selecione Push.

10. Em Endpoint, digite o URL do serviço do recomendador anexado por /ci.

11. Marque Ativar autenticação.

    1. Selecione a conta de serviço recommender-ci-subscription-sa criada.
    2. Clique em Conceder em resposta à mensagem de solicitação.

12. Selecione Prazo de confirmação como 60 segundos.

13. Mantenha os demais padrões.

14. Clique em Criar.

Testar o pipeline

O recomendador gera recomendações do IAM quando um subconjunto de permissões de um papel não é usado por 60 dias. As recomendações de dimensionamento da VM seguem um padrão semelhante. Para testar esse pipeline sob demanda, use os payloads de amostra de recomendação JSON fornecidos no subdiretório stub no repositório clonado para este tutorial. Com isso, é possível testar o pipeline excluindo as chamadas de API que o analisador do recomendador realiza no endpoint da API Recommender para atualizar o status de recomendações que foram aplicadas com sucesso.

Como alternativa, se você tem recomendações ativas nos seus projetos do Google Cloud, é possível testar o pipeline de ponta a ponta sem precisar usar stubs. O resultado descrito abaixo é pertinente quando você está usando os payloads de amostra para testar o pipeline. No entanto, as etapas para testar esse pipeline sem amostras permanecem as mesmas.

1. No console do Google Cloud, navegue até o projeto de teste e analise o recurso que foi criado. Você precisa ter o seguinte:

   1. Uma instância do Compute Engine chamada tf-compute-1 com o tipo de máquina g1-small.
   2. Uma conta de serviço chamada Terraform Recommender Test com o papel de editor para seu projeto de teste.

2. Na página do console do Cloud Scheduler no projeto build, clique em Executar agora para o job recommender-iam-scheduler.

3. Clique no job para ver os registros. É possível também ver os registros do serviço do analisador do recomendador para ter uma visão detalhada das etapas que estão sendo executadas pelo serviço.

4. Quando a execução do serviço for concluída, navegue até o repositório IAC-REPO-NAME do GitHub. O serviço recommender-parser pode ter gerado uma solicitação de envio para você. Revise os manifestos de IaC modificados que compõem essa solicitação de envio e clique em Mesclar solicitação de envio, se você estiver satisfeito com as alterações nos manifestos de IaC.

   Aviso: em ambientes de produção, recomendamos que você aplique um fluxo de trabalho de aprovação robusto que inclua a revisão humana das solicitações de envio antes que as alterações sejam mescladas. Os revisores precisam ter o conhecimento para avaliar os impactos identificados nas recomendações, bem como os impactos específicos da sua infraestrutura e dos seus negócios. A aplicação de recomendações sem avaliação adequada pode resultar em alterações inesperadas, como problemas com o desempenho do sistema, baixa confiabilidade ou perda das permissões necessárias. Consulte a documentação do GitHub para ver instruções sobre como configurar um processo de análise.

5. Uma nova confirmação para a ramificação mestre é criada quando a solicitação de envio é mesclada. Isso aciona um job do Cloud Build que implanta as modificações nos recursos do Google Cloud no projeto test. Aguarde alguns minutos para que o job do Cloud Build seja concluído. Analise o status dele no console do Google Cloud

   Observação: garantir uma estratégia de reversão funcional é uma prática recomendada durante a configuração do pipeline do DevOps. Por exemplo, as alterações de infraestrutura lançadas pelo pipeline de automação criado neste tutorial podem ser revertidas por meio da reversão de uma confirmação Git anterior. Saiba mais sobre os comandos https://git-scm.com/docs/git-reset e git revert nesta documentação do Git.

6. Quando o job for concluído, navegue até o projeto de teste. Os payloads de amostra fornecidos têm as seguintes alterações nos recursos no projeto de teste.

   • A conta de serviço de teste do Terraform, que anteriormente tinha o papel de editor ao ser implantada, foi alterada para viewer.
   Observação: quando você executa o serviço do Cloud Scheduler para invocar a análise de recomendações de dimensionamento da VM no endpoint /recommendation/vm, a instância do Compute Engine tf-compute-1, que originalmente tinha o tipo de máquina g1-small, será alterada para f1-micro.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua ambos os projetos que foram criados.

O jeito mais fácil de evitar cobranças é excluir o projeto que você criou para o tutorial.

Para excluir o projeto:

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

A seguir

• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.
• Saiba mais sobre o Google Cloud Policy Intelligence na documentação.