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.
- 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
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.
- 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 paraSUCCEEDED
. Se o job do Cloud Build falhar, o estado da recomendação será alterado paraFAILED
.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.
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
- 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.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
- No projeto de teste, ative a API Recommender e o Compute Engine.
- No projeto de versão, ative as APIs Cloud Run, Firestore,
Pub/Sub e Cloud Scheduler, IAM e
CloudResourceManager.
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
- No console do Google Cloud, selecione seu projeto
build
. No console do Google Cloud, 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.
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
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
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.
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
Defina seu projeto
build
como o projeto padrão:gcloud config set project $BUILD_PROJECT_ID
Crie uma variável de ambiente chamada
BUILD_PROJECT_NUMBER
para o número do projetobuild
export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
Clone o repositório do GitHub para este tutorial:
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
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
Nas próximas etapas, você enviará os arquivos no subdiretório
sample-iac
do repositório clonado para sua conta do GitHub.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
Navegue até o novo diretório
cd $HOME/sample-iac
Inicialize o repositório na sua máquina local.
git init
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
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
Adicione, confirme e envie para o GitHub.
git add . git commit -m "First Commit" git push origin master
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.
Gere chaves SSH para seu repositório do GitHub.
Gere um par de chaves SSH. Substitua [email protected] 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 "[email protected]"
Quando for solicitado a "Inserir um arquivo em que a chave seja salva", pressione Enter. Isso aceita o local padrão do arquivo.
No prompt para inserir uma senha longa, pressione Enter.
Anote o diretório SSH-KEYS-DIR em que você colocou as chaves SSH salvas. Por padrão, o local é
$HOME/.ssh/
Copie a chave pública SSH que você gerou para o repositório do GitHub como uma Chave de implantação.
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
Na sua conta do GitHub, navegue até o repositório IAC-REPO-NAME
Clique em Configurações > Implantar chaves.
Clique em adicionar chave de implantação e cole a chave pública SSH que você copiou. Escolha um Título para a chave.
Marque a caixa de seleção "Permitir acesso de gravação"
Clique em Salvar.
Volte para a sessão do Cloud Shell
Crie o arquivo
known_hosts
para o GitHub. Na sessão do Cloud Shell, execute o comando:ssh-keyscan github.com >> ~/.ssh/known_hosts
Crie um bucket do Cloud Storage no projeto
build
e faça upload das chaves SSH e do arquivoknown_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
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.
Na sua conta do GitHub, no canto superior direito de qualquer página, clique na sua foto de perfil e depois em Configurações.
Na barra lateral esquerda, clique em Configurações do desenvolvedor.
Na barra lateral esquerda, clique em Tokens de acesso pessoal
Clique em "Gerar novo token".
Dê ao token um nome descritivo.
Selecione os escopos como repo.
Clique em Gerar token.
Copie o token para a área de transferência.
Na sessão do Cloud Shell, crie uma variável de ambiente.
export GITHUB_PAT=personal-access-token-you-copied
Configurar o Cloud Build
Conecte seu repositório Git IAC-REPO-NAME para se integrar ao Cloud Build.
- Acesse a página do aplicativo Cloud Build no GitHub Marketplace.
- Role para baixo e clique em Configuração com o Google Cloud Build na parte inferior da página.
- Se solicitado, faça login no GitHub.
- 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.
- Clique em Instalar.
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.
Clique em Authorize Google Cloud Build by GoogleCloudBuild. Você será redirecionado para o Console do Google Cloud.
Selecione seu projeto do Google Cloud.
Ative a caixa de seleção de consentimento e clique em Avançar.
Na página Selecionar repositório exibida, selecione o repo IAC-REPO-NAME do GitHub.
Clique em Conectar repositório.
Clique em Criar um gatilho. Isso criará uma definição de gatilho para você.
Clique em Criar para salvar o gatilho de compilação.
Para mais informações, consulte Como executar versões no GitHub.
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']
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:[email protected] \ --role roles/compute.admin \ --project $TEST_PROJECT_ID gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \ --member serviceAccount:[email protected] \ --role roles/iam.serviceAccountAdmin \ --project $TEST_PROJECT_ID gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \ --member serviceAccount:[email protected] \ --role roles/iam.securityAdmin \ --project $TEST_PROJECT_ID
Abra a página "Gatilhos de compilação" no console do Google Cloud.
Selecione o projeto
build
e clique em Abrir.Atualize a definição do gatilho:
- Clique no menu e em Editar.
- 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. - Clique em Salvar.
Para testar manualmente o gatilho de compilação, clique em Executar na entrada do gatilho na lista.
Verifique se uma instância do Compute Engine chamada
tf-compute-1
e uma conta de serviço chamadaTerraform Recommender Test
foram criadas no seu projeto de teste pelo job do Cloud Build executado na etapa anterior
Implante o serviço do analisador do recomendador do Cloud Run
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
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
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
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
Crie a imagem e faça o upload para o Container Registry.
gcloud builds submit --tag $IMAGE .
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
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
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
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
- No Console do Google Cloud, em seu projeto
build
, navegue até a página Firestore. - Quando a seleção do modo for solicitada, clique em Selecionar modo nativo.
- Selecione
us-east1
como o local padrão. - 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
ouFAILED
, 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
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
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
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.
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
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 projetotest
.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 comotrue
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 }"
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.
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.
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
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
Adicione a conta de serviço
recommender-ci-subscription-sa
criada para o serviço do analisador do recomendador como membro usando o papelinvoker
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
Navegue até o Pub/Sub no Console do Google Cloud.
Clique no tópico cloud-builds.
Clique em Criar assinatura.
Para o ID da assinatura, digite
recommender-service-build-events
.Em Tipo de entrega, selecione Push.
Em Endpoint, digite o URL do serviço do recomendador anexado por
/ci
.Marque Ativar autenticação.
- Selecione a conta de serviço
recommender-ci-subscription-sa
criada. - Clique em Conceder em resposta à mensagem de solicitação.
- Selecione a conta de serviço
Selecione Prazo de confirmação como 60 segundos.
Mantenha os demais padrões.
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.
No console do Google Cloud, navegue até o projeto de teste e analise o recurso que foi criado. Você precisa ter o seguinte:
- Uma instância do Compute Engine chamada
tf-compute-1
com o tipo de máquinag1-small
. - Uma conta de serviço chamada
Terraform Recommender Test
com o papel deeditor
para seu projeto de teste.
- Uma instância do Compute Engine chamada
Na página do console do Cloud Scheduler no projeto
build
, clique em Executar agora para o job recommender-iam-scheduler.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.
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.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 CloudQuando 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 paraviewer
.
- A conta de serviço de teste do Terraform, que anteriormente tinha o papel de
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:
- No Console do Google Cloud, acesse a página Gerenciar recursos.
- Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
- Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.
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.