Looker PSC Southbound HTTPS Internet NEG Gitlab autogerenciado

Sobre este codelab

41 minutos

Último 2 de abril de 2025 atualizado

Escrito por Deepak Michael

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 no seu ambiente autogerido do GitLab 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 a instância autogerenciada do GitLab

O que é necessário

• Projeto do Google Cloud com permissões de proprietário
• Conta e repositório do GitLab
• 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 publicados como um serviço pelo Private Service Connect (PSC). Depois de publicar, 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 seu ambiente autogerenciado do GitLab.

OBSERVAÇÃO: o tutorial não fornece testes para implantar uma instância autogerenciada do Gitlab.

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 do 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 configurado como FQDN, que denota o FQDN local autogerenciado do Gitlab. O FQDN da Internet realiza a pesquisa DNS na VPC para resolução.
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.

OBSERVAÇÃO: na nossa configuração, um NEG da Internet configurado com FQDN é implantado na VPC do consumidor para resolver o endereço IP da instância autogerenciada do GitLab localizada no local. Por padrão, o NEG da Internet vai realizar uma pesquisa DNS para o FQDN fornecido. Portanto, se o FQDN da sua instância autogerenciada do GitLab puder ser resolvido em uma instância do GCE, não será necessário fazer mais nada. Se o FQDN não puder ser resolvido, será necessário implantar uma zona particular do Cloud DNS com um registro A do endereço IP do servidor autogerido do Gitlab. Neste tutorial, vamos configurar uma zona de DNS particular para gitlabonprem.com e um registro A com destino ao servidor autogerido do Gitlab.

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

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 acessar a instância autogerenciada do Gitlab, gitlabonprem.com.

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

OBSERVAÇÃO: a validação de certificado exige que fqdn=gitlabonprem,port=443 seja compatível com HTTPS.

No Cloud Shell, atualize o NEG da Internet gitlab-self-managed-internet-neg com o FQDN gitlabonprem.com e a porta 443.

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

Criar regras de firewall de rede

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-looker-psc-demo \
    --network looker-psc-demo \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

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=gitlab-self-managed-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-gitlab-self-managed-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 gitlab-self-managed-svc-attachment-https com aprovação automática que permita a conectividade do Looker Core ao anexo de serviço. Se você quiser controlar o acesso ao anexo do serviço, a opção de aprovações explícitas é aceita.

gcloud compute service-attachments create gitlab-self-managed-svc-attachment-https --region=$region --producer-forwarding-rule=producer-gitlab-self-managed-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/gitlab-self-managed-svc-attachment-https

No Cloud Shell, faça o seguinte:

gcloud compute service-attachments describe gitlab-self-managed-svc-attachment-https --region=$region

Exemplo:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2025-03-04T18:55:42.254-08:00'
description: ''
enableProxyProtocol: false
fingerprint: MlY9GLLGsgE=
id: '9103522880241140673'
kind: compute#serviceAttachment
name: gitlab-self-managed-svc-attachment-https
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '115404658846991336'
  low: '9103522880241140673'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/serviceAttachments/gitlab-self-managed-svc-attachment-https
targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/forwardingRules/producer-gitlab-self-managed-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=gitlabonprem.com é necessária para estabelecer uma conexão HTTPS com gitlabonprem.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: gitlabonprem.com
• SERVICE_ATTACHMENT_1: URI capturado ao descrever o anexo de serviço, gitlab-self-managed-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=gitlabonprem.com,attachment=projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-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.looker.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"
    ],
    "lookerServiceAttachmentUri": "projects/t7ec792caf2a609d1-tp/regions/$region/serviceAttachments/looker-psc-f51982e2-ac0d-48b1-91bb-88656971c183",
    "serviceAttachments": [
      {
        "connectionStatus": "ACCEPTED",
        "localFqdn": "gitlabonprem.com",
        "targetServiceAttachmentUri": "projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-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. resolução de DNS

Na seção a seguir, crie uma instância do GCE e valide a resolução de DNS para a instância autogerenciada do Gitlab, gitlabonprem.com, executando um PING. Como esperado, a resolução vai falhar, exigindo uma zona de DNS particular para gitlabonprem.com.

11. Criar uma instância do GCE

No Cloud Shell, crie a instância do GCE usada para validar a resolução de DNS.

gcloud compute instances create gce-dns-lookup \
    --project=$projectid \
    --machine-type=e2-micro \
    --image-family debian-11 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=producer-psc-fr-subnet

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 gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

No SO, faça um PING para gitlabonprem.com. A falha é esperada.

ping gitlabonprem.com

Exemplo:

user@gce-dns-lookup:~$ ping gitlabonprem.com
ping: gitlabonprem.com: Name or service not known

Saia do SO para voltar ao terminal do Cloud Shell.

exit

12. Criar uma zona de DNS particular

No Cloud Shell, crie a zona particular do Cloud DNS.

gcloud dns --project=$projectid managed-zones create gitlab-self-managed --description="" --dns-name="gitlabonprem.com." --visibility="private" --networks="https://compute.googleapis.com/compute/v1/projects/$projectid/global/networks/looker-psc-demo"

No Cloud Shell, crie o registro A que consiste no endereço IP da instância autogerenciada do Gitlab, 192.168.10.4.

gcloud dns --project=$projectid record-sets create gitlabonprem.com. --zone="gitlab-self-managed" --type="A" --ttl="300" --rrdatas="192.168.10.4"

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 gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

No SO, faça um PING para gitlabonprem.com, que é resolvido para 192.168.10.4.

ping gitlabonprem.com

Exemplo:

user@gce-dns-lookup:~$ ping gitlabonprem.com
PING gitlabonprem.com (192.168.10.4) 56(84) bytes of data

Saia do SO para voltar ao terminal do Cloud Shell.

exit

13. Conectividade híbrida

O FQDN gitlabonprem.com agora pode ser resolvido com o endereço IP particular hospedado no local. Em seguida, a rede híbrida (por exemplo, Interconnect, VPN de alta disponibilidade) precisa ser configurada entre a VPC looker-psc-demo e a rede local para ativar a conectividade.

Confira abaixo as etapas necessárias para estabelecer a conectividade do NEG híbrido no local:

• Como escolher um produto de conectividade de rede | Google Cloud
• Em uma arquitetura hub-spoke com peering de VPC, o NEG híbrido é implantado na mesma VPC que o Cloud Router (hub).
• Verifique se os firewalls locais estão atualizados para acomodar o intervalo de sub-redes somente proxy, já que essa sub-rede serve como o endereço IP de origem para a comunicação com os workloads locais.
• Divulgue a sub-rede somente proxy do Cloud Router como uma divulgação de rota personalizada

14. Testar a conectividade

Nas etapas a seguir, você vai usar o Looker Console para criar um projeto e validar a conectividade HTTPS com gitlabonprem.com usando o procedimento descrito em Configurar e testar uma conexão do Git.

OBSERVAÇÃO: configure a conexão do Git com o FQDN local definido ao aplicar o anexo de serviço ao Looker Core. Se o mesmo FQDN local não for usado na etapa de configuração do Git, a conexão vai falhar.

15. Limpar

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

gcloud compute service-attachments delete gitlab-self-managed-svc-attachment-https --region=$region -q

gcloud compute forwarding-rules delete producer-gitlab-self-managed-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-endpoint-groups delete gitlab-self-managed-internet-neg --region=$region -q

gcloud compute instances delete gce-dns-lookup --zone=us-central1-a -q

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

gcloud dns --project=$projectid record-sets delete gitlabonprem.com. --zone="gitlab-sel
f-managed" --type="A"

gcloud dns --project=$projectid managed-zones delete gitlab-self-managed 

gcloud compute networks delete looker-psc-demo -q

16. Parabéns

Parabéns! Você configurou e validou a conectividade a uma instância autogerenciada do GitLab 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

Mais leituras e vídeos

• 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
• Criar uma instância do Private Service Connect do Looker (Google Cloud Core)
• Como publicar um serviço usando o Private Service Connect