Este guia explica como realizar implantações azul/verde sem 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 de desenvolvedor, incluindo a criação e implantação de aplicativos em vários Google Cloud ambientes de execução como Compute Engine, Google Kubernetes Engine, GKE Enterprise e funções do Cloud Run.
Com os MIGs do Compute Engine, é possível operar aplicativos em várias máquinas virtuais (VMs) idênticas. É possível tornar as cargas de trabalho escalonáveis e altamente disponíveis aproveitando serviços de MIG automatizados, como 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ê vai 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
O diagrama a seguir mostra o modelo de implantação azul/verde usado pelo exemplo de código descrito neste documento:
Em 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 encaminha o tráfego de usuários finais para o pool azul ou verde de instâncias de VM.
- Um balanceador de carga azul que roteia o tráfego de engenheiros de controle de qualidade e desenvolvedores para o pool de instâncias de VM azul.
- Um balanceador de carga verde que roteia o tráfego de engenheiros de controle de qualidade e desenvolvedores para o pool de instâncias verdes.
- Dois conjuntos de usuários:
- Usuários finais que têm acesso ao balanceador de carga azul/verde, que os direciona para o pool de instâncias azul ou verde.
- Engenheiros de controle de qualidade e desenvolvedores 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.
O diagrama a seguir ilustra 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 do GitOps que ocorre durante cada implantação.
Para configurar essa infraestrutura, execute um script de configuração que inicia o processo de bootstrap 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 amostra do GitHub para o repositório no 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 azul e verde.
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 um 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 exclusã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.
Faça implantações azul-verde nas instâncias de VM.
Custos
Neste documento, você vai 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
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
Install the Google Cloud CLI.
-
If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Make sure that billing is enabled for your Google Cloud project.
-
Install the Google Cloud CLI.
-
If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Make sure that billing is enabled for your Google Cloud project.
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 pedir o consentimento do usuário, digite yes.
O script termina de ser executado em alguns segundos.
No Google Cloud console, abra a página Histórico de builds do Cloud Build:
Clique no build mais recente.
A página Detalhes da build aparece, mostrando um pipeline do Cloud Build com três etapas de build: 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 build.
Abra o Cloud Source Repositories:
Na lista de repositórios, clique em
copy-of-gcp-mig-simple
.Na guia Histórico na parte de baixo da página, você vai encontrar 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:
git push
Fazer mudanças 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
.O commit com a descrição
Promote green
vai aparecer na guia Histórico, na parte de baixo da página.Para ver a execução do gatilho
apply
, abra a página Histórico de builds no console Google Cloud :Clique no primeiro build para abrir a página Detalhes do build.
Você vai ver o pipeline de gatilho
apply
com duas etapas de build. A primeira etapa de build executa "terraform apply" para criar os recursos do Compute Engine e de balanceamento de carga para a implantação. A segunda etapa de build imprime o endereço IP em que você pode ver o aplicativo em execução.Abra o endereço IP correspondente ao MIG verde em um navegador. Você vai ver uma captura de tela semelhante a esta mostrando a implantação:
Acesse a página Grupo de instâncias do Compute Engine para ver os grupos de instâncias azul e verde:
Abra a página Instâncias de VM para conferir as quatro instâncias de VM:
Abra a página Endereços IP externos para conferir os três balanceadores de carga:
Você vai encontrar dois gatilhos de build chamados apply
e destroy
. O gatilho apply
está anexado ao arquivo infra/main.tfvars
na ramificação main
. Esse gatilho
é executado sempre que o arquivo é atualizado. O acionador destroy
é manual.
Noções básicas sobre o código
O código-fonte deste 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
roles/editor
do IAM à conta de serviço do Cloud Build no seu projeto. Essa função é necessária para que o Cloud Build crie e configure os componentes do GitOps necessários para a implantação. - Concede o papel
roles/source.admin
do IAM à conta de serviço do Cloud Build no seu projeto. Essa função é necessária para que a conta de serviço do Cloud Build crie o Cloud Source Repositories no seu 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 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 build de aplicação e destruição.
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 do fluxo do GitOps. O 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 do 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 chamar essas funções. - Etapa de build
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
definida em bash_utils.sh
. Os arquivos de configuração de build chamam essa função para
instalar o Terraform de maneira dinâmica. Ele cria um bucket do Cloud Storage para
registrar o status do Terraform.
O snippet de código a seguir 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. Depois, 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
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 a seguir 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 estão na pasta
copy-of-gcp-mig-simple/infra/
.
main.tf
: este é o arquivo de configuração do Terraformmain.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 azul e verde. 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 mudanças 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 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 essa variável como prefixo para que várias versões do aplicativo possam ser implantadas no mesmo projeto e os nomes dos objetos não entrem em conflito entre si.
- 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 de divisão. Esse módulo recebe a cor ativa para que o balanceador de carga do divisor saiba em qual MIG implantar o aplicativo.
O snippet de código a seguir de infra/main.tf
define dois módulos idênticos
para MIGs azuis e verdes. Ele usa a cor, a rede e a sub-rede, que são definidas no módulo divisor.
O arquivo splitter/main.tf
define os objetos criados para o MIG
splitter. Confira abaixo um snippet de código de splitter/main.tf
que
contém a lógica para alternar entre o MIG verde e o azul. Ele é apoiado pelo 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 a quantidade de tráfego a ser roteada.
O código a seguir encaminha 100% do tráfego para a cor especificada, mas você pode atualizar esse código para uma implantação canário e encaminhar o tráfego para um subconjunto de usuários.
O arquivo mig/main.tf
define os objetos relacionados 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 acontece porque, ao atualizar a versão do pool, não é possível usar o
modelo para criar a nova versão dos pools enquanto ele ainda está sendo usado pela
versão anterior do pool. Mas 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 primeiro
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 de aplicação:
Abra a página Gatilhos do Cloud Build:
Na tabela Gatilhos, localize a linha correspondente ao gatilho destroy e clique em Executar. Quando o gatilho termina a execução, os recursos criados por ele 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)
Excluir o projeto
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
A seguir
- Saiba mais sobre gatilhos de build.
- Saiba como ver a origem da build.