1. Introdução
Este é o codelab de balanceamento de carga de HTTPs externos com gerenciamento de tráfego avançado (Envoy).
A versão mais recente do balanceador de carga HTTP(S) externo com gerenciamento de tráfego avançado contém todos os recursos do balanceador de carga HTTP(S) externo global clássico, mas com uma lista cada vez maior de recursos de gerenciamento de tráfego avançado. Alguns desses recursos são novos para nossos balanceadores de carga e outros fornecem recursos aprimorados aos recursos atuais. Uma lista parcial desses recursos inclui:
- Divisão de tráfego ponderada
- Solicitar espelhamento
- Detecção de outlier
- Tentativas de solicitação
- Injeção de falha
- Opções adicionais de afinidade da sessão de back-end
- Outras opções de transformação de cabeçalho
- Compartilhamento de recursos entre origens (CORS, na sigla em inglês)
- Novos algoritmos de balanceamento de carga
O que você vai aprender
- Como configurar um grupo gerenciado de instâncias, a VPC associada e as regras de firewall
- Como usar os recursos avançados de gerenciamento de tráfego do novo balanceador de carga
- Como validar se os recursos avançados de gerenciamento de tráfego estão funcionando conforme o esperado.
O que é necessário
- Rede básica e conhecimento de HTTP
- Conhecimento básico de linha de comando do Unix/Linux
Topologia e caso de uso
Figura 1: topologia de roteamento do balanceador de carga HTTP
Durante este codelab, você vai configurar três grupos gerenciados de instâncias, um nas regiões leste, oeste e central. Você vai criar um balanceador de carga HTTPS externo global. O balanceador de carga vai utilizar vários recursos da lista de recursos avançados com suporte do balanceador de carga baseado em Envoy. Após a implantação, você vai gerar uma carga simulada e verificar se as configurações definidas estão funcionando corretamente.
2. Configuração e requisitos
Configuração de ambiente autoguiada
- Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.
- O Nome do projeto é o nome de exibição para os participantes do projeto. Ele é uma string de caracteres que não é usada pelas APIs do Google e pode ser atualizada a qualquer momento.
- O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado após a definição. O Console do Cloud gera automaticamente uma string única, geralmente não importa o que seja. Na maioria dos codelabs, você precisará fazer referência ao ID do projeto, que geralmente é identificado como
PROJECT_ID. Então, se você não gostar dele, gere outro ID aleatório ou crie um próprio e veja se ele está disponível. Em seguida, ele fica "congelado" depois que o projeto é criado. - Há um terceiro valor, um Número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
- Em seguida, você precisará ativar o faturamento no Console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e não gerar cobranças além deste tutorial, siga as instruções de "limpeza" encontradas no final do codelab. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.
Inicie o Cloud Shell
Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:
O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:
Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.
Antes de começar
No Cloud Shell, verifique se o ID do projeto está configurado
gcloud config list project
gcloud config set project [SEU-NOME-DO-PROJETO]
PROJECT_ID=[YOUR-PROJECT-NAME]
echo $PROJECT_ID
Ativar APIs
Ative todos os serviços necessários
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. criar a rede VPC
Crie uma rede VPC
No Cloud Shell
gcloud compute networks create httplbs --subnet-mode=auto
Saída
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/httplbs]. NAME: httplbs SUBNET_MODE: AUTO BGP_ROUTING_MODE: REGIONAL IPV4_RANGE: GATEWAY_IPV4:
Crie regras de firewall de VPC
Depois de criar a VPC, você vai criar regras de firewall. A regra de firewall será usada para permitir que todos os IPs acessem o IP externo do site do aplicativo de teste na porta 80 para tráfego HTTP.
No Cloud Shell
gcloud compute firewall-rules create httplb-allow-http-rule \ --allow tcp:80 \ --network httplbs \ --source-ranges 0.0.0.0/0 \ --priority 700
Saída
Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls/httplb-allow-http-rule]. Creating firewall...done. NAME: httplb-allow-http-rule NETWORK: httplbs DIRECTION: INGRESS PRIORITY: 700 ALLOW: tcp:80 DENY: DISABLED: False
4. Configurar os grupos gerenciados de instâncias
Você precisa configurar grupos gerenciados de instâncias que incluam os padrões dos recursos de back-end usados pelo balanceador de carga HTTP. Primeiro vamos criar modelos de instância que definem a configuração das VMs que serão criadas em cada região. Em seguida, para um back-end em cada região, vamos criar um grupo gerenciado de instâncias que faz referência a um modelo de instância.
Os grupos gerenciados de instâncias podem ter escopo zonal ou regional. Para este exercício de laboratório, vamos criar três grupos gerenciados de instâncias regionais, um em us-east1, um em us-west1 e outro em us-central1.
Nesta seção, você encontra um script de inicialização pré-criado que será referenciado na criação da instância. O script de inicialização instala e ativa os recursos do servidor da Web que serão usados para simular um aplicativo da Web. Sinta-se à vontade para explorar esse script.
Criar os modelos de instâncias Leste, Oeste e Central
A primeira etapa é criar o modelo de instância de us-east-1.
No Cloud Shell
gcloud compute instance-templates create us-east1-template \
--region=us-east1 \
--network=httplbs \
--tags=http-server, \
--image-family=debian-9 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
Saída
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-east1-template]. NAME: us-east1-template MACHINE_TYPE: n1-standard-1 PREEMPTIBLE: CREATION_TIMESTAMP: 2021-11-11T11:02:37.511-08:00
A próxima etapa é criar o modelo de instância de us-west-1.
No Cloud Shell
gcloud compute instance-templates create us-west1-template \
--region=us-west1 \
--network=httplbs \
--tags=http-server, \
--image-family=debian-9 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
Saída
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-west1-template]. NAME: us-west1-template MACHINE_TYPE: n1-standard-1 PREEMPTIBLE: CREATION_TIMESTAMP: 2021-11-11T11:03:08.577-08:00
A próxima etapa é criar o modelo de instância de us-central-1.
No Cloud Shell
gcloud compute instance-templates create us-central1-template \
--region=us-central1 \
--network=httplbs \
--tags=http-server, \
--image-family=debian-9 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
Saída
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-central1-template]. NAME: us-central1-template MACHINE_TYPE: n1-standard-1 PREEMPTIBLE: CREATION_TIMESTAMP: 2021-11-11T11:03:44.179-08:00
Agora é possível verificar se nossos modelos de instância foram criados com o seguinte comando gcloud:
No Cloud Shell
gcloud compute instance-templates list
Saída
NAME MACHINE_TYPE PREEMPTIBLE CREATION_TIMESTAMP us-central1-template n1-standard-1 2021-11-09T09:25:37.263-08:00 us-east1-template n1-standard-1 2021-11-09T09:24:35.275-08:00 us-west1-template n1-standard-1 2021-11-09T09:25:08.016-08:00
Criar os grupos de instâncias gerenciadas nas regiões leste, oeste e central
Agora precisamos criar um grupo gerenciado de instâncias usando os modelos de instância criados anteriormente.
No Cloud Shell
gcloud compute instance-groups managed create us-east1-mig \ --base-instance-name=us-east1-mig \ --size=1 \ --template=us-east1-template \ --zone=us-east1-b
Saída
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-east1-b/instanceGroupManagers/us-east1-mig]. NAME: us-east1-mig LOCATION: us-east1-b SCOPE: zone BASE_INSTANCE_NAME: us-east1-mig SIZE: 0 TARGET_SIZE: 1 INSTANCE_TEMPLATE: us-east1-template AUTOSCALED: no
No Cloud Shell
gcloud compute instance-groups managed create us-west1-mig \ --base-instance-name=us-west1-mig \ --size=1 \ --template=us-west1-template \ --zone=us-west1-a
Saída
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroupManagers/us-west1-mig]. NAME: us-west1-mig LOCATION: us-west1-a SCOPE: zone BASE_INSTANCE_NAME: us-west1-mig SIZE: 0 TARGET_SIZE: 1 INSTANCE_TEMPLATE: us-west1-template AUTOSCALED: no
No Cloud Shell
gcloud compute instance-groups managed create us-central1-mig \ --base-instance-name=us-central1-mig \ --size=1 \ --template=us-central1-template \ --zone=us-central1-a
Saída
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-central1-a/instanceGroupManagers/us-central1-mig]. NAME: us-central1-mig LOCATION: us-central1-a SCOPE: zone BASE_INSTANCE_NAME: us-central1-mig SIZE: 0 TARGET_SIZE: 1 INSTANCE_TEMPLATE: us-central1-template AUTOSCALED: no
É possível verificar se os grupos de instâncias foram criados com o seguinte comando gcloud:
No Cloud Shell
gcloud compute instance-groups list
Saída
NAME LOCATION SCOPE NETWORK MANAGED INSTANCES us-central1-mig us-central1 zone httplbs Yes 1 us-west1-mig us-west1 zone httplbs Yes 1 us-east1-mig us-east1 zone httplbs Yes 1
Verificar a funcionalidade do servidor da Web
Cada instância é configurada para executar um servidor da Web Apache com um script PHP simples que renderiza:
Para garantir que seus servidores da Web estejam funcionando corretamente, acesse Compute Engine -> do que para instâncias de VM padrão. Verifique se as novas instâncias (por exemplo, us-east1-mig-xxx) foram criadas de acordo com as definições do grupo de instâncias.
Agora, faça uma solicitação da Web em seu navegador para garantir que o servidor esteja em execução (pode levar um minuto para iniciar). Na página "Instâncias de VM" em "Compute Engine", selecione uma instância criada pelo grupo e clique no IP externo (público).
Ou, em seu navegador, navegue até http://<IP_Address>
5. Configurar o balanceador de carga
Criar verificação de integridade
Primeiro, precisamos criar uma verificação de integridade básica para garantir que nossos serviços estejam funcionando. Vamos criar uma verificação de integridade básica. Há muitas outras personalizações avançadas disponíveis.
No Cloud Shell
gcloud compute health-checks create http http-basic-check \
--port 80
Reservar endereço IP externo
Nesta etapa, você precisará reservar um endereço IP estático disponível globalmente que será anexado posteriormente ao balanceador de carga.
No Cloud Shell
gcloud compute addresses create lb-ipv4-2 \
--ip-version=IPV4 \
--global
Anote o endereço IP que foi reservado.
gcloud compute addresses describe lb-ipv4-2 \
--format="get(address)" \
--global
Criar serviços de back-end
Agora é preciso criar um serviço de back-end para cada um dos grupos gerenciados de instâncias criados anteriormente. Uma para Leste, Oeste e Central.
Como criar um serviço de back-end para o grupo de instâncias gerenciadas Leste.
No Cloud Shell
gcloud compute backend-services create east-backend-service \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \
--global
Criar um serviço de back-end para o grupo gerenciado de instâncias do Oeste.
No Cloud Shell
gcloud compute backend-services create west-backend-service \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \
--global
Criar um serviço de back-end para o grupo gerenciado de instâncias da Central.
No Cloud Shell
gcloud compute backend-services create central-backend-service \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \
--global
Adicionar MIGs aos serviços de back-end
Agora que criamos os respectivos serviços de back-end para cada cluster de aplicativo, precisamos adicionar os grupos gerenciados de instâncias criados anteriormente a cada serviço de back-end.
Adicionar MIG Leste ao serviço de back-end.
No Cloud Shell
gcloud compute backend-services add-backend east-backend-service \
--balancing-mode='UTILIZATION' \
--instance-group=us-east1-mig \
--instance-group-zone=us-east1-b \
--global
Adicione o MIG Ocidental ao serviço de back-end.
No Cloud Shell
gcloud compute backend-services add-backend west-backend-service \
--balancing-mode='UTILIZATION' \
--instance-group=us-west1-mig \
--instance-group-zone=us-west1-a \
--global
Adicionar um MIG central ao serviço de back-end.
No Cloud Shell
gcloud compute backend-services add-backend central-backend-service \
--balancing-mode='UTILIZATION' \
--instance-group=us-central1-mig \
--instance-group-zone=us-central1-a \
--global
Criar mapa de URL
Os recursos avançados de gerenciamento de tráfego deste laboratório estarão disponíveis no mapa de URLs. Precisamos criar um arquivo .yaml que conterá a configuração. Dentro do arquivo .yaml, criamos uma correspondência de prefixo em /roundrobbin, portanto, apenas o tráfego correspondente a /roundrobbin será afetado por essas configurações. Especificamos que 50% do tráfego deve ir para east-backend-service e 50% para west-backend-service. Além disso, adicionamos um valor de cabeçalho de resposta {test}, que vai estar presente em todas as respostas. Por fim, adicionamos que todo o tráfego deve ser espelhado ao central-backend-service. O tráfego é duplicado e enviado aqui apenas para fins de teste.
Salve o exemplo como um arquivo .yaml na sua máquina.
defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
kind: compute #urlMap
name: web-map-http
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /roundrobbin
priority: 2
headerAction:
responseHeadersToAdd:
- headerName: test
headerValue: value
replace: True
routeAction:
weightedBackendServices:
- backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
weight: 50
- backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/west-backend-service
weight: 50
retryPolicy:
retryConditions: ['502', '504']
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 50
requestMirrorPolicy:
backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/central-backend-service
Crie o mapa de URL importando o documento da sua máquina. O caminho de origem será diferente dependendo de onde você salvar o arquivo .yaml.
No Cloud Shell
gcloud compute url-maps import web-map-http \ --source /Users/[USERNAME]/Documents/Codelab/lbconfig.yaml \ --global
Criar um front-end HTTP
A etapa final na criação do balanceador de carga é a criação do front-end. Isso vai mapear o endereço IP reservado anteriormente para o mapa de URL do balanceador de carga que você criou.
No Cloud Shell
gcloud compute target-http-proxies create http-lb-proxy-adv \
--url-map=web-map-http
Em seguida, crie uma regra de encaminhamento global que mapeará o endereço IP reservado anteriormente para o proxy HTTP.
No Cloud Shell
gcloud compute forwarding-rules create http-content-rule \
--load-balancing-scheme EXTERNAL_MANAGED \
--address=lb-ipv4-2 \
--global \
--target-http-proxy=http-lb-proxy-adv \
--ports=80
6. Verificar se os recursos avançados de tráfego estão funcionando
Para verificar se o recurso de divisão de tráfego implementado está funcionando, é necessário gerar carga. Para isso, vamos criar uma nova VM para simular a carga.
Criar regra de permissão de firewall SSH
Para usar o SSH na VM que vai gerar tráfego, primeiro crie uma regra de firewall para permitir o tráfego SSH.
No Cloud Shell
gcloud compute firewall-rules create fw-allow-ssh \
--network=httplbs \
--action=allow \
--direction=ingress \
--target-tags=allow-ssh \
--rules=tcp:22
Saída
NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED fw-allow-ssh httplbs INGRESS 1000 tcp:22 False
Crie Siege-vm
Agora você vai criar a siege-vm que será usada para gerar cargas
No Cloud Shell
gcloud compute instances create siege-vm \
--network=httplbs \
--zone=us-east4-c \
--machine-type=e2-medium \
--tags=allow-ssh,http-server \
--metadata=startup-script='sudo apt-get -y install siege'
Saída
NAME ZONE MACHINE_TYPE INTERNAL_IP EXTERNAL_IP STATUS siege-vm us-east4-c e2-medium 10.150.0.3 34.85.218.119 RUNNING
Em seguida, conecte-se via SSH à VM que você criou. Depois disso, clique em SSH para iniciar um terminal e se conectar.
Depois de se conectar, execute o comando a seguir para gerar carga. Use o endereço IP que você reservou anteriormente para o balanceador de carga HTTP externo.
No Cloud Shell
siege -c 250 http://$lb-ipv4-2/roundrobbin
Saída
New configuration template added to /home/cloudcurriculumdeveloper/.siege Run siege -C to view the current settings in that file [alert] Zip encoding disabled; siege requires zlib support to enable it: No such file or directory ** SIEGE 4.0.2 ** Preparing 250 concurrent users for battle. The server is now under siege...
Verificar a distribuição de carga
Agora que o siege está em execução, é hora de verificar se o tráfego está sendo distribuído igualmente para os grupos gerenciados de instâncias nas regiões leste e oeste. Além disso, confira se o espelhamento de tráfego está funcionando e se o tráfego está sendo enviado para o grupo de instâncias gerenciadas central.
No menu de navegação do console do Cloud, clique em Serviços de rede > Balanceamento de carga. Selecione o balanceador de carga web-map-http. Navegue até a guia "Monitoramento" para consultar o gráfico abaixo.
Será possível ver a divisão de tráfego nesse MIG em tempo real. O tráfego é dividido uniformemente, já que você configurou uma divisão Round Robbin de 50/50.
Para confirmar se a política de espelhamento de tráfego que você criou está funcionando, é necessário verificar a utilização do grupo gerenciado de instâncias central-backend-service. Para isso, acesse "Compute", "Compute Engine", "Grupos de instâncias" e selecione "us-central1-mig". Em seguida, acesse a guia de monitoramento.
Os gráficos serão preenchidos, demonstrando que o tráfego foi espelhado no grupo gerenciado de instâncias.
Interrompa o Cerco
Agora que você demonstrou que a divisão avançada de tráfego está funcionando, é hora de interromper o cerco. Para isso, retorne ao terminal SSH de siege-vm e pressione CTRL+C para interromper a execução do siege.
Validar o cabeçalho de resposta sendo enviado
Antes da limpeza, é possível validar rapidamente se o cabeçalho de resposta apropriado está sendo enviado pelo balanceador de carga http. Ele foi configurado para enviar o teste de cabeçalho com valor de conteúdo. Executar o comando curl no Cloud Shell vai gerar a resposta esperada.
No Cloud Shell
curl -svo /dev/null http://lb-ipv4-2/roundrobbin
Saída
* Trying lb-ipv4-2..
* TCP_NODELAY set
* Connected to lb-ipv4-2 ( lb-ipv4-2) port 80 (#0)
> GET /roundrobbin HTTP/1.1
> Host: lb-ipv4-2
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Nov 2021 17:05:27 GMT
< server: envoy
< Content-Length: 273
< content-type: text/html; charset=iso-8859-1
< via: 1.1 google
< test: value
<
{ [273 bytes data]
* Connection #0 to host 34.149.2.26 left intact
* Closing connection 0
7. Limpeza do laboratório
Agora que concluímos o ambiente do laboratório, é hora de desmontá-lo. Execute os comandos a seguir para excluir o ambiente de teste.
No Cloud Shell
gcloud compute instances delete siege-vm --zone=us-east4-c gcloud compute forwarding-rules delete http-content-rule --global gcloud compute target-http-proxies delete http-lb-proxy-adv gcloud compute url-maps delete web-map-http gcloud compute backend-services delete east-backend-service --global gcloud compute backend-services delete west-backend-service --global gcloud compute backend-services delete central-backend-service --global gcloud compute addresses delete lb-ipv4-2 --global gcloud compute health-checks delete http-basic-check gcloud compute instance-groups managed delete us-east1-mig --zone us-east1-b gcloud compute instance-groups managed delete us-west1-mig --zone us-west1-a gcloud compute instance-groups managed delete us-central1-mig --zone us-central1-a gcloud compute instance-templates delete "us-east1-template" gcloud compute instance-templates delete "us-west1-template" gcloud compute instance-templates delete "us-central1-template" gcloud compute firewall-rules delete httplb-allow-http-rule gcloud compute firewall-rules delete fw-allow-ssh gcloud compute networks delete httplbs
8. Parabéns!
Você concluiu o codelab de HTTPs externos com gerenciamento de tráfego avançado (Envoy).
O que vimos
- Como configurar um grupo gerenciado de instâncias, a VPC associada e as regras de firewall
- Como usar os recursos avançados de gerenciamento de tráfego do novo balanceador de carga
- Como validar se os recursos avançados de gerenciamento de tráfego estão funcionando conforme o esperado.
Próximas etapas
- Experimente alguns dos outros recursos de roteamento avançados, como reescrever URLs, adicionar cabeçalhos CORS e muito mais ( link).