Este documento faz parte de uma série sobre os padrões de arquitetura que as empresas podem usar para otimizar o alcance da nuvem em escala usando o Active Assist. Neste tutorial, mostramos como criar um pipeline de automação para recomendações do Active Assist que funciona com o conjunto de ferramentas do GKE Enterprise. Ele é destinado a pessoas que usam o Config Management para gerenciar os ambientes do GKE Enterprise e o Config Connector para gerenciar os recursos do Google Cloud. As outras partes da série são as seguintes:
- Padrões para usar o Active Assist em grande escala
- Como usar pipelines sem servidor com o Active Assist
- Como usar o conjunto de ferramentas do GKE Enterprise com o Active Assist (este documento)
O pipeline de automação criado neste tutorial pode ajudar você a conseguir o seguinte:
- Como escalonar o uso do portfólio do Active Assist na sua organização.
- Transformar o Active Assist em parte de um pipeline de integração e entrega contínuas (CI/CD).
- Controlar a análise e a atuação das recomendações do Active Assist usando criações como problemas do GitHub e solicitações de envio.
Neste tutorial, também usamos o kpt, um kit de ferramentas de código aberto desenvolvido pelo Google para ajudar a gerenciar, manipular, personalizar e aplicar arquivos de dados de configuração de recursos do Kubernetes.
Arquitetura
O diagrama de arquitetura a seguir mostra os componentes que serão usados neste tutorial.
Os componentes são usados das seguintes maneiras:
- Um repositório do GitHub não se repete (DRY, na sigla em inglês), e é usado para modelos do Config Connector que você implanta em projetos da organização do Google Cloud.
- Um ou mais repositórios do GitHub específicos para um projeto ou ambiente e que têm arquivos de configuração hidratados. Esses repositórios hidratados são destinados aos ambientes que são gerenciados pelo Config Sync. Eles usam o Config Connector para ativar e gerenciar os recursos do Google Cloud na organização.
- Um cluster do GKE que usa o Config Sync para controle de versões e detecção de desvio. Esse cluster também tem o Config Connector instalado. O Config Connector permite que o cluster gerencie os recursos do Google Cloud na organização.
- Um gatilho do Cloud Build que aciona uma versão quando um modelo é enviado por push para o repositório DRY do GitHub.
- Um gatilho programado do Cloud Build que aciona um build periodicamente; O job de compilação usa uma função kpt. A função invoca as APIs do Active Assist Recommender para buscar recomendações ativas. Ele revisa e analisa recomendações para determinar se os recursos do Google Cloud que o Config Connector gerencia precisam ser redimensionados ou otimizados. A função kpt cria um problema do GitHub no repositório DRY com os detalhes da alteração recomendada se os recursos do Google Cloud gerenciados pelo Config Connector precisarem ser redimensionados ou otimizados.
O fluxo de trabalho dessa arquitetura é o seguinte:
- As equipes autorizadas com acesso ao repositório DRY criam e gerenciam modelos do Config Connector no repositório.
- Um job do Cloud Build é acionado quando um modelo é criado ou modificado e verificado na ramificação
main
. - O job do Cloud Build hidrata os modelos invocando os setters kpt. O job envia os arquivos de configuração hidratados para o repositório hidratado do GitHub. O Secret Manager é usado para armazenar chaves de implantação do GitHub para o repositório particular.
- O Config Sync monitora alterações no repositório hidratado e aplica atualizações encontradas no repositório ao cluster gerenciado.
- O Config Connector monitora alterações e ativa recursos do Google Cloud se algum recurso precisar ser criado ou atualizado como resultado das alterações do Kubernetes Resource Model (KRM) aplicadas pelo Config Sync.
- Um gatilho programado do Cloud Build é executado periodicamente para invocar a API Recommender para buscar recomendações ativas para os projetos que o Config Connector gerenciou.
- O job programado do Cloud Build executa uma função kpt personalizada para invocar a API Recommender e buscar e analisar recomendações ativas.
- A função kpt cria um problema no GitHub que mostra uma comparação da configuração atual do recurso e da configuração recomendada para o recurso. Com essa abordagem, os problemas do GitHub são criados no repositório DRY, o que facilita o acompanhamento das alterações no repositório.
Objetivos
- Crie os seguintes repositórios de amostra do GitHub:
- Um repositório DRY para o Config Connector KRMs.
- Um repositório para armazenar arquivos de configuração hidratados gerados com setters kpt.
- Criar um cluster do GKE com o Config Sync e o Config Connector.
- Crie uma função kpt de amostra para recuperar recomendações do Active Assist para projetos gerenciados pelo Config Connector.
- Crie um gatilho do Cloud Build que será acionado quando um modelo for enviado para a ramificação
main
do repositório DRY. - Criar um job programado do Cloud Build que seja executado periodicamente para recuperar recomendações do Active Assist disponíveis para os recursos gerenciados pelo Config Connector.
- Teste o pipeline completo com as recomendações de stub fornecidas no repositório do GitHub para este tutorial.
Custos
Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:
- Cloud Build
- Cloud Run
- Firestore
- Pub/Sub
- Container Registry
- Cloud Scheduler
- Google Kubernetes Engine (GKE) Enterprise Edition
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.
Antes de começar
-
In the Google Cloud console, go to the project selector page.
-
Select or create a Google Cloud project.
- Anote o ID do projeto do Google Cloud. Você usará esse ID na próxima seção ao configurar o ambiente. Este projeto é chamado em todo o tutorial como o projeto
build
. -
Enable the Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Scheduler e Cloud Source Repositories APIs.
Você usará as credenciais padrão do aplicativo para este tutorial. Se for solicitado que você crie credenciais na página Adicionar credenciais ao seu projeto, clique em Cancelar. -
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
Como configurar o ambiente
Neste tutorial, todos os comandos serão executados no Cloud Shell.
In the Google Cloud console, activate Cloud Shell.
Defina variáveis para o ID e o número do projeto
build
atual do Google Cloud:export RECO_MGR_PROJECT=PROJECT_ID gcloud config set project $RECO_MGR_PROJECT export RECO_MGR_PROJECT_NUMBER=$(gcloud projects describe $RECO_MGR_PROJECT --format='value(projectNumber)')
Substitua
PROJECT_ID
pelo ID do projeto que você anotou na seção anterior.Defina as variáveis da região de implantação:
export REGION=us-central1 export ZONE=us-central1-a
Clone o repositório que contém o código do aplicativo de amostra usado neste tutorial:
git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
Acesse o diretório do projeto:
cd activeassist-anthos-toolchain
Criar o pipeline
Nesta seção, você cria os componentes para criar o pipeline. As recomendações do Active Assist são geradas com base em padrões de uso e métricas do sistema. Cada categoria de recomendação pode usar uma janela de tempo padrão diferente para analisar os dados de uso e as métricas com base nas recomendações geradas. Para testar o pipeline completo, o repositório clonado em uma etapa anterior fornece recomendações de exemplo (stubs) que você usa para executar o pipeline completo.
Como alternativa, se você estiver executando o pipeline em um projeto de amostra que tenha recursos e recomendações atuais, faça as alterações apropriadas no código de amostra e execute o pipeline.
Configurar amostras de repositórios particulares do GitHub
Nas seções a seguir, você irá configurar os repositórios do GitHub de amostra para este tutorial.
Configurar um repositório privado do GitHub do DRY
Crie um repositório particular do GitHub para o repositório DRY. Anote o nome do repositório.
No Cloud Shell, crie uma variável de ambiente para o nome de usuário do GitHub e o nome do repositório DRY:
export REPO_OWNER=YOUR_GITHUB_USERNAME export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
Substitua:
YOUR_GITHUB_USERNAME
: seu nome de usuário do GitHub.YOUR_PRIVATE_DRY_REPO
: o nome do repositório DRY.
Crie um token de acesso pessoal (PAT, na sigla em inglês) para gerar problemas neste repositório. O pipeline cria problemas do GitHub se há recomendações do Active Assist que precisam ser revisadas. Para mais informações sobre como criar PATs no GitHub, consulte a documentação do GitHub.
Ao definir um escopo para esse token, selecione Controle total de repositórios particulares.
No Cloud Shell, crie uma variável de ambiente para o PAT que você gerou:
export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
Substitua
YOUR_PERSONAL_ACCESS_TOKEN
pelo seu próprio token.
Configurar um repositório particular hidratado do GitHub
Crie um repositório particular do GitHub para o repositório hidratado. Anote o nome do repositório.
No Cloud Shell, defina uma variável de ambiente para o repositório hidratado:
export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO export HYDRATED_REPO='git@github.com:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
Substitua
YOUR_PRIVATE_HYDRATED_REPO
pelo nome do seu repositório hidratado.Crie um par de chaves de implantação:
ssh-keygen -t rsa -b 4096 \ -C 'active-assist-robot' \ -N '' \ -f $(pwd)/active-assist-robot
Uma chave de implantação permite implantar no repositório particular do GitHub ao executar um job do Cloud Build para hidratar arquivos de configuração.
Imprima a chave gerada:
cat $(pwd)/active-assist-robot.pub
Adicione a chave de implantação ao repositório particular do GitHub. Selecione Permitir acesso de gravação ao adicionar a chave de implantação. Para saber como adicionar chaves de implantação a repositórios do GitHub, consulte a documentação do GitHub sobre Como gerenciar chaves de implantação.
Faça upload das chaves do GitHub para o Secret Manager
No Cloud Shell, crie um secret para armazenar a chave privada do par de chaves de implantação:
gcloud secrets create github-ssh-key \ --data-file=$(pwd)/active-assist-robot
Crie um secret para armazenar o PAT:
echo $GITHUB_TOKEN | gcloud secrets create github-pat --data-file=-
Criar um cluster do GKE
Nesta seção, você cria um cluster do GKE com o complemento do Config Connector, cria uma identidade e configura o Config Connector. Você também configura o Config Sync. É possível usar o Config Sync para criar uma configuração comum em toda a infraestrutura, incluindo políticas personalizadas, e aplicá-la no local e na nuvem. O Config Sync avalia alterações e as distribui para todos os clusters do Kubernetes, sempre refletindo o estado esperado nos clusters.
No Cloud Shell, crie um novo cluster do GKE com o complemento Config Connector ativado:
gcloud container clusters create sample-ops \ --machine-type n1-standard-4 \ --zone $ZONE \ --release-channel regular \ --addons ConfigConnector \ --workload-pool=$RECO_MGR_PROJECT.svc.id.goog \ --enable-stackdriver-kubernetes \ --enable-ip-alias
Conclua as seções a seguir no guia Como instalar com o complemento GKE para criar uma identidade e configurar o Config Connector.
Instale o Config Sync no cluster do GKE que você criou. Ao configurar o Config Sync, faça o seguinte:
- Use um
token
para
conceder acesso somente leitura ao Config Sync ao Git.
Use o token do GitHub que você
Criou quando você configura um repositório privado do DRY no GitHub.
O token está disponível por meio da variável de ambiente
$GITHUB_TOKEN
. - Configurar o Config Sync usando gcloud.
Defina as seguintes configurações:
- sourceFormat:
hierarchy
- syncRepo:
https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
- syncBranch:
main
- secretType:
token
- policyDir: não preencha essa opção
- sourceFormat:
- Use um
token
para
conceder acesso somente leitura ao Config Sync ao Git.
Use o token do GitHub que você
Criou quando você configura um repositório privado do DRY no GitHub.
O token está disponível por meio da variável de ambiente
Crie um gatilho do Cloud Build para enviar ao repositório hidratado
Nas seções a seguir, você vai criar um gatilho do Cloud Build que será
acionado quando os modelos forem enviados para a ramificação principal do seu repositório
YOUR_PRIVATE_DRY_REPO
. Este gatilho executa as etapas que hidratam os modelos de KRM de configuração como dados
no repositório YOUR_PRIVATE_DRY_REPO
e envia os arquivos de configuração hidratados para seu repositório
YOUR_PRIVATE_HYDRATED_REPO
.
Conectar o Cloud Build aos repositórios GitHub.
Nesta seção, você
conecta
os repositórios YOUR_PRIVATE_DRY_REPO
e YOUR_PRIVATE_HYDRATED_REPO
do GitHub ao Cloud Build.
Acesse a página do Marketplace do GitHub para o aplicativo Cloud Build:
Clique em Configurar com o Google Cloud Build.
Se solicitado, faça login no GitHub.
Selecione Somente repositórios selecionados.
Use a lista suspensa Selecionar repositórios para ativar o acesso aos repositórios
YOUR_PRIVATE_DRY_REPO
eYOUR_PRIVATE_HYDRATED_REPO
por meio do aplicativo Cloud Build.Clique em Install.
Faça login no Google Cloud. A página Autorização é exibida e 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.
Selecione a caixa de seleção de consentimento e clique em Avançar.
Clique em Install.
Faça login no Google Cloud. A página Autorização é exibida e 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.
Selecione a caixa de seleção de consentimento e clique em Avançar.
Na página Selecionar repositório exibida, selecione os seguintes repositórios do GitHub:
YOUR_PRIVATE_DRY_REPO
YOUR_PRIVATE_HYDRATED_REPO
Clique em Conectar e em Concluído.
Crie um gatilho do Cloud Build para o repositório DRY
No Cloud Shell, execute o seguinte comando:
envsubst < cloudbuild.template.yaml > cloudbuild.yaml
O comando gera um arquivo
cloudbuild.yaml
.Crie o gatilho:
gcloud beta builds triggers create github \ --name ActiveAssistDemo \ --repo-name=$DRY_REPO_NAME \ --repo-owner=$REPO_OWNER \ --branch-pattern="main" \ --build-config=cloudbuild.yaml
Conceda permissão à conta de serviço do Cloud Build para acessar o Secret Manager:
gcloud secrets add-iam-policy-binding github-ssh-key \ --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/secretmanager.secretAccessor" gcloud secrets add-iam-policy-binding github-pat \ --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/secretmanager.secretAccessor"
Criar um gatilho programado do Cloud Build para recomendações do Active Assist
Nas seções a seguir, você cria um gatilho programado do Cloud Build que é executado periodicamente. Esse gatilho busca recomendações do Active Assist
usando uma função kpt e determina se há recomendações
ativas para os recursos no
repositório
YOUR_PRIVATE_HYDRATED_REPO
. A função kpt também cria um problema do GitHub no
seu repositório YOUR_PRIVATE_HYDRATED_REPO
.
Se houver recomendações ativas para a configuração de recursos que
precisam ser analisadas e acionadas.
Gerar uma imagem do Cloud Build
Nesta seção, você gera uma imagem do Cloud Build que tem componentes kpt, gh e nós.
No Cloud Shell, crie e envie uma imagem do Docker para o Container Registry:
gcloud auth configure-docker docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
Crie um gatilho do Cloud Build para seu repositório hidratado
No Cloud Shell, crie o arquivo de configuração necessário para configurar o gatilho programado do Cloud Build:
envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
Crie o gatilho do Cloud Build:
gcloud beta builds triggers create github \ --name ActiveAssistScheduledRecommendations \ --repo-name=YOUR_PRIVATE_HYDRATED_REPO \ --repo-owner=$REPO_OWNER \ --branch-pattern="main" \ --build-config=cloudbuild-scheduled-recommendations.yaml
Consiga o ID deste gatilho:
export TRIGGER_ID=`gcloud beta builds triggers describe \ ActiveAssistScheduledRecommendations \ --format="value(id)"`
Criar um job do Cloud Scheduler para invocar o gatilho
No Cloud Shell, crie uma conta de serviço:
gcloud iam service-accounts create build-invoker \ --description "Service Account used by Cloud Scheduler to invoke the sample scheduled Cloud Build job" \ --display-name "recommender-scheduler-sa" \ --project $RECO_MGR_PROJECT
Os jobs do Cloud Scheduler usam essa conta de serviço para executar o serviço
recommender-parser
.Conceda as permissões à conta de serviço para invocar um job do Cloud Build:
gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \ --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \ --role roles/cloudbuild.builds.editor \ --project $RECO_MGR_PROJECT gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \ --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \ --role roles/serviceusage.serviceUsageConsumer \ --project $RECO_MGR_PROJECT
Crie um job do Cloud Scheduler para invocar o gatilho criado na etapa anterior:
gcloud scheduler jobs create http scheduled-build \ --project $RECO_MGR_PROJECT \ --time-zone "America/Los_Angeles" \ --schedule="0 */3 * * *" \ --uri="https://cloudbuild.googleapis.com/v1/projects/${RECO_MGR_PROJECT}/triggers/${TRIGGER_ID}:run" \ --description="Scheduler job to invoke Cloud Build" \ --oauth-service-account-email="build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com" \ --headers="Content-Type=application/json" \ --http-method="POST" \
Selecione
Y
se aparecer a seguinte mensagem:There is no App Engine app in the project.
Se for solicitado que você escolha a região em que quer armazenar o aplicativo do App Engine, selecione a região
us-central
.
Confirmar e enviar os arquivos de configuração do Cloud Build para o GitHub
Envie os dois arquivos de configuração do Cloud Build que você criou para seu
repositório
YOUR_PRIVATE_DRY_REPO
:
git remote add dry https://github.com/$REPO_OWNER/$DRY_REPO_NAME.git
git add cloudbuild.yaml
git add cloudbuild-scheduled-recommendations.yaml
git commit -m "Added cloudbuild configuration YAMLs"
git push dry main
Talvez seja necessário inserir suas credenciais do GitHub quando você as envia para o repositório particular.
Analisar o resultado do job do Cloud Build
Quando você confirma e envia alterações para o repositório YOUR_PRIVATE_DRY_REPO
, o job do Cloud Build é acionado. Se o job do Cloud Build for executado com êxito, vários recursos serão criados. Nesta seção, você verifica se os recursos foram criados após a conclusão do job do Cloud Build.
No Cloud Shell, no cluster
sample-ops
, valide se você tem um namespace chamadoactiveassist-kcc
:kubectl get ns | grep activeassist-kcc
O Config Connector implanta uma instância de amostra do Compute Engine em execução no projeto
PROJECT_ID
.Valide se a instância do Compute Engine está no projeto:
gcloud compute instances list | grep \ computeinstance-sample-cloudmachine
O tipo
MACHINE_TYPE
dessa máquina én1-standard-1
.
Executar testes completos
Para permitir que você teste o pipeline completo, o repositório que você clonou para este tutorial fornece recomendações de exemplo (stubs). Você usa esses stubs para executar o pipeline completo. O stub imita um payload de recomendação do Active Assist
e tem uma recomendação para alterar o tipo de máquina para
a instância do Compute Engine implantada no tipo de instância n1-standard-1
para o tipo de instância g1-small
. de dados.
Nesta seção, você invocará o gatilho programado do Cloud Build
manualmente para executar o job que usa uma função kpt para buscar
recomendações do Active Assist. Você também verifica se um problema do GitHub
foi criado no
repositório YOUR_PRIVATE_DRY_REPO
.
Abra a página Gatilhos de compilação no console do Google Cloud.
Selecione o gatilho
ActiveAssistScheduledRecommendations
.Para testar manualmente o gatilho, clique em Executar na entrada do seu gatilho na lista de gatilhos.
O gatilho cria um problema do GitHub no seu repositório
YOUR_PRIVATE_DRY_REPO
. O problema é similar a:gcloud auth configure-docker docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
No problema de amostra, a saída da função kpt mostra que o tipo
MACHINE_TYPE
atual da instância do Compute Engine é do tipon1-standard-1
. A recomendação do Active Assist é alterá-lo para um tipog1-small
.Os revisores de controle de versão da sua empresa podem analisar os problemas automatizados do GitHub e tomar as medidas adequadas para ela.
Limpeza
Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
A seguir
- Saiba mais sobre as tecnologias sem servidor do Google Cloud.
- Leia sobre como integrar as recomendações do Policy Intelligence em um pipeline de infraestrutura como código (IaC, na sigla em inglês).