Usar recomendações para infraestrutura como código

---

Vista geral

A Google Cloud Policy Intelligence ajuda as empresas a compreender e gerir as respetivas políticas para reduzir o risco. Ao oferecer mais visibilidade e automatização, os clientes podem aumentar a segurança sem aumentar a carga de trabalho.

O Recommender permite-lhe obter recomendações para Google Cloud recursos, o que ajuda a melhorar a segurança na nuvem, poupar custos e muito mais. Para ver uma lista de recomendações suportadas, consulte a documentação do motor de recomendações. Este tutorial descreve a utilização de recomendações de dimensionamento para instâncias de VM e recomendações de gestão de identidade e acesso (IAM). O Serviço de Recomendação usa a aprendizagem automática para fornecer aos administradores recomendações para remover o acesso desnecessário a Google Cloud recursos e redimensionar Google Cloud as instâncias do Compute Engine para uma utilização mais eficiente dos recursos.

Cada recomendação inclui uma ação sugerida e o respetivo impacto. Depois de rever as recomendações para os impactos identificados, bem como outras considerações específicas do seu ambiente, pode selecionar as recomendações que quer aplicar. Pode aplicar recomendações manualmente a partir da Google Cloud consola ou aplicá-las de forma programática integrando-as no seu pipeline de infraestrutura como código (IaC).

A IaC permite-lhe automatizar a criação dos seus Google Cloud recursos.Tem de manter o seu repositório de IaC atualizado e encaminhar as alterações feitas à Google Cloud organização através dele. Geralmente, as estratégias de IaC nas organizações revelam-se benéficas quando são implementadas com rigor e servem como a única versão da verdade para a sua infraestrutura na nuvem. Manter o repositório de IaC atualizado é fundamental para evitar desvios entre a versão da sua infraestrutura que o repositório de IaC reflete e o que tem na organização.

Recomendações de IAM

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

Recomendação de dimensionamento para VMs

As recomendações de dimensionamento ajudam a reduzir os custos através de sugestões para redimensionar o tipo de máquina das suas instâncias de modo a usar os recursos das instâncias de forma mais eficiente

Este tutorial descreve como arquitetar e criar um pipeline de automatização para aplicar um programa de recomendações de informações sobre políticas de forma programática. Como parte deste pipeline de automatização, vai saber como manter o seu repositório de IaC atualizado com as alterações que decide fazer à sua Google Cloud organização, com base no dimensionamento das VMs e na recomendação de associações de políticas de IAM que o Recomendador disponibiliza.

Este tutorial usa o Hashicorp Terraform como ferramenta IaC. No entanto, os padrões arquitetónicos e os componentes usados no pipeline de automatização descrito podem ser usados mesmo que esteja a usar uma ferramenta de gestão de IaC diferente, como o Deployment Manager. Tem de modificar a base de código de código aberto disponibilizada com este tutorial para se adequar à sua implementação específica de IaC.

Este guia destina-se a arquitetos, proprietários de produtos e programadores que possam ser responsáveis pela administração, segurança e planeamento da infraestrutura do respetivoGoogle Cloud.

Arquitetura do pipeline de automatização

O diagrama seguinte mostra os componentes que usa nesta pipeline de automatização.

Uma tarefa agendada do Cloud Scheduler executa o serviço Recommender Parser. O serviço chama a API Recommender para obter recomendações do Recommender para os projetos que especificar. Em seguida, analisa estas recomendações de dimensionamento de VMs e IAM para as mapear para a configuração que tem nos seus manifestos do Terraform. O serviço atualiza os seus manifestos de IaC para refletir estas recomendações. Gera um pedido de obtenção com as alterações para que possa rever as atualizações. Depois de rever e unir o pedido de envio, uma tarefa do Cloud Build implementa as alterações à sua infraestrutura na sua organização doGoogle Cloud .

São usados vários serviços Google Cloud auxiliares no pipeline para fins de acompanhamento das recomendações processadas, geração de notificações sobre a conclusão da compilação e armazenamento do estado do Terraform. Vai saber mais sobre estes serviços ao longo deste tutorial.

A lista seguinte descreve a finalidade dos componentes e os requisitos de controlo de acesso:

Recomendadores de inteligência da plataforma

Finalidade: gerar recomendações de segurança e dimensionamento de VMs

Controlo de acesso: a Google Cloud conta de serviço tem de ter as autorizações de IAM necessárias para obter recomendações através da API Recommender.

Reveja as funções e as autorizações do Recommender para selecionar a função mais adequada aplicável à conta de serviço que usa para executar o serviço recommender-parser.

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

Cloud Scheduler

Finalidade: o Cloud Scheduler aciona o serviço do analisador do Recommender. O Cloud Scheduler permite-lhe configurar várias tarefas que invocam tantas instâncias do serviço de análise quanto precisar. Cada invocação tem de transmitir as seguintes entradas

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

Nota: é recomendável configurar várias tarefas do programador se tiver mais do que um repositório de IaC na sua empresa. Geralmente, este é um padrão comum em grandes empresas.

Controlo de acesso: crie ou identifique uma Google Cloud conta de serviço a usar para as chamadas do Cloud Scheduler para o seu serviço Recommender Parser.

Conceda à conta de serviço a função de agente do serviço Cloud Scheduler para que possa executar tarefas do Cloud Scheduler. Além disso, conceda à conta de serviço a função de invocador do Cloud Run, uma vez que essa conta invoca um serviço do Cloud Run

Consulte a documentação sobre a configuração do acesso autenticado para tarefas do programador para ver detalhes.

Serviço do Cloud Run

Finalidade:: o serviço de análise sintática de recomendações é onde reside toda a lógica de processamento. Tem várias rotas, cada uma com um objetivo específico:

• Analisar recomendações para cada tipo de recomendação.
• Atualizar o estado das recomendações que estão a ser processadas

Controlo de acesso: use o IAM para gerir o acesso a este serviço

Além disso, atribua o serviço a uma conta de serviço dedicada. Isto garante que apenas o serviço pode invocar outros serviços, como o Firestore.

Hashicorp Terraform

Finalidade: o Terraform 0.12 é a ferramenta IaC.

É usado um criador do Cloud Build para o Terraform para invocar comandos do Terraform, e a conta de serviço do Cloud Build é usada para esse fim.

Cloud Build

Finalidade: o Google Cloud Build automatiza a implementação de infraestrutura com base nas alterações feitas aos manifestos de IaC de acordo com as recomendações de inteligência de políticas.

Controlo de acesso: a conta de serviço do Cloud Build tem de ter o conjunto certo de autorizações para interagir com os recursos no seu projeto de teste.

Consulte a documentação para configurar uma conta de serviço do Cloud Build.

GitHub

Finalidade: o repositório de IaC usa o GitHub para o controlo de origem. O repositório de IaC no GitHub está integrado com o Cloud Build. Quando são feitos commits no ramo principal, é acionado um trabalho do Cloud Build para executar um conjunto de tarefas pré-configuradas.

Controlo de acesso: tem de gerar chaves SSH para ativar o acesso ao seu repositório de IaC.

Além disso, tem de gerar um token de acesso pessoal para enviar commits para o GitHub.

Nota: são necessárias chaves SSH e um token de acesso pessoal quando interage com repositórios privados alojados no GitHub. Se o seu repositório for público (não recomendado), este passo não se aplica a si.

Firestore

O Firestore é uma base de dados de documentos NoSQL totalmente gerida e escalável que é usada nesta arquitetura para persistir informações relacionadas com os IDs de recomendações analisados pelo serviço Recommender Parser, juntamente com os detalhes correspondentes pertinentes para os commits do Git.

Os detalhes persistentes no Firestore desempenham um papel integral no ciclo de feedback que faz parte do pipeline completo. Depois de receber uma recomendação gerada pela API Recommender e antes de processar a recomendação, o serviço marca o estado da recomendação como CLAIMED. Depois de a recomendação ser aplicada com êxito, o serviço consulta a base de dados para obter os IDs das recomendações que foram aplicadas com êxito pela tarefa do Cloud Build e altera o estado da recomendação para SUCCEEDED. Se a tarefa do Cloud Build falhar, o estado da recomendação é alterado para FAILED.

Controlo de acesso: consulte as funções do Firestore para ver detalhes. O serviço recommender-parser lê dados do Firestore e precisa da função roles/datastore.user para o fazer.

Pub/Sub

Finalidade: o Cloud Build publica mensagens num tópico do Pub/Sub quando o estado da sua compilação muda, como quando a compilação é criada, quando a compilação passa para um estado de funcionamento e quando a compilação é concluída.

O tópico do Pub/Sub para o qual o Cloud Build publica mensagens chama-se cloud-builds e é criado automaticamente para si quando ativa a API Cloud Build no seu projeto.

Controlo de acesso: as subscrições push podem ser configuradas para fornecer um cabeçalho de autenticação para permitir que o serviço autorize o pedido. Consulte o artigo Usar subscrições push para ver mais detalhes.

Objetivos

• Crie um pipeline de automatização para
  • Monitorize proativamente as recomendações da inteligência das políticas da plataforma
  • Analisar recomendações e aplicar atualizações a um repositório de IaC existente
• Saiba como pode usar um conjunto de Google Cloud serviços, Hashicorp Terraform e GitHub para criar este pipeline.
• Compreenda as pressuposições e as práticas recomendadas que tem de ter em atenção para criar este pipeline
• Teste o pipeline

Custos

Neste documento, usa 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 custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Antes de começar

Este tutorial pressupõe que tem uma conta do GitHub e que conhece o Git, Node.js, Terraform e o Docker.

Notas de lançamento e pressupostos

Existe muita variabilidade na forma como os manifestos e as ferramentas de IaC são usados.

Reveja as seguintes informações para determinar como este tutorial se pode adequar ao seu pipeline de IaC e que tipos de alterações podem ser necessários.

• Esta pipeline usa o Terraform ver. 0.12. As alterações significativas na sintaxe de configuração do HCL ou as alterações à estrutura do ficheiro de estado do Terraform podem introduzir problemas de interrupção.
• Esta conduta pressupõe que as estruturas de diretórios da IaC não estão aninhadas e que um repositório de IaC gere recursos num ou mais Google Cloud projetos.
• As variáveis do Terraform transmitidas como variáveis de ambiente ou argumentos da linha de comandos não são suportadas. O protótipo pressupõe a configuração declarativa de variáveis do Terraform num ficheiro tfvars.
• O Recommender gera recomendações de IAM quando um subconjunto de permissões para uma função não é usado há 60 dias e as recomendações de dimensionamento de VMs seguem um padrão semelhante. Para os fins deste tutorial, foram fornecidos payloads de recomendações de exemplo que podem ser usados para testar o pipeline.
• Os ciclos no Terraform não são suportados nesta versão
• Os módulos do Terraform não são suportados. A base de código é de código aberto e assume-se que vai fazer as melhorias específicas necessárias ao fluxo de análise para se adequar à estrutura do diretório e à utilização de módulos.

A versão atual do serviço de análise de recomendações de código aberto está alinhada com as seguintes limitações conhecidas das recomendações da IAM:

• As recomendações só podem ser feitas para associações de políticas IAM que sejam:
  • Ao nível do projeto
  • Associado a contas de utilizador e contas de serviço geridas pelo utilizador
• As recomendações de IAM suportam apenas funções básicas e funções predefinidas. Não é possível avaliar nem recomendar funções personalizadas e associações condicionais.
• As funções recomendadas contêm apenas um subconjunto das autorizações da função atual. Não são introduzidas novas autorizações por uma função recomendada.

Pré-requisitos

1. Selecione ou crie dois Google Cloud projetos.

   Aceda à página do seletor de projetos

   • Um projeto de compilação que aloja e executa o pipeline de automatização.
   • Um projeto de teste que aloja Google Cloud recursos usados para testar o pipeline de automatização.

2. Verify that billing is enabled for your Google Cloud project.

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

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the APIs

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

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the APIs

Quando terminar este tutorial, pode evitar a faturação contínua eliminando os recursos que criou. Consulte a secção Limpar para ver mais detalhes.

Configure o seu ambiente

1. Na Google Cloud consola, selecione o projeto do build.

2. Na Google Cloud consola, aceda ao Cloud Shell.

   Aceda ao Cloud Shell

   Na parte inferior da Google Cloud consola, é aberta uma sessão do Cloud Shell e é apresentado um comando. O Cloud Shell é um ambiente de shell com a CLI do Google Cloud já instalada e com valores já definidos para o seu projeto atual. A sessão pode demorar alguns segundos a ser inicializada.

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

3. Crie uma variável de ambiente para guardar o número do projeto do seu projeto build através do comando abaixo:

   export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
   

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

   export TEST_PROJECT_ID=PROJECT-ID

5. Atribui definições predefinidas para valores que são usados ao longo do tutorial, como região e zona. Neste tutorial, usa us-central1 como região predefinida e us-central1-b como zona predefinida.

6. Defina a região e a zona predefinidas para este 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 o seu projeto do build como o projeto predefinido:

   gcloud config set project $BUILD_PROJECT_ID
   

8. Crie uma variável de ambiente denominadaBUILD_PROJECT_NUMBER para obuildnúmero do projeto

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

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

   Nota: execute todos os comandos neste tutorial no Cloud Shell, salvo indicação em contrário.

Crie um contentor para o estado do Terraform

Crie um contentor do Cloud Storage no seu projeto de compilação para armazenar o ficheiro 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 como repositório de IaC de exemplo

1. Crie um novo repositório privado do GitHub. Este repositório IAC-REPO-NAME serve como repositório de IaC para os fins deste tutorial

2. Nos passos seguintes, vai enviar os ficheiros no subdiretório sample-iac do repositório clonado para a sua conta do GitHub.

   1. No Cloud Shell, copie o diretório sample-iac para o seu diretório pessoal. Vai usar este 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 para 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, substitua IAC-REPO-NAME e GITHUB-ACCOUNT por valores adequados

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

   5. Substitua os marcadores de posição nos ficheiros deste repositório pelotestID do projeto e o nome do contentor do Google 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. Inicie sessão na sua conta do GitHub quando lhe for solicitado.

Gere chaves SSH para o seu repositório

Configure a autenticação de chaves SSH com o seu repositório de IaC no GitHub e carregue as chaves para o Cloud Storage.

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

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

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

   2. Quando lhe for pedido que "Introduza um ficheiro no qual guardar a chave", prima Enter. Esta opção aceita a localização predefinida do ficheiro.

   3. No comando para introduzir uma frase secreta, prima Enter.

2. Tome nota do diretório SSH-KEYS-DIR no qual guarda as chaves SSH transferidas. Por predefinição, a localização é$HOME/.ssh/

3. Copie a chave pública de SSH que gerou para o seu repositório do GitHub como uma chave de implementação.

   1. Copie a chave pública de SSH que 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 para o IAC-REPO-NAME repositório

   3. Clique em Definições > Chaves de implementação.

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

   5. Selecione a caixa de verificação "Permitir acesso de escrita"

   6. Clique em Guardar.

4. Navegue novamente para a sessão do Cloud Shell

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

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

6. Crie um contentor do Cloud Storage no seu projetobuild e carregue as suas chaves SSH e o ficheiroknown_hosts para o mesmo. Substitua SSH-KEYS-DIR pelo caminho para o diretório onde 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. Este token é usado quando executa operações Git através de chamadas API que o serviço recommender-parser faz para gerar pedidos de obtenção, validar manifestos de IaC atualizados.

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

   2. Na barra lateral esquerda, clique em Definições do programador.

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

   4. Clique em Gerar novo token.

   5. Atribua um nome descritivo ao token.

   6. Selecione os âmbitos 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

Configure o Cloud Build

1. Associe o seu repositório Git IAC-REPO-NAME para integrar com o Cloud Build.

   1. Aceda à página da app Cloud Build no GitHub Marketplace.
   2. Desloque a página para baixo e clique em Configurar com o Google Cloud Build na parte inferior da página.
   3. Se lhe for pedido, inicie sessão no GitHub.
   4. Selecione Selecionar apenas repositórios. Use a lista pendente Selecionar repositórios para ativar apenas o acesso ao seu IAC-REPO-NAME na app Cloud Build.
   5. Clique em Instalar.

   6. Inicie sessão em Google Cloud.

      É apresentada a página de autorização, onde lhe é pedido que autorize a app Google Cloud Build a estabelecer ligação a Google Cloud.

   7. Clique em Autorizar o Google Cloud Build por GoogleCloudBuild. É redirecionado para a consola Google Cloud .

   8. Selecione o seu projeto do Google Cloud .

   9. Ative a caixa de verificação de consentimento e clique em Seguinte.

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

   11. Clique em Associar repositório.

   12. Clique em Criar um acionador. Esta ação cria uma definição de acionador para si.

   13. Clique em Criar para guardar o acionador de compilação.

   Para mais informações, consulte o artigo Executar compilações no GitHub.

2. O diretório que copiou tem um ficheiro cloudbuild.yaml. Este ficheiro de configuração descreve os passos que uma tarefa do Cloud Build executa quando é acionada.

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

3. Adicione autorizações à sua conta de serviço do Cloud Build para lhe permitir criar contas de serviço, associar funções 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 Build Triggers na Google Cloud consola.

5. Selecione o projeto build e clique em Abrir.

6. Atualize a definição do acionador:

   1. Clique no menu e, de seguida, em Editar.
   2. Para Configuração, selecione a opção Ficheiro de configuração do Cloud Build (yaml ou json) e introduza cloudbuild.yaml no campo de texto.
   3. Clique em Guardar.

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

8. Verifique se uma instância do Compute Engine denominada tf-compute-1 e uma conta de serviço denominada Terraform Recommender Test foram criadas no seu projeto de teste pela tarefa do Cloud Build que executou no passo anterior

Nota: pode ter de aguardar alguns momentos até que a tarefa do Cloud Build seja concluída antes de verificar a criação de recursos no seu projeto de teste.

Implemente o serviço do Cloud Run recommender-parser

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

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

2. Configure Google Cloud para usar uma região predefinida para os serviços do Cloud Run. Neste tutorial, usa a região us-central1, mas pode escolher uma região suportada diferente, se preferir.

   gcloud config set run/region us-central1
   

3. O diretório parser-servicetem um subdiretório de teste com alguns JSONs de payload de exemplo para testar o serviço recommender-parser. Execute os seguintes comandos sed para substituir os marcadores de posição PROJECT_ID nestes ficheiros JSON pelo ID do seu 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 sua imagem do Docker.

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

5. Crie a imagem e carregue-a para o Container Registry

   gcloud builds submit --tag $IMAGE .
   

6. Crie uma conta de serviço para o serviço recommender-parser interagir com outros serviços no pipeline. Google Cloud É uma boa prática conceder autorizações detalhadas aos seus serviços do Cloud Run. Consulte o artigo Identidade do serviço do Cloud Run para ver mais detalhes.

   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 recommender-parser precisa de aceder às chaves SSH do GitHub e ao estado do Terraform que carregou para os contentores do Cloud Storage criados anteriormente. Adicione a conta de serviço como membro ao contentor 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 serviço recommender-parser 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. Implemente o serviço do Cloud Run, denominado recommender-parser, executando o comando. Substitua GITHUB-ACCOUNT pelo nome de utilizador da sua conta do GitHub e não pelo email. Aceite todos os comandos 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

Configure o Firestore

1. Na Google Cloud consola, no projeto build, navegue para a página do Firestore.
2. Quando lhe for pedido que selecione um modo, clique em Selecionar modo nativo.
3. Selecioneus-east1 como a localização predefinida.
4. Clique em Criar base de dados.

O serviçorecommender-parser escreve documentos nesta base de dados para os seguintes fins:

• Para acompanhar as recomendações que obteve da Recommender API
• Chame a API Recommender assim que as recomendações forem processadas para atualizar o estado de cada recomendação processada para SUCCEEDED ou FAILED, conforme apropriado. Este é um passo fundamental que torna o pipeline idempotente, garantindo que as recomendações não são processadas de forma incompleta nem várias vezes.

Configure uma tarefa do Cloud Scheduler

1. Crie uma conta de serviço que as tarefas do Cloud Scheduler usam para executar o serviço recommender-parser.

   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. Atribua à conta de serviço a função de execução/invocador para poder 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. Obtenha o URL do serviço de recomendações:

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

   A tarefa do Cloud Scheduler invoca a rota /recommendation/iam do serviço recommender-parser para analisar as recomendações do IAM e a rota /recommender/vm para analisar as recomendações de dimensionamento de VMs.

4. Crie uma variável para o ponto final que as tarefas do Cloud Scheduler invocam. Substitua RECOMMENDER-SERVICE-URL pelo URL do serviço de recomendações que copiou no passo anterior.

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

   O URL deve ter o seguinte aspeto após anexar as informações do trajeto:

   RECOMMENDER-SERVICE-URL/recommendation/iam
   

5. Crie uma tarefa do Cloud Scheduler denominada recommender-iam-scheduler.

   • Altere o fuso horário selecionado com base na sua localização.
   • Substitua IAC-REPO-NAME pelo nome do repositório do GitHub que criou.

   O corpo da mensagem requer três entradas e tem de o construir conforme descrito abaixo:

   • repo: Este é o nome do seu repositório do GitHub IAC-REPO-NAME que criou em Crie um repositório do GitHub.

   • projects: Uma lista / matriz de IDs de projetos aos quais este repositório do GitHub de IaC está mapeado. Google Cloud Neste tutorial, é o seu projeto test.

   • stub: o Recommender gera recomendações de IAM quando um subconjunto de autorizações para uma função não é usado durante 60 dias e as recomendações de dimensionamento de VMs seguem um padrão semelhante. Para fins de teste desta conduta a pedido, pode transmitir stub como true para que a conduta seja testada com os payloads de exemplo do Recommender fornecidos no repositório que 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 }"

Nota: o --schedule="0 */3 * * *" executa a tarefa do Scheduler a cada 3 horas. Altere-o de acordo com o seu requisito. Além disso, se precisar de criar uma tarefa do programador para analisar as recomendações de dimensionamento de VMs, deve acrescentar o URL do serviço your-recommender-parser com /recommendation/vm e definir o atributo location no parâmetro --message-body para uma zona válida.

Passos adicionais

O Cloud Build publica informações de compilação num tópico do Pub/Sub denominado cloud-builds que foi criado automaticamente quando ativou a API Cloud Build no seu projeto de compilação.

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

   gcloud pubsub topics describe cloud-builds
   

   Se o tópico existir, é apresentada a seguinte saída, em que BUILD-PROJECT-ID é o ID do projeto de compilação:

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

   Se receber uma mensagem de erro a indicar que o recurso não foi encontrado, siga as instruções para subscrever notificações de compilação e criar o tópico manualmente.

2. Crie uma conta de serviço que o Pub/Sub usa para invocar o ponto final do serviço recommender-parser.

   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 deve estar associada às funções de que precisa para poder publicar mensagens e invocar o serviço recommender-parser.

   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 recommender-ci-subscription-saconta de serviço que criou ao serviço recommender-parser como membro com a função 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 para Pub/Sub na Google Cloud consola.

6. Clique no tópico cloud-builds.

7. Clique em Criar subscrição.

8. Para o ID da subscrição, introduza recommender-service-build-events.

9. Para Tipo de fornecimento, selecione Push.

10. Para Ponto final, introduza o URL do serviço de recomendações anexado por /ci.

11. Selecione Ativar autenticação.

    1. Selecione a conta de serviço recommender-ci-subscription-saque criou.
    2. Clique em Conceder em resposta à mensagem de comando.

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

13. Manter as restantes predefinições.

14. Clique em Criar.

Teste o pipeline

O Recomendador gera recomendações de IAM quando um subconjunto de autorizações para uma função não é usado durante 60 dias. As recomendações de dimensionamento de VMs seguem um padrão semelhante. Para efeitos de teste desta pipeline a pedido, vai usar os payloads JSON de recomendações de exemplo fornecidos no subdiretório stub fornecido no repositório que clonou para este tutorial. Isto permite-lhe testar o pipeline, exceto as chamadas API que o analisador de recomendações faz ao ponto final da API Recommender para atualizar o estado das recomendações que aplicou com êxito.

Em alternativa, se tiver recomendações ativas nos seus Google Cloud projetos, pode testar o pipeline integralmente sem ter de usar stubs. O resultado descrito abaixo é pertinente quando usa os payloads de exemplo para testar o pipeline. No entanto, os passos para testar este pipeline sem exemplos permanecem inalterados.

1. Na Google Cloud consola, navegue para o projeto de teste e reveja os recursos que foram criados. Deve ter o seguinte:

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

2. Na página da consola do Cloud Scheduler no seu projeto build, clique em Executar agora para a tarefa recommender-iam-scheduler.

3. Clique na tarefa para ver os registos. Também pode ver os registos do serviço recommender-parser para ter uma vista detalhada dos passos que estão a ser executados pelo serviço.

4. Quando o serviço concluir a execução, navegue para o seu repositório do GitHub IAC-REPO-NAME. O serviço recommender-parser teria gerado um pedido de obtenção para si. Reveja os manifestos de IaC modificados que constituem este pedido de envio e clique em Unir pedido de envio se estiver satisfeito com as alterações aos seus manifestos de IaC.

   Aviso: em ambientes de produção, recomendamos que aplique um fluxo de trabalho de aprovação robusto que inclua a revisão humana de pedidos de obtenção antes de as alterações serem unidas. Os revisores devem ter os conhecimentos necessários para avaliar os impactos identificados nas recomendações, bem como os impactos específicos da sua infraestrutura e empresa. A aplicação de recomendações sem uma avaliação adequada pode resultar em alterações inesperadas, como problemas com o desempenho do sistema, fiabilidade fraca ou perda de autorizações necessárias. Consulte a documentação do GitHub para obter instruções sobre como configurar um processo de revisão.

5. Quando junta o pedido de envio, é criado um novo commit no ramo principal. Isto aciona uma tarefa do Cloud Build que implementa as modificações nos Google Cloud recursos no seu projeto test. Aguarde alguns momentos para que a tarefa do Cloud Build seja concluída. Pode rever o respetivo estado na consola do Google Cloud

   Nota: certificar-se de que tem uma estratégia de reversão funcional implementada é uma prática recomendada quando configura os seus pipelines de DevOps. Por exemplo, as alterações à infraestrutura implementadas pelo pipeline de automatização que criou neste tutorial podem ser revertidas para um commit anterior do Git. Pode saber mais acerca dos comandos https://git-scm.com/docs/git-reset e git revert nesta documentação do Git.

6. Quando a tarefa estiver concluída, navegue para o projeto de teste. As cargas úteis de exemplo fornecidas fazem as seguintes alterações aos recursos no seu projeto de teste.

   • A conta de serviço de teste do Terraform, que tinha anteriormente a função de editor quando implementada, é alterada para viewer.
   Nota: quando executa o serviço Cloud Scheduler para invocar recomendações de redimensionamento de VMs no ponto final /recommendation/vm, a instância do Compute Engine tf-compute-1, que originalmente tem um tipo de máquina de g1-small, é alterada para f1-micro.

Limpar

Para evitar incorrer em custos na sua Google Cloud conta pelos recursos usados neste tutorial, elimine ambos os projetos que criou.

A forma mais fácil de eliminar a faturação é eliminar o projeto que criou para o tutorial.

Para eliminar o projeto:

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

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.

O que se segue?

• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.
• Saiba mais acerca da Google Cloud inteligência de políticas na documentação.