Esta página foi traduzida pela API Cloud Translation.

Conectar-se a serviços locais por uma rede híbrida usando o Private Service Connect e o NEG híbrido com balanceador de carga HTTP(s) interno

1. Introdução

O Cloud Load Balancing é compatível com tráfego de balanceamento de carga para endpoints que se estendem além do Google Cloud, como data centers no local e outras nuvens públicas que podem ser alcançadas pela conectividade híbrida.

Uma estratégia híbrida é uma solução pragmática para você se adaptar às demandas do mercado em constante mudança e modernizar gradualmente seus aplicativos. Pode ser uma implantação híbrida temporária para permitir a migração para uma solução moderna baseada na nuvem ou uma instalação permanente da infraestrutura de TI da sua organização.

Ao configurar o balanceamento de carga híbrido, você também pode aproveitar os benefícios dos recursos de rede do Cloud Load Balancing para os serviços em execução na sua infraestrutura fora do Google Cloud.

Se você quiser disponibilizar o serviço híbrido em outras redes VPC, use o Private Service Connect para publicar o serviço. Ao colocar um anexo de serviço na frente do balanceador de carga HTTP(S) regional interno,é possível permitir que os clientes em outras redes VPC acessem os serviços híbridos em execução no local ou em outros ambientes de nuvem.

O que você vai criar

Neste codelab, você vai criar um balanceador de carga HTTP(S) interno com conectividade híbrida para um serviço no local usando um grupo de endpoints de rede. A VPC do consumidor poderá se comunicar com o serviço no local usando as portas 80. A porta 443 não está no escopo do codelab.

O que você vai aprender

Como criar um balanceador de carga HTTP(S) interno com um back-end de NEG híbrido
Como estabelecer um produtor do Private Service Connect (anexo de serviço) e um consumidor (regra de encaminhamento)

O que é necessário

Rede híbrida estabelecida, por exemplo, VPN de alta disponibilidade, interconexão, SW-WAN
Projeto do Google Cloud

Estabelecer conectividade híbrida

Seu Google Cloud e ambientes locais ou de outras nuvens precisam estar conectados por conectividade híbrida, usando anexos da VLAN do Cloud Interconnect ou túneis do Cloud VPN com o Cloud Router. Recomendamos que você use uma conexão de alta disponibilidade.

Um Cloud Router ativado com roteamento dinâmico global aprende sobre o endpoint específico por meio do BGP e o programa na rede VPC do Google Cloud. O roteamento dinâmico regional não é compatível. Rotas estáticas também não são compatíveis.

A rede VPC do Google Cloud usada para configurar o Cloud Interconnect ou o Cloud VPN é a mesma usada para configurar a implantação do balanceamento de carga híbrido. Verifique se os intervalos CIDR da sub-rede da sua rede VPC não entram em conflito com os intervalos CIDR remotos. Quando os endereços IP se sobrepõem, as rotas de sub-rede são priorizadas em relação à conectividade remota.

Para instruções, consulte:

Divulgações de rota personalizadas

As sub-redes abaixo exigem divulgações personalizadas do Cloud Router para a rede local, garantindo que as regras de firewall no local sejam atualizadas.

Sub-rede	Descrição
172.16.0.0/23	Sub-rede de proxy usada para comunicação direta com o serviço local
130.211.0.0/22, 35.191.0.0/16	Verificação de integridade do Google Cloud

2. Antes de começar

Atualizar o projeto para oferecer suporte ao codelab

Este codelab usa $variables para ajudar na implementação da configuração da gcloud no Cloud Shell.

No Cloud Shell, faça o seguinte:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Configuração do Producer

Crie a VPC do produtor

No Cloud Shell, faça o seguinte:

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Crie as sub-redes do Producer

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

Reservar um endereço IP para o balanceador de carga interno

No Cloud Shell, faça o seguinte. O uso de SHARED_VIP não é compatível com o Private Service Connect. Em vez disso, use GCE_ENDPOINT

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

Use o comando compute addresses describe para consultar o endereço IP alocado

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

Crie as sub-redes de proxy regionais

A alocação de proxy é feita no nível da VPC, não no nível do balanceador de carga. É preciso criar uma sub-rede somente proxy em cada região de uma rede virtual (VPC) em que você usa balanceadores de carga baseados no Envoy. Se você implantar vários balanceadores de carga na mesma região e na mesma rede VPC, eles vão compartilhar a mesma sub-rede somente proxy para balanceamento de carga.

Um cliente estabelece uma conexão com o endereço IP e a porta da regra de encaminhamento do balanceador de carga.
Cada proxy detecta o endereço IP e a porta especificados pela regra de encaminhamento do balanceador de carga correspondente. Um dos proxies recebe e encerra a conexão de rede do cliente.
O proxy estabelece uma conexão com o endpoint ou a VM de back-end apropriados em um NEG, conforme determinado pelos serviços de back-end e mapa de URL do balanceador de carga.

É preciso criar sub-redes somente proxy, independentemente de sua rede estar no modo automático ou personalizada. Uma sub-rede somente proxy precisa fornecer 64 ou mais endereços IP. Isso corresponde a um comprimento de prefixo de /26 ou menos. O tamanho de sub-rede recomendado é /23 (512 endereços somente proxy).

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Crie as sub-redes NAT do Private Service Connect

Crie uma ou mais sub-redes dedicadas para usar com o Private Service Connect. Se você estiver usando o console do Google Cloud para publicar um serviço, poderá criar as sub-redes durante esse procedimento. Crie a sub-rede na mesma região do balanceador de carga do serviço. Não é possível converter uma sub-rede normal em uma sub-rede do Private Service Connect.

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Crie as regras de firewall do produtor

Configure regras de firewall para permitir o tráfego entre os endpoints do Private Service Connect e o anexo de serviço. No codelab, criamos uma regra de firewall de entrada que permite que a sub-rede NAT 100.100.10.0/24 acesse o anexo de serviço do Private Service Connect (balanceador de carga interno).

No Cloud Shell, faça o seguinte:

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

Dentro do Cloud Shell. Crie a regra fw-allow-health-check para permitir que as verificações de integridade do Google Cloud alcancem o serviço local (serviço de back-end) na porta TCP 80

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

Crie uma regra de permissão de entrada de firewall para a sub-rede somente proxy para permitir que o balanceador de carga se comunique com instâncias de back-end na porta TCP 80

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Configurar o NEG de conectividade híbrida

Ao criar o NEG,use uma ZONA que minimize a distância geográfica entre o Google Cloud e seu ambiente local ou outro ambiente de nuvem. Por exemplo, se você estiver hospedando um serviço em um ambiente local em Frankfurt, na Alemanha, poderá especificar a zona europe-west3-a do Google Cloud ao criar o NEG.

Além disso, se você estiver usando o Cloud Interconnect, a ZONA usada para criar o NEG precisará estar na mesma região em que o anexo do Cloud Interconnect foi configurado.

Para conhecer as regiões e zonas disponíveis, consulte a documentação do Compute Engine: regiões e zonas disponíveis.

No Cloud Shell, crie um NEG de conectividade híbrida usando o comando gcloud compute network-endpoint-groups create

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

No Cloud Shell, adicione o endpoint IP:porta local ao NEG híbrido.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Configurar o balanceador de carga

Nas etapas a seguir, você vai configurar o balanceador de carga (regra de encaminhamento) e associar ao grupo de endpoints de rede

No Cloud Shell, crie a verificação de integridade regional transmitida ao serviço no local

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

No Cloud Shell, crie o serviço de back-end para o back-end no local, aproveitando o NEG híbrido

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

No Cloud Shell, adicione o back-end de NEG híbrido ao serviço de back-end. Para TAXA, insira a TAXA máxima que o back-end deve gerenciar.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

No Cloud Shell, crie o mapa de URL para encaminhar as solicitações de entrada ao serviço de back-end

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

Crie o proxy de destino HTTP

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-map \
    --url-map-region=us-central1 \
    --region=us-central1

Crie uma regra de encaminhamento para encaminhar as solicitações recebidas para o proxy. Não use a sub-rede somente proxy para criar a regra de encaminhamento.

 gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --target-http-proxy-region=us-central1

4. Validar o balanceador de carga

No Console do Cloud, acesse Serviços de rede → Balanceamento de carga → Balanceadores de carga. Observe que o 1 NEG é "Verde" indicando uma verificação de integridade bem-sucedida para o serviço local

A seleção de ‘on-premise-svc-url-map' gera o endereço IP do front-end e identifica o serviço de back-end

5. Conferir as rotas aprendidas no local

Acesse Rede VPC → Rotas. A sub-rede de serviço local aprendida 192.168.1.0/27

6. Validar a conectividade com o serviço local

Na VPC dos produtores, vamos criar uma VM para testar a conectividade com o serviço no local. Depois disso, o anexo de serviço será a próxima configuração.

No Cloud Shell, crie a instância de teste na VPC do produtor

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

Para permitir que o IAP se conecte às instâncias de VM, crie uma regra de firewall que:

Aplica-se a todas as instâncias de VM que você quer disponibilizar usando o IAP.
Permite tráfego de entrada no intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para encaminhamento de TCP.

No Cloud Shell, crie a instância de teste na VPC do produtor

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Faça login em test-box-us-central1 usando o IAP no Cloud Shell para validar a conectividade com o serviço local. Para isso, execute um curl no endereço IP do balanceamento de carga. Tente de novo se houver um tempo limite.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Execute um curl validando a conectividade com o serviço no local. Depois de validar, saia da VM e volte ao prompt do Cloud Shell. Substitua o IP do balanceador de carga interno com base na saída identificada na etapa 4.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

7. Criar o anexo de serviço do Private Service Connect

Nas etapas a seguir, vamos criar o anexo de serviço. Quando pareado com um endpoint do consumidor, o acesso ao serviço no local é feito sem a necessidade de peering de VPC.

Criar o anexo de serviço

No Cloud Shell, crie o anexo de serviço

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

Opcional: se você estiver usando uma VPC compartilhada, crie o anexo de serviço no projeto de serviço

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

Valide o anexo de serviço TCP

gcloud compute service-attachments describe service-1 --region us-central1

Opcional: acesse Serviços de rede → Private Service Connect para conferir o anexo de serviço recém-criado

Selecionar Service-1 oferece mais detalhes, incluindo o URI do anexo de serviço usado pelo consumidor para estabelecer uma conexão de serviço particular. Anote o URI, porque ele será usado em uma etapa posterior.

Detalhes do anexo de serviço:projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. Configuração do consumidor

Crie a VPC do consumidor

No Cloud Shell, faça o seguinte:

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Crie as sub-redes do consumidor

No Cloud Shell, crie a sub-rede do GCE

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

Dentro do Cloud Shell, crie a sub-rede do endpoint do consumidor

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Crie o endpoint do consumidor (regra de encaminhamento)

No Cloud Shell, crie o endereço IP estático que será usado como um endpoint do consumidor

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Vamos usar o URI do anexo de serviço gerado anteriormente para criar o endpoint do consumidor

Dentro do Cloud Shell, crie o endpoint do consumidor

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. Validar o Consumer Private Service Connect - VPC de consumidor

Na VPC do consumidor, verifique se o Private Service Connect foi bem-sucedido navegando até Serviços de rede → Private Service Connect→ Endpoints conectados. Observe a conexão psc-consumer-1 estabelecida e o endereço IP correspondente que criamos anteriormente.

Ao selecionar psc-consumer-1, são fornecidos detalhes, incluindo o URI do anexo de serviço

10. Validar o Consumer Private Service Connect - VPC do produtor

Na VPC do produtor, verifique uma conexão de serviço particular bem-sucedida navegando até Serviços de rede → Private Service Connect→Serviço publicado. A conexão service-1 publicada agora indica uma regra de encaminhamento (endpoint de conexão).

11. Criar uma zona DNS particular e Registro A

Crie a zona de DNS particular mapeada para o endpoint de conexão do PSC, permitindo acesso contínuo ao produtor de qualquer host na VPC.

No Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. Validar o acesso do consumidor ao serviço de produtores usando a VM

Na VPC Consumers, vamos criar uma VM para testar a conectividade com o serviço no local acessando o endpoint do consumidor service1.codelabs.net

No Cloud Shell, crie a instância de teste na VPC do consumidor

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

Para permitir que o IAP se conecte às instâncias de VM, crie uma regra de firewall que:

Aplica-se a todas as instâncias de VM que você quer disponibilizar usando o IAP.
Permite tráfego de entrada no intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para encaminhamento de TCP.

No Cloud Shell, crie a instância de teste na VPC do consumidor

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Faça login na VM do consumidor usando o IAP no Cloud Shell para validar a conectividade com o serviço local executando um curl no FQDN do DNS service1.codelab.net. Tente de novo se houver um tempo limite.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

Execute um curl validando a conectividade com o serviço no local. Após a validação, saia da VM e retorne ao prompt do Cloud Shell.

Dentro do Cloud Shell, execute um curl

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Veja abaixo um exemplo de captura do serviço local. O endereço IP de origem 172.16.0.13 é do intervalo da sub-rede do proxy 172.16.0.0/23

13. Limpeza do produtor

Excluir componentes do Producer

No Cloud Shell, exclua as instâncias de teste na VPC do produtor

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. Limpeza do consumidor

Excluir componentes do consumidor

No Cloud Shell, exclua as instâncias de teste na VPC do consumidor

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet

15. Parabéns

Parabéns, você configurou e validou com sucesso o Private Service Connect com um balanceador de carga HTTP(S) interno.

Você criou a infraestrutura do produtor e adicionou um anexo de serviço à VPC do produtor que aponta para um serviço no local. Você aprendeu a criar um endpoint na VPC do consumidor que permite a conectividade com o serviço no local.

Qual é a próxima etapa?

Confira alguns destes codelabs:

Conectar-se a serviços locais por uma rede híbrida usando o Private Service Connect e o NEG híbrido com balanceador de carga HTTP(s) interno

1. Introdução

O que você vai criar

O que você vai aprender

O que é necessário

Estabelecer conectividade híbrida

Divulgações de rota personalizadas

2. Antes de começar

Atualizar o projeto para oferecer suporte ao codelab

3. Configuração do Producer

Crie a VPC do produtor

Crie as sub-redes do Producer

Reservar um endereço IP para o balanceador de carga interno

Use o comando compute addresses describe para consultar o endereço IP alocado

Crie as sub-redes de proxy regionais

Crie as sub-redes NAT do Private Service Connect

Crie as regras de firewall do produtor

Configurar o NEG de conectividade híbrida

Configurar o balanceador de carga

4. Validar o balanceador de carga

5. Conferir as rotas aprendidas no local

6. Validar a conectividade com o serviço local

7. Criar o anexo de serviço do Private Service Connect

Criar o anexo de serviço

8. Configuração do consumidor

Crie a VPC do consumidor

Crie as sub-redes do consumidor

Crie o endpoint do consumidor (regra de encaminhamento)

9. Validar o Consumer Private Service Connect - VPC de consumidor

10. Validar o Consumer Private Service Connect - VPC do produtor

11. Criar uma zona DNS particular e Registro A

12. Validar o acesso do consumidor ao serviço de produtores usando a VM

Veja abaixo um exemplo de captura do serviço local. O endereço IP de origem 172.16.0.13 é do intervalo da sub-rede do proxy 172.16.0.0/23

13. Limpeza do produtor

Excluir componentes do Producer

14. Limpeza do consumidor

Excluir componentes do consumidor

15. Parabéns

Qual é a próxima etapa?

Leia mais e Vídeos

Documentos de referência