Neste guia, explicamos como executar implantações azul-verde sem tempo de inatividade em grupos gerenciados de instâncias (MIGs, na sigla em inglês) do Compute Engine usando o Cloud Build e o Terraform.
O Cloud Build permite automatizar vários processos do desenvolvedor, incluindo a criação e a implantação de aplicativos em vários ambientes de execução do Google Cloud, como Compute Engine, Google Kubernetes Engine, GKE Enterprise e Cloud Functions.
Os MIGs do Compute Engine permitem operar aplicativos em várias máquinas virtuais (VMs) idênticas. É possível tornar suas cargas de trabalho escalonáveis e altamente disponíveis aproveitando serviços de MIG automatizados, incluindo: escalonamento automático, recuperação automática, implantação regional (várias zonas) e atualização automática. Usando o modelo de implantação contínua azul-verde, você aprenderá a transferir gradualmente o tráfego de usuários de um MIG (azul) para outro (verde), ambos em execução na produção.
Visão geral do design
No diagrama a seguir, mostramos o modelo de implantação azul-verde usado pelo exemplo de código descrito neste documento:
De modo geral, esse modelo inclui os seguintes componentes:
- Dois pools de VMs do Compute Engine: azul e verde.
- Três balanceadores de carga HTTP(S) externos:
- Um balanceador de carga azul/verde, que roteia o tráfego de usuários finais para o pool azul ou verde das instâncias de VM.
- Um balanceador de carga azul que encaminha o tráfego de engenheiros e desenvolvedores de controle de qualidade para o pool de instâncias de VM azul.
- Um balanceador de carga verde que encaminha o tráfego de engenheiros e desenvolvedores de controle de qualidade para o pool de instâncias verde.
- Dois conjuntos de usuários:
- Usuários finais que têm acesso ao balanceador de carga azul/verde, que os aponta para o pool de instâncias azul ou verde.
- Engenheiros e desenvolvedores de controle de qualidade que precisam de acesso aos dois conjuntos de pools para fins de desenvolvimento e teste. Eles podem acessar os balanceadores de carga azul e verde, que os encaminham para o pool de instâncias azul e o pool de instâncias verde, respectivamente.
Os pools de VMs azul e verde são implementados como MIGs do Compute Engine, e os endereços IP externo são roteados para as VMs no MIG usando balanceadores de carga HTTP(s) externos. O exemplo de código descrito neste documento usa o Terraform para configurar essa infraestrutura.
No diagrama a seguir, ilustramos as operações do desenvolvedor que acontecem na implantação:
No diagrama acima, as setas vermelhas representam o fluxo de bootstrap que ocorre quando você configura a infraestrutura de implantação pela primeira vez, e as setas azuis representam o fluxo de GitOps que ocorre durante cada implantação.
Para configurar essa infraestrutura, execute um script de configuração que inicia o processo de inicialização e configura os componentes para o fluxo do GitOps.
O script de configuração executa um pipeline do Cloud Build que realiza as seguintes operações:
- Cria um repositório no Cloud Source Repositories chamado
copy-of-gcp-mig-simple
e copia o código-fonte do repositório de amostras do GitHub para o repositório do Cloud Source Repositories. - Cria dois gatilhos do Cloud Build chamados
apply
edestroy
.
O gatilho apply
está anexado a um arquivo do Terraform chamado main.tfvars
no Cloud Source Repositories. Esse arquivo contém as variáveis do Terraform que
representam os balanceadores de carga azuis e verdes.
Para configurar a implantação, atualize as variáveis no arquivo main.tfvars
.
O gatilho apply
executa um pipeline do Cloud Build que executa
tf_apply
e realiza as seguintes operações:
- Cria dois MIGs do Compute Engine (um para verde e outro para azul), quatro instâncias de VM do Compute Engine (duas para o MIG verde e duas para o MIG azul), os três balanceadores de carga (azul, verde e o divisor) e três endereços IP públicos.
- Imprime os endereços IP que podem ser usados para ver os aplicativos implantados nas instâncias azul e verde.
O gatilho de destruição é acionado manualmente para excluir todos os recursos criados pelo gatilho de aplicação.
Objetivos
Use o Cloud Build e o Terraform para configurar balanceadores de carga HTTP(S) externos com back-ends de grupo de instâncias de VM do Compute Engine.
Executar implantações azul-verde nas instâncias de VM.
Custos
Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:
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
- Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.
- Instale a CLI do Google Cloud.
-
Para inicializar a CLI gcloud, execute o seguinte comando:
gcloud init
-
Crie ou selecione um projeto do Google Cloud.
-
Crie um projeto do Google Cloud:
gcloud projects create PROJECT_ID
Substitua
PROJECT_ID
por um nome para o projeto do Google Cloud que você está criando. -
Selecione o projeto do Google Cloud que você criou:
gcloud config set project PROJECT_ID
Substitua
PROJECT_ID
pelo nome do projeto do Google Cloud.
-
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
- Instale a CLI do Google Cloud.
-
Para inicializar a CLI gcloud, execute o seguinte comando:
gcloud init
-
Crie ou selecione um projeto do Google Cloud.
-
Crie um projeto do Google Cloud:
gcloud projects create PROJECT_ID
Substitua
PROJECT_ID
por um nome para o projeto do Google Cloud que você está criando. -
Selecione o projeto do Google Cloud que você criou:
gcloud config set project PROJECT_ID
Substitua
PROJECT_ID
pelo nome do projeto do Google Cloud.
-
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
Testar
Execute o script de configuração do repositório de exemplo de código do Google:
bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)
Quando o script de configuração solicitar o consentimento do usuário, digite yes.
A execução do script é concluída em alguns segundos.
No console do Google Cloud, abra a página Histórico de versões do Cloud Build:
Clique no build mais recente.
Você verá a página Detalhes da versão, que mostra um pipeline do Cloud Build com três etapas: a primeira cria um repositório no Cloud Source Repositories, a segunda clona o conteúdo do repositório de amostra no GitHub para o Cloud Source Repositories e a terceira adiciona dois gatilhos de compilação.
Abra o Cloud Source Repositories:
Na lista de repositórios, clique em
copy-of-gcp-mig-simple
.Na guia Histórico, na parte inferior da página, você verá um commit com a descrição
A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git
feito pelo Cloud Build para criar um repositório chamadocopy-of-gcp-mig-simple
.Abra a página Gatilhos do Cloud Build:
Para iniciar o processo de implantação, atualize o arquivo
infra/main.tfvars
:Na janela do terminal, crie e navegue até uma pasta chamada
deploy-compute-engine
:mkdir ~/deploy-compute-engine cd ~/deploy-compute-engine
Clone o repositório
copy-of-gcp-mig-simple
:gcloud source repos clone copy-of-mig-blue-green
Navegue até o diretório clonado:
cd ./copy-of-mig-blue-green
Atualize
infra/main.tfvars
para substituir azul por verde:sed -i'' -e 's/blue/green/g' infra/main.tfvars
Adicione o arquivo atualizado:
git add .
Faça a confirmação do arquivo:
git commit -m "Promote green"
Envie o arquivo por push:
git push
Fazer alterações em
infra/main.tfvars
aciona a execução do gatilhoapply
, que inicia a implantação.
Abra o Cloud Source Repositories:
Na lista de repositórios, clique em
copy-of-gcp-mig-simple
.Você verá o commit com a descrição
Promote green
na guia Histórico, na parte inferior da página.Para visualizar a execução do gatilho
apply
, abra a página Histórico de build no console do Google Cloud:Clique no primeiro build para abrir a página Detalhes do build.
Você vai notar o pipeline do gatilho
apply
com duas etapas de build. A primeira etapa executa o Terraform apply para criar o Compute Engine e os recursos de balanceamento de carga para a implantação. A segunda etapa do build imprime o endereço IP em que é possível ver o aplicativo em execução.Abra o endereço IP correspondente ao MIG verde em um navegador. Será exibida uma captura de tela semelhante à seguinte que mostra a implantação:
Acesse a página Grupo de instâncias do Compute Engine para ver os grupos azul e verde:
Abra a página Instâncias de VM para ver as quatro instâncias:
Abra a página Endereços IP externos para ver os três balanceadores de carga:
Você vai ver dois gatilhos de build chamados apply
e destroy
. O gatilho apply
é anexado ao arquivo infra/main.tfvars
na ramificação main
. Esse gatilho é executado sempre que o arquivo é atualizado. O gatilho destroy
é manual.
Noções básicas sobre o código
O código-fonte desse exemplo de código inclui:
- Código-fonte relacionado ao script de configuração.
- Código-fonte relacionado aos pipelines do Cloud Build.
- Código-fonte relacionado aos modelos do Terraform.
Script de configuração
setup.sh
é o script de configuração que executa o processo de inicialização e cria os
componentes para a implantação azul-verde. O script executa as seguintes
operações:
- Ativa as APIs Cloud Build, Resource Manager, Compute Engine e Cloud Source Repositories.
- Concede o papel de IAM
roles/editor
à conta de serviço do Cloud Build no projeto. Esse papel é necessário para que o Cloud Build crie e configure os componentes GitOps necessários para a implantação. - Concede o papel de IAM
roles/source.admin
à conta de serviço do Cloud Build no projeto. Esse papel é necessário para que a conta de serviço do Cloud Build crie o Cloud Source Repositories no projeto e clone o conteúdo do repositório de exemplo do GitHub no Cloud Source Repositories. Gera um pipeline do Cloud Build chamado
bootstrap.cloudbuild.yaml
inline, que:- Cria um novo repositório no Cloud Source Repositories.
- Copia o código-fonte do repositório de amostra do GitHub para o novo repositório no Cloud Source Repositories.
- Cria os gatilhos de compilação "apply e destroy".
Pipelines do Cloud Build
apply.cloudbuild.yaml
e destroy.cloudbuild.yaml
são os
arquivos de configuração do Cloud Build que o script de configuração usa para configurar os
recursos para o fluxo do GitOps. apply.cloudbuild.yaml
contém duas etapas de build:
- etapa de build
tf_apply build
que chama a funçãotf_install_in_cloud_build_step
, que instala o Terraform.tf_apply
, que cria os recursos usados no fluxo de GitOps. As funçõestf_install_in_cloud_build_step
etf_apply
são definidas embash_utils.sh
, e a etapa de build usa o comandosource
para chamá-las. - etapa de criação
describe_deployment
que chama a funçãodescribe_deployment
que imprime os endereços IP dos balanceadores de carga.
destroy.cloudbuild.yaml
chama tf_destroy
, que exclui todos os recursos
criados por tf_apply
.
As funções tf_install_in_cloud_build_step
, tf_apply
, describe_deployment
e tf_destroy
são definidas no arquivo bash_utils.sh
.
Os arquivos de configuração de build usam o comando source
para chamar as funções.
O código a seguir mostra a função tf_install_in_cloud_build_step
que está
definida em bash_utils.sh
. Os arquivos de configuração de build chamam essa função
para instalar o Terraform em tempo real. Ele cria um bucket do Cloud Storage
para registrar o status do Terraform.
O snippet de código abaixo mostra a função tf_apply
definida em
bash_utils.sh
. Primeiro, ele chama terraform init
, que carrega todos os módulos e
bibliotecas personalizadas, e executa terraform apply
para carregar as variáveis
do arquivo main.tfvars
.
O snippet de código a seguir mostra a função describe_deployment
que é
definida em bash_utils.sh
. Ele usa gcloud compute addresses describe
para buscar
os endereços IP dos balanceadores de carga usando o nome e os imprime.
O snippet de código abaixo mostra a função tf_destroy
definida em
bash_utils.sh
. Ele chama terraform init
, que carrega todos os módulos e bibliotecas
personalizadas, e executa terraform destroy
, que descarrega as variáveis do Terraform.
Modelos do Terraform
Todos os arquivos e variáveis de configuração do Terraform estarão na pasta copy-of-gcp-mig-simple/infra/
.
main.tf
: é o arquivo de configuração do Terraform.main.tfvars
: esse arquivo define as variáveis do Terraform.mig/
esplitter/
: essas pastas contêm os módulos que definem os balanceadores de carga. A pastamig/
contém o arquivo de configuração do Terraform que define o MIG para os balanceadores de carga azuis e verdes. Os MIGs azul e verde são idênticos. Portanto, eles são definidos uma vez e instanciados para os objetos azul e verde. O arquivo de configuração do Terraform para o balanceador de carga do divisor está na pastasplitter/
.
O snippet de código a seguir mostra o conteúdo de infra/main.tfvars
. Ele contém três variáveis: duas que determinam qual versão do aplicativo implantar nos pools azul e verde e uma variável para a cor ativa: azul ou verde. As alterações feitas nesse arquivo acionam a implantação.
Confira a seguir um snippet de código de infra/main.tf
. Neste snippet:
- Uma variável é definida para o projeto do Google Cloud.
- O Google está definido como o provedor do Terraform.
- Uma variável é definida para o namespace. Todos os objetos criados pelo Terraform têm o prefixo dessa variável para que várias versões do aplicativo possam ser implantadas no mesmo projeto e os nomes dos objetos não entrem em conflito.
- As variáveis
MIG_VER_BLUE
,MIG_VER_BLUE
eMIG_ACTIVE_COLOR
são as vinculações das variáveis no arquivoinfra/main.tfvars
.
O snippet de código a seguir de infra/main.tf
mostra a instanciação do
módulo do divisor. Esse módulo usa a cor ativa para que o balanceador de carga do
divisor saiba qual MIG implantar o aplicativo.
O snippet de código a seguir de infra/main.tf
define dois módulos idênticos para MIGs azul e verde. Ele usa a cor, a rede e a sub-rede
definidas no módulo do divisor.
O arquivo splitter/main.tf
define os objetos criados para o
MIG do divisor. Veja a seguir um snippet de código de splitter/main.tf
que
contém a lógica para alternar entre o MIG verde e azul. Ele tem o
suporte do serviço google_compute_region_backend_service
, que pode rotear o tráfego para
duas regiões de back-end: var.instance_group_blue
ou var.instance_group_green
.
capacity_scaler
define o tráfego a ser roteado.
O código a seguir roteia 100% do tráfego para a cor especificada, mas é possível atualizar esse código para implantação canário para rotear o tráfego a um subconjunto de usuários.
O arquivo mig/main.tf
define os objetos que pertencem aos MIGs azul e
verde. O snippet de código a seguir desse arquivo define o modelo de instância do Compute Engine usado para criar os pools de VMs. Observe que esse modelo de instância tem a propriedade de ciclo de vida do Terraform definida como create_before_destroy
.
Isso ocorre porque, ao atualizar a versão do pool, não é possível usar o modelo para criar a nova versão dos pools quando ela ainda está sendo usada pela versão anterior do pool. No entanto, se a versão mais antiga do pool for
destruída antes da criação do novo modelo, haverá um período em que
os pools ficarão inativos. Para evitar esse cenário, definimos o ciclo de vida do Terraform como create_before_destroy
para que a versão mais recente de um pool de VMs seja criada antes que a versão mais antiga seja destruída.
Limpar
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.
Excluir recursos individuais
Exclua os recursos do Compute Engine criados pelo gatilho apply:
Abra a página Gatilhos do Cloud Build:
Na tabela Triggers, localize a linha correspondente ao acionador destroy e clique em Run. Quando o acionador conclui a execução, os recursos criados pelo acionador apply são excluídos.
Exclua os recursos criados durante o bootstrapping executando o seguinte comando na janela do terminal:
bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/teardown.sh)
Exclua o projeto
Exclua um projeto do Google Cloud:
gcloud projects delete PROJECT_ID
A seguir
- Saiba mais sobre gatilhos de build.
- Saiba como conferir a procedência do build.