NEG da Internet HTTPS de saída do Looker PSA

Sobre este codelab

38 minutos

Último 2 de abril de 2025 atualizado

Escrito por Deepak Michael, Emanuele Mazza

1. Introdução

Somente as instâncias do Looker (Google Cloud Core) que usam o acesso a serviços particulares para a conexão particular são compatíveis com uma configuração de IP particular e público.

Uma instância do Looker (Google Cloud Core) com uma conexão de IP particular (acesso a serviços particulares) e uma conexão de IP pública tem um URL público, e todo o tráfego de entrada passa pela conexão de IP pública. O tráfego de saída é roteado pela VPC, que pode ser configurada para permitir apenas o tráfego de IP particular, conforme ilustrado na Figura 1.

Figure1

A comunicação com github.com é resolvida para um endereço IP público, portanto, inacessível em uma instância do Looker implantada como particular ou público+particular.

Neste codelab, você vai realizar uma conexão HTTPS southbound com o GitHub usando um balanceador de carga de proxy TCP interno e um grupo de endpoint de rede (NEG) da Internet invocado do PSA do Looker.

O que você vai aprender

• Requisitos de rede
• 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 de PSA do Looker com o acesso público e particular ou apenas o particular ativado

2. O que você vai criar

Você vai implantar um balanceador de carga de proxy TCP interno e um NEG da Internet configurado com o endereço IP resolvido de github.com que usa o Cloud NAT para saída da Internet para organizações github.com resolvidas pelo Looker.

3. Requisitos de rede

Confira abaixo os requisitos de rede:

Componentes	Descrição
VPC ($vpc_network)	VPC de modo personalizado
sub-rede da regra de encaminhamento	Usado para alocar um endereço IP para o balanceador de carga do proxy TCP regional interno
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 funciona 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 de 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]
vpc_network=[VPC Name]
echo $project
echo $region
echo $vpc-network

Ative todos os serviços necessários:

gcloud services enable compute.googleapis.com

7. Componentes da rede VPC

Rede VPC

O pré-requisito do tutorial é uma instância do PSA Looker. Portanto, a VPC associada já foi criada.

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

gcloud compute networks subnets create psa-fr-subnet --network $vpc_network --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

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

gcloud compute networks subnets create $region-proxyonly-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=$vpc_network \
  --range=10.10.10.0/24

Criar o gateway do Public NAT

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 saída de Internet do GCE/GKE.

No Cloud Shell, crie o Cloud Router:

gcloud compute routers create $vpc_network-cloud-router --network $vpc_network --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 $vpc_network-natgw \
  --router=$vpc_network-cloud-router \
  --endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB \
  --nat-custom-subnet-ip-ranges=$region-proxyonly-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 que será usado mais tarde como o registro A de DNS para github.com:

gcloud compute addresses create internet-neg-lb-ip \
  --region=$region \
  --subnet=psa-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

8. NEG da Internet

Há duas maneiras de configurar o endpoint externo referenciado pelo NEG da Internet : INTERNET_FQDN_PORT ou INTERNET_IP_PORT. Se o formato INTERNET_IP_PORT (opção 1) for escolhido, só será possível usar um endereço IP público roteável pela Internet. Se o formato INTERNET_FQDN_PORT (opção 2) for escolhido, o FQDN poderá ser resolvido em um endereço IP público roteável pela Internet ou em um endereço IP particular, dependendo do escopo do endpoint: regional ou global.

Opção 1: configurar o NEG da Internet usando o endereço IP

O NEG da Internet requer o endereço IP resolvido do Github.com. Portanto, para ter o melhor desempenho, abra um terminal local e execute um comando "dig" para receber o endereço IP do github.com.

Exemplo de um terminal local que gera o endereço IP resolvido 140.82.113.4

bash-3.2$ dig github.com
; <<>> DiG 9.10.6 <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64801
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;github.com.                        IN        A
;; ANSWER SECTION:
github.com.                60        IN        A        140.82.113.4
;; Query time: 409 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 26 15:50:45 CDT 2024
;; MSG SIZE  rcvd: 65

Crie uma NEG na Internet e defina o –network-endpoint-type como internet_ip_port.

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_IP_PORT \
    --network=$vpc_network \
    --region=$region

OBSERVAÇÃO: ip=[resolved github.com ip],port=443 é obrigatório para oferecer suporte a HTTPS.

No Cloud Shell, atualize o NEG da Internet github-internet-neg com o endereço IP resolvido de github.com e a porta 443:

gcloud compute network-endpoint-groups update github-internet-neg \
    --add-endpoint="ip=[your-resolved-ip],port=443" \
    --region=$region

Exemplo:

gcloud compute network-endpoint-groups update github-internet-neg \
    --add-endpoint="ip=140.82.113.4,port=443" \
    --region=$region

Opção 2: configurar o NEG da Internet usando FQDN

Também é possível criar um NEG da Internet e definir o –network-endpoint-type como internet_FQDN_port.

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=$vpc_network \
    --region=$region

OBSERVAÇÃO: a porta 443 é necessária para oferecer suporte a HTTPS.

No Cloud Shell, atualize o NEG da Internet github-internet-neg com o FQDN github.com:

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

9. Criar o serviço do GitHub

Criar componentes do balanceador de carga

No Cloud Shell, faça o seguinte:

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

gcloud compute backend-services add-backend psa-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=psa-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 psa-github-fr \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=$vpc_network \
     --subnet=psa-fr-subnet \
     --address=internet-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --ports=443

10. Zona de DNS do GitHub

Na seção a seguir, você vai criar uma política de resposta DNS para GitHub.com com um registro A que consiste no endereço IP do balanceador de carga de proxy TCP interno.

Depois disso, o peering de DNS vai compartilhar a zona github.com com o PSA do Looker, permitindo a conectividade ao github pelo balanceador de carga interno em combinação com o NEG da Internet e o Cloud NAT.

No Cloud Shell, crie a zona da política de resposta:

gcloud dns --project=$project response-policies create github-com --description="" --networks="$vpc_network"

No Cloud Shell, crie o registro A do DNS que consiste no endereço IP do balanceador de carga do proxy TCP, [insert-your-ip-address]:

gcloud dns --project=$project response-policies rules create github --response-policy="github-com" --dns-name="github.com." --local-data=name="github.com.",type="A",ttl=300,rrdatas="[insert-your-ip-address]"

Exemplo:

gcloud dns --project=$project response-policies rules create github --response-policy="github-com" --dns-name="github.com." --local-data=name="github.com.",type="A",ttl=300,rrdatas="172.16.20.2"

Atualizar peering de DNS

Nesta seção, você vai usar a sintaxe "gcloud services peered-dns-domains create", que cria um domínio DNS pareado para uma conexão de serviço particular que envia solicitações de registros em um determinado namespace originado na rede VPC do produtor de serviços para a rede VPC do consumidor ser resolvido.

OBSERVAÇÃO: a criação de um domínio de DNS pareado para a rede de serviços vai influenciar todos os serviços gerenciados do Google que usam a conexão de peering de VPC da rede de serviços.

No Cloud Shell, crie um domínio DNS pareado que o Looker vai consultar para github.com:

gcloud services peered-dns-domains create github-com --project=$project --network=$vpc_network --dns-suffix=github.com.

11. 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.

12. 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

13. Limpar

Em um único terminal do Cloud Shell, exclua os componentes do laboratório:

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

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

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

gcloud compute routers nats delete $vpc_network-natgw --router=$vpc_network-cloud-router --router-region=$region -q

gcloud compute routers delete $vpc_network-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 psa-fr-subnet $region-proxyonly-subnet --region=$region -q

gcloud services peered-dns-domains delete github-com --network=$vpc_network -q

gcloud dns --project=$project response-policies rules delete github --response-policy="github-com" -q

gcloud dns response-policies update github-com --networks= -q

gcloud dns response-policies delete github-com

14. Parabéns

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

Cosmopup acha que os codelabs são incríveis.

Qual é a próxima etapa?

Mais leituras e vídeos

• Como configurar e testar uma conexão do Git | Looker | Google Cloud

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