Este guia explica como executar implantações azul-verde sem tempo de inatividade Grupos gerenciados de instâncias (MIGs) do Compute Engine usando o Cloud Build e o Terraform.
O Cloud Build permite automatizar vários processos para desenvolvedores, incluindo criar e implantar aplicativos em vários ambientes de execução do Google Cloud como o Compute Engine, Google Kubernetes Engine, GKE Enterprise, e funções do Cloud Run.
Os MIGs do Compute Engine permitem 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. Como usar a implantação contínua azul-verde você vai aprender a transferir gradualmente o tráfego de usuários de um MIG (azul) para outro MIG (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 código descrito neste documento:
Em um nível alto, 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 de instâncias de VM.
- Um balanceador de carga Blue que roteia o tráfego de engenheiros de QA e desenvolvedores para o pool de instâncias de VM Blue.
- Um balanceador de carga verde que encaminha o tráfego de engenheiros de QA e desenvolvedores para o pool de instâncias verdes.
- Dois conjuntos de usuários:
- Os usuários finais que têm acesso ao balanceador de carga azul/verde, que aponta ao pool de instâncias azul ou verde.
- Engenheiros e desenvolvedores de controle de qualidade que precisam de acesso aos dois conjuntos de pools para para fins de desenvolvimento e teste. Eles podem acessar os ícones Azul e balanceadores de carga verdes, 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. os endereços IP externo são roteados para as VMs no MIG usando HTTP(s) externos balanceadores de carga de aplicativo 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 ocorrem na implantação:
No diagrama acima, as setas vermelhas representam o fluxo de bootstrapping ocorre quando você configura a infraestrutura de implantação pela primeira vez, e o 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 inicialização e configura os componentes para o fluxo do GitOps.
O script de configuração executa um pipeline do Cloud Build que realiza a 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 exemplo do GitHub para o repositório no Cloud Source Repositories. - cria dois gatilhos do Cloud Build chamados
apply
edestroy
.
O acionador apply
é anexado a um arquivo do Terraform chamado main.tfvars
nos repositórios de origem do Cloud. 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 azul os três balanceadores de carga (azul, verde e divisor) e os três endereços IP públicos.
- Mostra os endereços IP que podem ser usados para conferir os aplicativos implantados nas instâncias azul e verde.
O acionador de destruição é acionado manualmente para excluir todos os recursos criados pelo acionador 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
- 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.
-
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.
-
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
- Install the Google Cloud CLI.
-
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.
-
-
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 pedir o consentimento do usuário, digite sim.
O script termina de ser executado em alguns segundos.
No console do Google Cloud, abra a página Histórico de build do Cloud Build:
Clique no build mais recente.
A página Detalhes do 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 exemplo 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 inferior da página, você verá um commit com a descrição
A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git
feita 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 o 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 no
infra/main.tfvars
aciona a execução doapply
. 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 History, na parte de baixo da página.Para conferir a execução do gatilho
apply
, abra a página Histórico da 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 de build 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 mostra o endereço IP onde você vê 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 as colunas Azul e Grupos de instâncias verdes:
Abra a página Instâncias de VM para ver as quatro instâncias:
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
. Este gatilho
é executado sempre que o arquivo é atualizado. O acionador 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 o seguinte
operações:
- Ativa o Cloud Build, o 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. Esse papel é necessário para que o Cloud Build crie e configure os componentes necessários do GitOps para a implantação. - Concede o papel
roles/source.admin
do IAM ao conta de serviço do Cloud Build no projeto. Essa função é necessária para que a conta de serviço do Cloud Build crie os repositórios do Cloud Source no seu projeto e clone o conteúdo do repositório do GitHub de exemplo para os repositórios do Cloud Source. 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 do GitHub de exemplo para o novo repositório no Cloud Source Repositories.
- Cria os gatilhos de aplicação e destruição de build.
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:
- a etapa de build
tf_apply build
que chama a função;tf_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 definidos embash_utils.sh
e a etapa de build usa o comandosource
para chamar para resolvê-los com rapidez. - 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
criado por tf_apply
.
As funções tf_install_in_cloud_build_step
, tf_apply
,
describe_deployment
e tf_destroy
são definidos no arquivo bash_utils.sh
.
Os arquivos de configuração do 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 é
definido 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
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 e, em seguida, executa terraform apply
para carregar as variáveis da
o arquivo main.tfvars
.
O snippet de código a seguir mostra a função describe_deployment
, que é
definido 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
, que é definida em
bash_utils.sh
. Ele chama terraform init
, que carrega todos os módulos e bibliotecas
personalizadas e, em seguida, 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
: é o arquivo de configuração do Terraformmain.tfvars
: este arquivo define as variáveis do Terraform.mig/
esplitter/
: essas pastas contêm os módulos que definem o balanceadores de carga de aplicativo externos. A pastamig/
contém o arquivo de configuração do Terraform que define o MIG para os balanceadores de carga azuis e verdes. As APIs Azul e os MIGs verdes são idênticos, então eles são definidos uma vez e 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 abaixo mostra o conteúdo de infra/main.tfvars
. Ela
contém três variáveis: duas que determinam a versão do aplicativo a ser implantada
ao pool Azul e ao Verde e uma variável para a cor ativa: Azul ou
verde. As alterações 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 colidam entre si.
- As variáveis
MIG_VER_BLUE
,MIG_VER_BLUE
eMIG_ACTIVE_COLOR
são as vinculações para as 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 qual MIG implantar o aplicativo.
O snippet de código abaixo 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 definidos no módulo do divisor.
O arquivo splitter/main.tf
define os objetos criados para o
o MIG do splitter. Confira abaixo um snippet de código da splitter/main.tf
que
contém a lógica para alternar entre o MIG verde e azul. Ele é apoiado por
o serviço google_compute_region_backend_service
, que pode rotear 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 encaminha 100% do tráfego para a cor especificada, mas você pode atualizar esse código para a implantação canário para encaminhar o tráfego para um subconjunto de usuários.
O arquivo mig/main.tf
define os objetos relacionados às MIGs
azuis e verdes. O snippet de código a seguir define o modelo de instância do Compute Engine usado para criar os pools de VM. Observe que o ciclo de vida da propriedade do modelo de instância está definido como create_before_destroy
.
Isso porque, ao atualizar a versão do pool, não é possível usar o
para criar a nova versão dos pools quando ela ainda estiver sendo usada
a versão anterior do pool. Mas, se a versão mais antiga do pool for
destruídos antes de criar o novo modelo, haverá um período de tempo em que
que as piscinas caíram. 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 apply:
Abra a página Gatilhos do Cloud Build:
Na tabela Triggers, localize a linha correspondente ao destroy. e clique em Executar. Quando o gatilho conclui a execução, o os recursos criados pelo gatilho apply são excluídos.
Exclua os recursos criados durante o inicialização 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
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
A seguir
- Saiba mais sobre gatilhos de build.
- Saiba como conferir a procedência do build.