NEG de Internet HTTPS no limite sul do Looker PSC

1. Introdução

OBSERVAÇÃO: o Looker oferece suporte a produtores Southbound em qualquer região. Para o acesso de entrada ao Looker, o endpoint do consumidor ou o back-end precisa estar na mesma região que a instância PSC do Looker.

Neste codelab, você vai realizar uma conexão HTTPS southbound ao GitHub usando um balanceador de carga de proxy TCP interno e um grupo de endpoint de rede da Internet (NEG, na sigla em inglês) invocado do PSC do Looker como consumidor de serviço.

O Private Service Connect é um recurso da rede do Google Cloud que permite que consumidores acessem serviços gerenciados de maneira particular na rede VPC deles. Da mesma forma, ele permite que produtores do serviço gerenciado hospedem esses serviços em redes VPC separadas e ofereçam uma conexão particular aos consumidores. Por exemplo, quando você usa o Private Service Connect para acessar o Looker, você é o consumidor de serviços e o Google é o produtor de serviços, conforme destacado na Figura 1.

Figura 1.

O acesso de ida, também conhecido como PSC reverso, permite que o consumidor crie um serviço publicado como produtor para permitir que o Looker acesse endpoints locais, em uma VPC, serviços gerenciados e a Internet. As conexões de saída podem ser implantadas em qualquer região, independentemente de onde o PSC do Looker está implantado, conforme destacado na Figura 2.

Figura 2.

O que você vai aprender

• Requisitos de rede
• Criar um serviço de produtor do Private Service Connect
• Criar um endpoint do Private Service Connect no Looker
• Estabelecer conectividade com o GitHub no Looker usando uma conexão de teste

O que é necessário

• Projeto do Google Cloud com permissões de proprietário
• Conta e repositório do GitHub
• Token de acesso pessoal do GitHub (clássico)
• Instância PSC do Looker

2. O que você vai criar

Você vai estabelecer uma rede de produtores, looker-psc-demo, para implantar o balanceador de carga de proxy TCP interno e o NEG da Internet publicado como um serviço pelo Private Service Connect (PSC). Após a publicação, você vai realizar as seguintes ações para validar o acesso ao serviço do produtor:

• Criar um endpoint do PSC no Looker associado ao anexo de serviço do produtor
• Use o console do Looker para criar um novo projeto e testar a conectividade HTTPS com o GitHub.com

3. Requisitos de rede

Confira abaixo os requisitos de rede para a rede do produtor. O consumidor neste codelab é a instância do PSC do Looker.

Componentes	Descrição
VPC (looker-psc-demo)	VPC de modo personalizado
Sub-rede NAT do PSC	Os pacotes da rede VPC do consumidor são convertidos usando a NAT de origem (SNAT) para que os endereços IP de origem sejam convertidos em endereços IP de origem da sub-rede NAT na rede VPC do produtor.
Sub-rede da regra de encaminhamento do PSC	Usado para alocar um endereço IP para o balanceador de carga de proxy TCP regional interno
Sub-rede PSC NEG	Usado para alocar um endereço IP para o grupo de endpoints de rede
Sub-rede somente proxy	Cada um dos proxies do balanceador de carga recebe um endereço IP interno. Os pacotes enviados de um proxy para um endpoint ou VM de back-end têm um endereço IP de origem da sub-rede somente proxy.
NEG da Internet	Um recurso usado para definir um back-end externo para o balanceador de carga. O endpoint não pode ser acessado apenas pelo Cloud VPN ou Cloud Interconnect.
Serviço de back-end	Um serviço de back-end atua como uma ponte entre o balanceador de carga e os recursos de back-end. No tutorial, o serviço de back-end é associado ao NEG da Internet.
Cloud Router	O Cloud NAT depende de Cloud Routers para recursos do plano de controle, mas não para o gerenciamento de sessões do BGP.
Cloud NAT	O NEG regional da Internet usa o Cloud NAT para saída da Internet.

4. Topologia do codelab

5. Configuração e requisitos

Configuração de ambiente autoguiada

1. 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. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
• O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
• Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Atenção: o ID do projeto é globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá ser usado novamente.

Observação: se você usa uma conta do Gmail, defina o local padrão como Sem organização. Se você usa uma conta do Google Workspace, escolha um local adequado para a organização.

2. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. 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 Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:

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. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.

6. Antes de começar

Ativar APIs

No Cloud Shell, verifique se o ID do projeto está configurado:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=[YOUR-REGION]
echo $project
echo $region

Ative todos os serviços necessários:

gcloud services enable compute.googleapis.com

7. Criar rede VPC do produtor

Rede VPC

No Cloud Shell, faça o seguinte:

gcloud compute networks create looker-psc-demo --subnet-mode custom

Criar sub-redes

A sub-rede do PSC será associada ao anexo de serviço PSC para fins de conversão de endereços de rede.

No Cloud Shell, crie a sub-rede NAT do PSC:

gcloud compute networks subnets create producer-psc-nat-subnet --network looker-psc-demo --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

No Cloud Shell, crie a sub-rede da regra de encaminhamento do produtor:

gcloud compute networks subnets create producer-psc-fr-subnet --network looker-psc-demo --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

No Cloud Shell, crie a sub-rede somente proxy regional do produtor:

gcloud compute networks subnets create $region-proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=looker-psc-demo \
  --range=10.10.10.0/24

Criar o gateway NAT público

O NAT Gateway é usado pelo balanceador de carga de proxy TCP interno regional para saída de Internet com a opção de configuração –endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB. Portanto, o mesmo NATGW não oferece suporte à saída de Internet do GCE/GKE. Implante um NAT GW adicional com –endpoint-types=ENDPOINT_TYPE_VM para a saída de Internet do GCE/GKE.

No Cloud Shell, crie o Cloud Router:

gcloud compute routers create looker-psc-demo-cloud-router --network looker-psc-demo --region $region

No Cloud Shell, crie o gateway do Cloud NAT para ativar a saída da Internet para o balanceador de carga de proxy TCP:

gcloud compute routers nats create looker-psc-demo-natgw \
  --router=looker-psc-demo-cloud-router \
  --endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB \
  --nat-custom-subnet-ip-ranges=$region-proxy-only-subnet \
  --auto-allocate-nat-external-ips \
  --region=$region

Reserve o endereço IP do balanceador de carga

No Cloud Shell, reserve um endereço IP interno para o balanceador de carga:

gcloud compute addresses create internet-neg-lb-ip \
  --region=$region \
  --subnet=producer-psc-fr-subnet

No Cloud Shell, confira o endereço IP reservado.

gcloud compute addresses describe internet-neg-lb-ip \
  --region=$region | grep -i address:

Exemplo de saída:

user@cloudshell$ gcloud compute addresses describe internet-neg-lb-ip   --region=$region | grep -i address:
address: 172.16.20.2

Configurar o NEG da Internet

Crie uma NEG na Internet e defina –network-endpoint-type como internet-fqdn-port (o nome do host e a porta em que seu back-end externo pode ser alcançado).

No Cloud Shell, crie um NEG da Internet usado para github.com

gcloud compute network-endpoint-groups create github-internet-neg \
    --network-endpoint-type=INTERNET_FQDN_PORT \
    --network=looker-psc-demo \
    --region=$region

OBSERVAÇÃO: fqdn=github.com,port=443 é necessário para oferecer suporte a HTTPS.

No Cloud Shell, atualize o NEG da Internet github-internet-neg com o FQDN github.com e a porta 443.

gcloud compute network-endpoint-groups update github-internet-neg \
    --add-endpoint="fqdn=github.com,port=443" \
    --region=$region

Criar políticas e regras de firewall de rede

No Cloud Shell, faça o seguinte:

gcloud compute network-firewall-policies create looker-psc-demo-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy looker-psc-demo-policy --network looker-psc-demo --name looker-psc-demo --global-firewall-policy

A regra de firewall a seguir permite o tráfego do intervalo de sub-rede NAT do PSC para todas as instâncias na rede.

No Cloud Shell, faça o seguinte:

gcloud compute network-firewall-policies rules create 2001 --action ALLOW --firewall-policy looker-psc-demo-policy --description "allow traffic from PSC NAT subnet" --direction INGRESS --src-ip-ranges 172.16.10.0/28 --global-firewall-policy --layer4-configs=tcp

8. Criar serviço de produtor

Criar componentes do balanceador de carga

No Cloud Shell, faça o seguinte:

gcloud compute backend-services create producer-backend-svc  --protocol=tcp --region=$region --load-balancing-scheme=INTERNAL_MANAGED

gcloud compute backend-services add-backend producer-backend-svc --network-endpoint-group=github-internet-neg --network-endpoint-group-region=$region --region=$region

No Cloud Shell, crie um proxy TCP de destino para encaminhar solicitações ao serviço de back-end:

gcloud compute target-tcp-proxies create producer-lb-tcp-proxy \
      --backend-service=producer-backend-svc  \
      --region=$region

Na sintaxe a seguir, crie uma regra de encaminhamento (balanceador de carga do proxy TCP interno).

No Cloud Shell, faça o seguinte:

gcloud compute forwarding-rules create producer-github-fr \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=looker-psc-demo \
     --subnet=producer-psc-fr-subnet \
     --address=internet-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --ports=443

Criar anexo de serviço

No Cloud Shell, crie o anexo de serviço github-svc-attachment-https:

gcloud compute service-attachments create github-svc-attachment-https --region=$region --producer-forwarding-rule=producer-github-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-subnet

Em seguida, anote o anexo de serviço listado no URI de self-link que começa com projetos para configurar o endpoint do PSC no Looker.

selfLink: projects/<your-project-id>/regions/<your-region>/serviceAttachments/github-svc-attachment-https

No Cloud Shell, faça o seguinte:

gcloud compute service-attachments describe github-svc-attachment-https --region=$region

Exemplo:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2024-08-30T09:44:03.883-07:00'
description: ''
enableProxyProtocol: false
fingerprint: RfKh3blWZE0=
id: '2897904404386302012'
kind: compute#serviceAttachment
name: github-svc-attachment-https
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$project/regions/$region/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '19348441121424360'
  low: '2897904404386302012'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$project/regions/$region
selfLink: https://www.googleapis.com/compute/v1/projects/$project/regions/$region/serviceAttachments/github-svc-attachment-https
targetService: https://www.googleapis.com/compute/v1/projects/$project/regions/$region/forwardingRules/producer-github-fr

No console do Cloud, navegue até:

Serviços de rede → Private Service Connect → Serviços publicados

9. Estabelecer uma conexão de endpoint do PSC no Looker

Na próxima seção, você vai associar o anexo de serviço do produtor ao PSC do Looker Core usando as flags –psc-service-attachment no Cloud Shell para um único domínio.

OBSERVAÇÃO: sempre que você executar um comando de atualização com as flags –psc-service-attachment, é necessário incluir todas as conexões que você quer ativar, incluindo as que já foram ativadas anteriormente. Consulte os documentos do PSC do Looker para conferir um exemplo.

OBSERVAÇÃO: a flag domain=github.com é necessária para estabelecer uma conexão HTTPS com github.com.

OBSERVAÇÃO: a instância do PSC do Looker precisa ser ativada antes de continuar.

No Cloud Shell, crie a associação do psc atualizando os seguintes parâmetros para corresponder ao seu ambiente:

• INSTANCE_NAME: o nome da sua instância do Looker (Google Cloud Core).
• DOMAIN_1: github.com
• SERVICE_ATTACHMENT_1: URI capturado ao descrever o anexo de serviço, github-svc-attachment-https.
• REGION: a região em que sua instância do Looker (Google Cloud Core) está hospedada.

No Cloud Shell, faça o seguinte:

gcloud looker instances update INSTANCE_NAME \
--psc-service-attachment  domain=DOMAIN_1,attachment=SERVICE_ATTACHMENT_URI_1 \
--region=REGION

Exemplo:

gcloud looker instances update looker-psc-instance \
--psc-service-attachment  domain=github.com,attachment=projects/$project/regions/$region/serviceAttachments/github-svc-attachment-https \
--region=$region

No Cloud Shell, valide se o status de conexão de serviceAttachments é "ACCEPTED" e atualize com o INSTANCE_NAME do PSC do Looker.

gcloud looker instances describe [INSTANCE_NAME] --region=$region --format=json

Exemplo:

gcloud looker instances describe looker-psc-instance --region=$region --format=json

Exemplo:

{
  "adminSettings": {},
  "createTime": "2024-08-23T00:00:45.339063195Z",
  "customDomain": {
    "domain": "cosmopup.com",
    "state": "AVAILABLE"
  },
  "encryptionConfig": {},
  "lookerVersion": "24.12.28",
  "name": "projects/$project/locations/$region/instances/looker-psc-instance",
  "platformEdition": "LOOKER_CORE_ENTERPRISE_ANNUAL",
  "pscConfig": {
    "allowedVpcs": [

    "projects/$project/global/networks/looker-psc-demo",
      "projects/$project/global/networks/looker-shared-vpc"
    ],
    "lookerServiceAttachmentUri": "projects/t7ec792caf2a609d1-tp/regions/$region/serviceAttachments/looker-psc-f51982e2-ac0d-48b1-91bb-88656971c183",
    "serviceAttachments": [
      {
        "connectionStatus": "ACCEPTED",
        "localFqdn": "github.com",
        "targetServiceAttachmentUri": "projects/$project/regions/$region/serviceAttachments/github-svc-attachment-https"
      }
    ]
  },
  "pscEnabled": true,
  "state": "ACTIVE",
  "updateTime": "2024-08-30T17:47:33.440271635Z"
}

Validar o endpoint do PSC no console do Cloud

No console do Cloud, é possível validar a conexão PSC.

No console do Cloud, navegue até:

Looker → Instância do Looker → Detalhes

10. Testar a conectividade com o GitHub

Nas etapas a seguir, você vai usar o Looker Console para criar um projeto e validar a conectividade HTTPS com github.com.

11. Criar um novo projeto

Ativar o modo de desenvolvimento

No console do Looker, navegue até:

Ative o modo de desenvolvimento (canto inferior esquerdo da página). Depois de selecionado, o banner "Você está no modo de desenvolvimento" vai aparecer.

Criar um novo projeto

No console do Cloud, navegue até:

Desenvolver → Projetos

Selecionar "Novo projeto do LookML"

Informe um nome, selecione "Projeto em branco" e clique em "Criar projeto".

Selecione "Configurar Git".

Configurar o Git

Atualize o URL do repositório com os detalhes do GitHub HTTPS, adicione o URL com .git e selecione "Continuar".

Exemplo:

Atualize a seleção com seu nome de usuário do GitHub e o Token de acesso pessoal (clássico) e selecione "Testar e finalizar a configuração".

Selecionar ações do Git

Selecionar "Testar conexão do Git"

Validar o teste de conexão do Git

Limpar

Excluir componentes do laboratório em um único terminal do Cloud Shell

gcloud compute service-attachments delete github-svc-attachment-https --region=$region -q

gcloud compute forwarding-rules delete producer-github-fr --region=$region -q

gcloud compute target-tcp-proxies delete producer-lb-tcp-proxy --region=$region -q

gcloud compute backend-services delete producer-backend-svc --region=$region -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy looker-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=looker-psc-demo-policy  --name=looker-psc-demo --global-firewall-policy -q

gcloud compute network-firewall-policies delete looker-psc-demo-policy --global -q

gcloud compute routers nats delete looker-psc-demo-natgw --router=looker-psc-demo-cloud-router --router-region=$region -q

gcloud compute routers delete looker-psc-demo-cloud-router --region=$region -q

gcloud compute network-endpoint-groups delete github-internet-neg --region=$region -q

gcloud compute addresses delete internet-neg-lb-ip --region=$region -q

gcloud compute networks subnets delete producer-psc-fr-subnet producer-psc-nat-subnet $region-proxy-only-subnet --region=$region -q

gcloud compute networks delete looker-psc-demo -q

12. Parabéns

Parabéns! Você configurou e validou a conectividade com o GitHub usando o Looker Console com o Private Service Connect.

Você criou a infraestrutura do produtor e aprendeu a criar um NEG da Internet, um serviço de produtor e um endpoint do PSC do Looker que permitissem a conectividade ao serviço do produtor.

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
• 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
• Acesso a todos os codelabs publicados do Private Service Connect

Leituras e vídeos complementares

• Como configurar e testar uma conexão do Git | Looker | Google Cloud
• Visão geral do Private Service Connect

Documentos de referência

• Configurar um balanceador de carga de rede de proxy interno regional com um back-end externo
• Visão geral do Cloud NAT
• Criar uma instância do Looker (Google Cloud Core) do Private Service Connect
• Como publicar um serviço usando o Private Service Connect