1. Introdução
O Private Service Connect com configuração de DNS automática usa o Diretório de serviços e o Cloud DNS para criar automaticamente registros DNS programados com os endereços IP do endpoint do Private Service Connect do consumidor.
O que você vai criar
Neste codelab, você vai criar uma arquitetura abrangente do Private Service Connect que ilustra o uso do DNS automático, conforme ilustrado na Figura 1.
O DNS automático é possível graças ao seguinte:
- O anexo do serviço do produtor origina o DNS automático ao fornecer um domínio público próprio com o "– nomes de domínio" flag ao criar o anexo de serviço do Private Service Connect.
- O consumidor define um nome de endpoint.
- O DNS automático cria uma Zona DNS goog-psc-default-us-central1 e um Nome do DNS cosmopup.net, além de uma entrada do Diretório de serviços que consiste no nome do endpoint do consumidor.
O benefício do DNS automático está ilustrado em (4), em que um usuário final pode se comunicar com o endpoint do consumidor pelo DNS, FQDN stargazer.cosmopup.net.
Figura 1.
O que você vai aprender
- Como criar um balanceador de carga HTTP(S) interno
- Como criar um anexo de serviço com DNS automático
- Como estabelecer um serviço de produtor do Private Service Connect
- Como acessar um endpoint do consumidor usando DNS automático
O que é necessário
- Projeto do Google Cloud
- Um domínio público de sua propriedade
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]
projectname=YOUR-PROJECT-NAME
echo $projectname
3. Configuração do Producer
Criar a VPC do produtor
No Cloud Shell, faça o seguinte:
gcloud compute networks create producer-vpc --project=$projectname --subnet-mode=custom
Crie as sub-redes do produtor
No Cloud Shell, faça o seguinte:
gcloud compute networks subnets create gce-subnet --project=$projectname --range=172.16.20.0/28 --network=producer-vpc --region=us-central1
No Cloud Shell, faça o seguinte:
gcloud compute networks subnets create load-balancer-subnet --project=$projectname --range=172.16.10.0/28 --network=producer-vpc --region=us-central1
Reservar um endereço IP para o balanceador de carga interno
No Cloud Shell, faça o seguinte:
gcloud compute addresses create lb-ip \
--region=us-central1 \
--subnet=load-balancer-subnet \
--purpose=GCE_ENDPOINT
Conferir o endereço IP alocado
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 rede 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 a VM de back-end apropriada, determinada pelo mapa de URL e pelos serviços de back-end do balanceador de carga.
É preciso criar sub-redes somente proxy, independentemente de a rede VPC estar no modo automático ou personalizado. 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 \
--project $projectname \
--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 a sub-rede NAT do Private Service Connect e a sub-rede somente de proxy do ILB.
No Cloud Shell, faça o seguinte:
gcloud compute --project=$projectname 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
No Cloud Shell, crie a regra de firewall fw-allow-health-check para permitir que as verificações de integridade do Google Cloud alcancem o serviço de produtor (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 na sub-rede somente proxy para que o balanceador de carga se comunique com as 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
Configuração do Cloud Router e do NAT
O Cloud NAT é usado neste codelab para instalação de pacotes de software, já que a instância de VM não tem um endereço IP externo.
No Cloud Shell, crie o roteador de nuvem.
gcloud compute routers create cloud-router-for-nat --network producer-vpc --region us-central1
No Cloud Shell, crie o gateway NAT.
gcloud compute routers nats create cloud-nat-us-central1 --router=cloud-router-for-nat --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1
Configuração do grupo de instâncias
Na seção a seguir, você vai criar a instância do Compute Engine e um grupo de instâncias não gerenciadas. Nas etapas posteriores, o grupo de instâncias será usado como o serviço de back-end do balanceador de carga.
No Cloud Shell, crie a verificação de integridade regional transmitida ao serviço do produtor.
gcloud compute instances create app-server-1 \
--project=$projectname \
--machine-type=e2-micro \
--image-family debian-10 \
--no-address \
--image-project debian-cloud \
--zone us-central1-a \
--subnet=gce-subnet \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo 'Welcome to App-Server-1 !!' | tee /var/www/html/index.html
EOF"
No Cloud Shell, crie o grupo de instâncias não gerenciadas.
gcloud compute instance-groups unmanaged create psc-instance-group --zone=us-central1-a
gcloud compute instance-groups unmanaged set-named-ports psc-instance-group --project=$projectname --zone=us-central1-a --named-ports=http:80
gcloud compute instance-groups unmanaged add-instances psc-instance-group --zone=us-central1-a --instances=app-server-1
Configurar o balanceador de carga
Nas etapas a seguir, você vai configurar o balanceador de carga HTTP interno que será publicado como um anexo de serviço em uma etapa posterior
No Cloud Shell, crie a verificação de integridade regional.
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.
gcloud compute backend-services create l7-ilb-backend-service \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=HTTP \
--health-checks=http-health-check \
--health-checks-region=us-central1 \
--region=us-central1
No Cloud Shell, adicione back-ends ao serviço de back-end.
gcloud compute backend-services add-backend l7-ilb-backend-service \
--balancing-mode=UTILIZATION \
--instance-group=psc-instance-group \
--instance-group-zone=us-central1-a \
--region=us-central1
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 l7-ilb-map \
--default-service l7-ilb-backend-service \
--region=us-central1
Crie o proxy de destino HTTP.
gcloud compute target-http-proxies create l7-ilb-proxy\
--url-map=l7-ilb-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 l7-ilb-forwarding-rule \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=load-balancer-subnet \
--address=lb-ip \
--ports=80 \
--region=us-central1 \
--target-http-proxy=l7-ilb-proxy \
--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. Observar a verificação de integridade bem-sucedida no serviço de back-end
Selecionar ‘l7-ilb-map' gera o endereço IP do front-end, que deve corresponder ao endereço IP que você gerou em uma etapa anterior e identifica o serviço de back-end.
5. Criar o anexo de serviço do Private Service Connect
Crie o anexo de serviço
No Cloud Shell, crie o anexo de serviço. Não se esqueça de adicionar o caractere "." ao final do nome do domínio.
gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet --domain-names=cosmopup.net.
Opcional: se estiver usando uma VPC compartilhada, crie o anexo de serviço no projeto de serviço.
gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/us-central1/subnetworks/psc-nat-subnet --domain-names=cosmopup.net.
Acesse Serviços de rede → Private Service Connect para conferir o anexo de serviço recém-criado
Selecionar published-service fornece mais detalhes, incluindo o URI do anexo de serviço usado pelo consumidor para estabelecer uma conexão de serviço particular. o nome de domínio.
Detalhes do anexo de serviço:
projects/<nome do projeto>/regions/us-central1/serviceAttachments/published-service
6. Configuração do consumidor
Ativar APIs de consumidor
No Cloud, o Shell executa o seguinte:
gcloud services enable dns.googleapis.com
gcloud services enable servicedirectory.googleapis.com
Crie a rede VPC do consumidor
No Cloud Shell, faça o seguinte:
gcloud compute networks create consumer-vpc --project=$projectname --subnet-mode=custom
Crie as sub-redes do consumidor
No Cloud Shell, crie a sub-rede para a instância de teste.
gcloud compute networks subnets create db1-subnet --project=$projectname --range=10.20.0.0/28 --network=consumer-vpc --region=us-central1
No Cloud Shell, crie uma sub-rede para o endpoint do consumidor.
gcloud compute networks subnets create consumer-ep-subnet --project=$projectname --range=10.10.0.0/28 --network=consumer-vpc --region=us-central1
Criar o endpoint do consumidor (regra de encaminhamento)
No Cloud Shell, crie o endereço IP estático que será usado para o endpoint do consumidor.
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=consumer-ep-subnet --addresses 10.10.0.10
Usamos o URI do anexo de serviço gerado anteriormente para criar o endpoint do consumidor.
No Cloud Shell, crie o endpoint do consumidor.
gcloud compute forwarding-rules create stargazer --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$projectname/regions/us-central1/serviceAttachments/published-service
7. Validar a conexão na rede VPC do consumidor
Na rede VPC do consumidor, verifique se está tudo certo com o Private Service Connect. Para isso, acesse Serviços de rede → Private Service Connect→ Endpoints conectados. Anote a conexão stargazer 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
8. Validar a conexão na rede VPC do produtor
Na rede VPC do produtor, verifique se há uma conexão de serviço particular bem-sucedida navegando até Serviços de rede → Private Service Connect→Serviço publicado. A conexão de serviço publicada agora indica uma regra de encaminhamento (endpoint de conexão).
9. Valide a configuração automática de DNS
Vamos avaliar a configuração do DNS e do diretório de serviços.
Configuração do Cloud DNS
Acesse Serviços de rede → Cloud DNS → Zonas. O nome DNS da zona goog-psc-default-us-central & cosmopup.net. é gerado automaticamente.
Ver a configuração do DNS e do diretório de serviços
Selecionar o nome da zona nos permite ver como o Diretório de serviços está integrado ao Cloud DNS.
Configuração do Diretório de serviços
Acesse Serviços de rede → Diretório de serviços
Você se lembra do nome de endpoint do consumidor "stargazer"? Ele é programado automaticamente no Diretório de serviços, o que nos permite alcançar o endpoint do consumidor usando o FQDN stargazer.goog-psc-default–us-central1
10. Validar o acesso do consumidor ao serviço de produtores
Na rede VPC do consumidor, criaremos uma VM para testar a conectividade do serviço publicado acessando o endpoint do consumidor stargazer.cosmopup.net
No Cloud Shell, crie a instância de teste na VPC do consumidor.
gcloud compute instances create db1 \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=db1-subnet \
--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 regra de firewall do IAP.
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 instância "consumer-vm" usando o IAP no Cloud Shell para validar a conectividade com o serviço do produtor usando um curl. Tente de novo se houver um tempo limite.
gcloud compute ssh db1 --project=$projectname --zone=us-central1-a --tunnel-through-iap
Execute um curl validando a conectividade com o serviço do produtor. Depois da validação, saia da VM e retorne ao prompt do Cloud Shell.
No Cloud Shell, execute um curl no seu domínio personalizado, por exemplo, stargazer.[custom-domain.com]. No resultado abaixo, um curl é realizado em stargazer.cosmopup.net
user@db1:~$ curl -v stargazer.cosmopup.net
* Trying 10.10.0.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d3aa8190f0)
* Connected to stargazer.cosmopup.net (10.10.0.10) port 80 (#0)
> GET / HTTP/1.1
> Host: stargazer.cosmopup.net
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Thu, 22 Dec 2022 00:16:25 GMT
< server: Apache/2.4.38 (Debian)
< last-modified: Wed, 21 Dec 2022 20:26:32 GMT
< etag: "1b-5f05c5e43a083"
< accept-ranges: bytes
< content-length: 27
< content-type: text/html
< via: 1.1 google
<
Welcome to App-Server-1 !!
Saia da VM e retorne ao comando do Cloud Shell para iniciar as tarefas de limpeza
11. Limpar
Exclua os componentes do codelab no Cloud Shell.
gcloud compute forwarding-rules delete stargazer --region=us-central1 --quiet
gcloud compute instances delete db1 --zone=us-central1-a --quiet
gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet
gcloud compute networks subnets delete consumer-ep-subnet db1-subnet --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap-consumer --quiet
gcloud compute networks delete consumer-vpc --quiet
gcloud compute service-attachments delete published-service --region=us-central1 --quiet
gcloud compute forwarding-rules delete l7-ilb-forwarding-rule --region=us-central1 --quiet
gcloud compute target-http-proxies delete l7-ilb-proxy --region=us-central1 --quiet
gcloud compute url-maps delete l7-ilb-map --region=us-central1 --quiet
gcloud compute backend-services delete l7-ilb-backend-service --region=us-central1 --quiet
gcloud compute instance-groups unmanaged delete psc-instance-group --zone=us-central1-a --quiet
gcloud compute instances delete app-server-1 --zone=us-central1-a --quiet
gcloud compute firewall-rules delete allow-to-ingress-nat-subnet fw-allow-health-check fw-allow-proxy-only-subnet --quiet
gcloud compute addresses delete lb-ip --region=us-central1 --quiet
gcloud compute networks subnets delete gce-subnet load-balancer-subnet psc-nat-subnet proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute routers delete cloud-router-for-nat --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
12. Parabéns
Parabéns, você configurou e validou um endpoint do Private Service Connect com configuração de DNS automática.
Você criou a infraestrutura do produtor e adicionou um anexo de serviço com registro de domínio público. Você aprendeu a criar um endpoint do consumidor na rede VPC dele que permitisse a conectividade com o serviço local usando DNS gerado automaticamente.
A Cosmopup acha que os codelabs são incríveis!
Qual é a próxima etapa?
Confira alguns destes codelabs:
- Como usar o Private Service Connect para publicar e consumir serviços com o GKE
- Como usar o Private Service Connect para publicar e consumir serviços
- Conectar-se a serviços no local por uma rede híbrida usando o Private Service Connect e um balanceador de carga de proxy TCP interno
Leia mais e Vídeos
- Visão geral do Private Service Connect
- O que é o Private Service Connect?
- Tipos de balanceador de carga compatíveis