NEG da Internet HTTPS de saída do Looker PSA

1. Introdução

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

Uma instância do Looker (Google Cloud Core) que tem uma conexão por IP particular (acesso a serviços particulares) e uma conexão por IP público tem um URL público, e todo o tráfego de entrada passa pela conexão por IP público. 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, não é possível acessá-la de uma instância do Looker implantada como particular ou pública + particular.

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

O que você vai aprender

• Requisitos de rede
• Estabelecer conectividade com o GitHub no Looker usando um teste de conexão

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 do PSA do Looker com o modo público + particular ou somente 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 aproveita o Cloud NAT para saída da Internet para organizações github.com resolvidas pelo Looker.

3. Requisitos de rede

Confira abaixo o detalhamento dos requisitos de rede:

Componentes	Descrição
VPC ($vpc_network)	VPC no modo personalizado
Sub-rede da regra de encaminhamento	Usada para alocar um endereço IP para o balanceador de carga de proxy TCP regional interno
Sub-rede somente proxy	Cada proxy do balanceador de carga recebe um endereço IP interno. Cada pacote enviado de um proxy para um endpoint ou VM de back-end tem 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 acessível 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 está 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 aproveita 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]
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 do 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 gateway NAT é usado pelo balanceador de carga de proxy TCP regional interno para saída da Internet com a opção de configuração –endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB. Portanto, o mesmo NATGW não vai oferecer suporte à saída da Internet do GCE/GKE. Implante um gateway NAT adicional com –endpoint-types=ENDPOINT_TYPE_VM para saída da 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 ativando a saída da Internet para o balanceador de carga do 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, somente um endereço IP roteável da Internet pública poderá ser usado. Se o formato INTERNET_FQDN_PORT (opção 2) for escolhido, o FQDN poderá ser resolvido para um endereço IP roteável da Internet pública ou para 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 exige o endereço IP resolvido de Github.com. Portanto, para melhor desempenho, abra um terminal local e execute um comando "dig" para receber o endereço IP de github.com.

O exemplo de um terminal local 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 um NEG da Internet e defina –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 é necessá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 o FQDN

Opcionalmente, você pode criar um NEG da Internet e definir –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 de 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 DNS do GitHub

Na seção a seguir, você vai criar uma política de resposta de 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 com o GitHub pelo balanceador de carga interno em combinação com o NEG da Internet e o Cloud NAT.

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

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

No Cloud Shell, crie o registro A de DNS que consiste no endereço IP do balanceador de carga de 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 o peering de DNS

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

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

No Cloud Shell, crie um domínio DNS com peering 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 console do Looker 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" será exibido.

Criar um novo projeto

No console do Cloud, navegue até:

Desenvolver → Projetos

Selecione "Novo projeto do LookML".

Forneça um nome de projeto, 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 HTTPS do GitHub. 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 configuração".

Selecione "Ações do Git".

Selecione "Testar conexão Git".

Valide o teste de conexão do Git.

13. Liberar espaço

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 console do Looker.

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

Qual é a próxima etapa?

Leituras e vídeos adicionais

• 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