Private Service Connect com configuração de DNS automática

1. Introdução

O Private Service Connect com configuração automática de DNS usa o Diretório de serviços e o Cloud DNS para criar registros DNS automaticamente 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 mostrado na Figura 1.

O DNS automático é possível com o seguinte:

1. O anexo de serviço do produtor origina o DNS automático fornecendo um domínio público de propriedade com a flag "– domain-names" ao criar o anexo de serviço do Private Service Connect.
2. O consumidor define um nome de endpoint.
3. O DNS automático cria uma zona DNS goog-psc-default-us-central1 e um nome 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 é 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.

Observação:o codelab oferece etapas de configuração e validação com base na topologia ilustrada. Modifique o procedimento conforme necessário para atender aos requisitos da sua organização. As permissões do IAM não estão no escopo do codelab.

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 o DNS automático

O que é necessário

• Projeto do Google Cloud
• Um domínio público que você possui

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 do 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 produtor

Criar a VPC do produtor

No Cloud Shell, faça o seguinte:

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

Criar 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

Observação:o uso de SHARED_VIP não é compatível com o Private Service Connect. Use GCE_ENDPOINT.

Conferir o endereço IP alocado

Use o comando compute addresses describe para conferir o endereço IP alocado.

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

Criar as sub-redes de proxy regionais

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

1. Um cliente estabelece uma conexão com o endereço IP e a porta da regra de encaminhamento do balanceador de carga.
2. 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.
3. O proxy estabelece uma conexão com a VM de back-end adequada, conforme determinado pelos serviços de back-end e o mapa de URL do balanceador de carga.

É necessário criar sub-redes somente proxy, mesmo que sua rede VPC esteja 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 mais curto. 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

Criar 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 regular 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

Criar as regras de firewall do produtor

Configure as regras de firewall para permitir o tráfego entre a sub-rede NAT do Private Service Connect e a sub-rede somente 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 (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

Cloud Router e configuração NAT

O Cloud NAT é usado no codelab para a 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 da 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 próxima seção, você vai criar a instância do Compute Engine e o grupo de instâncias não gerenciadas. Nas etapas seguintes, 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 recebidas para o 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. Anote a verificação de integridade bem-sucedida no serviço de back-end

A seleção de "l7-ilb-map" gera o endereço IP do front-end, que precisa corresponder ao endereço IP que você pesquisou em uma etapa anterior, e identifica o serviço de back-end.

5. Criar o anexo do serviço do Private Service Connect

Observação:se você especificar um nome de domínio, ele será usado para configurar automaticamente entradas de DNS particular para seus serviços na rede VPC do consumidor de serviço. É preciso ser um proprietário verificado do nome de domínio que está sendo especificado. A publicação do serviço vai falhar se você não for o proprietário do domínio. Clique em "Verificar domínio" para ver e configurar a propriedade do domínio. Na sintaxe abaixo, cosmopup.net é usado como o nome de domínio. Atualize a configuração com um domínio público autorizado que você tenha.

Criar o anexo do serviço

No Cloud Shell, crie o anexo de serviço. Adicione o "." no final do nome de 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.

Navegue até Serviços de rede → Private Service Connect para conferir o anexo de serviço recém-estabelecido.

A seleção de published-service fornece mais detalhes, incluindo o URI do anexo de serviço usado pelo consumidor para estabelecer uma conexão de serviço privada e 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 do consumidor

No Cloud Shell, faça o seguinte:

gcloud services enable dns.googleapis.com
gcloud services enable servicedirectory.googleapis.com

Criar a rede VPC do consumidor

No Cloud Shell, faça o seguinte:

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

Criar 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 a conexão do Private Service Connect foi bem-sucedida acessando Serviços de rede → Private Service Connect → Endpoints conectados. Observe a conexão do stargazer estabelecida e o endereço IP correspondente que criamos anteriormente.

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

8. Valide a conexão na rede VPC do produtor

Na rede VPC do produtor, verifique se a conexão de serviço particular foi bem-sucedida acessando 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. Validar 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

Navegue até Serviços de rede → Cloud DNS → Zonas. A zona goog-psc-default-us-central & e o nome de DNS cosmopup.net são gerados automaticamente.

Conferir a configuração do DNS e do Diretório de serviços

A seleção do nome da zona permite que a integração do Diretório de serviços com o Cloud DNS seja verificada.

Configuração do Diretório de serviços

Acesse Serviços de rede → Diretório de serviços.

Lembra do nome do endpoint do consumidor stargazer? Ele é programado automaticamente no Diretório de serviços, permitindo que alcancemos o endpoint do consumidor usando o FQDN stargazer.goog-psc-default–us-central1.

10. Validar o acesso do consumidor ao serviço do produtor

Na rede VPC do consumidor, vamos criar 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 suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias da VM que você quer que sejam acessíveis usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o 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 VM do consumidor usando o IAP no Cloud Shell para validar a conectividade com o serviço do produtor executando um curl. Tente novamente se houver um tempo limite.

gcloud compute ssh db1 --project=$projectname --zone=us-central1-a --tunnel-through-iap

Execute um curl que valida a conectividade com o serviço do produtor. Depois de validar, saia da VM e volte ao prompt do Cloud Shell.

No Cloud Shell, execute um curl no seu domínio personalizado, por exemplo, stargazer.[custom-domain.com]. Na saída 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 volte ao prompt do Cloud Shell para iniciar as tarefas de limpeza.

11. Limpar

No Cloud Shell, exclua os componentes do codelab.

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 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 de consumidor na rede VPC do consumidor que permitia a conectividade ao serviço local usando o DNS gerado automaticamente.

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 on-prem por rede híbrida usando o Private Service Connect e um balanceador de carga do proxy TCP interno

Leituras e vídeos complementares

• Visão geral do Private Service Connect
• O que é o Private Service Connect?
• Tipos de balanceadores de carga compatíveis

Documentos de referência

• Visão geral do balanceador de carga HTTP(S) interno
• Visão geral das verificações de integridade
• Como publicar um serviço usando o Private Service Connect
• Private Service Connect: DNS automático