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 a criação e implantação de aplicativos em vários ambientes de execução do Google Cloud como o Compute Engine, Google Kubernetes Engine, GKE Enterprise, e o Cloud Functions.
Os MIGs do Compute Engine permitem operar aplicativos em várias máquinas virtuais (VMs) idênticas. É possível deixar para cargas de trabalho escalonáveis e altamente disponíveis aproveitando o MIG automatizado serviços, incluindo: escalonamento automático, recuperação automática, regional (várias zonas) implantação 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:
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 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 encaminha o tráfego de engenheiros e desenvolvedores para o pool de instâncias de VM azul.
- Um balanceador de carga verde que roteia o tráfego de engenheiros 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 e balanceadores de carga de rede 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 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 bootstrap e configura os componentes para o fluxo de 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 GitHub repositório de amostra 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 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 executa 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.
- Imprime os endereços IP que você pode usar para ver os nas instâncias azul e verde.
O gatilho de destruição é acionado manualmente para excluir todos os recursos criados pelo no gatilho "apply".
Objetivos
Usar o Cloud Build e o Terraform para configurar a carga HTTP(S) externa com back-ends de grupos de instâncias de VMs 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.
- 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 solicitar o consentimento do usuário, digite yes.
A execução do script é concluída em alguns segundos.
No console do Google Cloud, abra o Histórico de builds do Cloud Build. página:
Clique no build mais recente.
Você verá a página Detalhes do build, que mostra um Cloud Build pipeline com três etapas de build: a primeira cria um repositório Cloud Source Repositories, a segunda etapa clona o conteúdo do exemplo no GitHub ao Cloud Source Repositories. A terceira etapa adiciona dois e 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 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 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
.Você verá o commit com a descrição
Promote green
no 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 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 a etapa de build executa o Terraform apply para criar o Compute Engine e carregar 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ê 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 ver os três balanceadores de carga:
Você vai ver 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 gatilho destroy
é um manual
gatilho.
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 o
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 ao conta de serviço do Cloud Build no projeto. Este papel é para que o Cloud Build crie e configure Componentes de GitOps para a implantação. - Concede o papel
roles/source.admin
do IAM ao conta de serviço do Cloud Build no projeto. Este papel é necessária para que a conta de serviço do Cloud Build crie o o Cloud Source Repositories no seu projeto e clonar o conteúdo do exemplo repositório do GitHub para o 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 exemplo do GitHub para o um 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
Os arquivos de configuração do Cloud Build que o script de configuração usa para definir o
recursos para o fluxo de GitOps. 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. - a etapa de build
describe_deployment
que chama a função;describe_deployment
, que imprime os endereços IP da carga. para balanceadores de carga HTTP(S) e 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 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 é
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
definida em
bash_utils.sh
. Ele chama terraform init
, que carrega todos os módulos e objetos
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
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 o e balanceadores de carga de rede externos. A pastamig/
contém o arquivo de configuração do Terraform que define o MIG para os balanceadores de carga azul e verde. 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. A configuração do Terraform O arquivo do balanceador de carga do divisor está na pastasplitter/
.
O snippet de código a seguir 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 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 são prefixada com essa variável para que várias versões do aplicativo possam ser implantados no mesmo projeto e os nomes dos objetos não entrarem em conflito 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 divisor. Este módulo assume a cor ativa para que o splitter carregue
balanceador sabe qual MIG implantar o aplicativo.
O snippet de código de infra/main.tf
abaixo define dois módulos idênticos.
para MIGs azul e verde. 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 o tráfego
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 até a cor especificada, mas você pode atualizar esse código para implantação canário para rotear o tráfego a um subconjunto de os usuários.
O arquivo mig/main.tf
define os objetos que pertencem às imagens azul e verde
MIGs. O snippet de código a seguir desse arquivo define a Compute Engine
modelo de instância usado para criar os pools de VMs. Observe que essa instância
o modelo tem a propriedade de ciclo de vida do Terraform definida 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
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 bootstrapping executando o seguinte comando na janela de 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.