Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

Informazioni su questo codelab

41 minuti

Ultimo aggiornamento: 2 aprile 2025

Scritto da: Deepak Michael

1. Introduzione

NOTA: Looker supporta i produttori in uscita in qualsiasi regione. Per l'accesso in uscita a Looker, l'endpoint o il backend del consumer deve trovarsi nella stessa regione dell'istanza PSC di Looker.

In questo codelab eseguirai una connessione HTTPS southbound al tuo ambiente GitLab Self-Managed utilizzando un bilanciatore del carico proxy TCP interno e un gruppo di endpoint di rete (NEG) internet invocato da Looker PSC come consumatore di servizi.

Private Service Connect è una funzionalità della rete di Google Cloud che consente ai consumer di accedere privatamente ai servizi gestiti dall'interno della loro rete VPC. Analogamente, consente ai producer di servizi gestiti di ospitare questi servizi nelle proprie reti VPC separate e di offrire una connessione privata ai propri consumer. Ad esempio, quando utilizzi Private Service Connect per accedere a Looker, sei il consumatore del servizio e Google è il produttore del servizio, come evidenziato nella Figura 1.

Figura 1.

L'accesso in uscita, noto anche come PSC inverso, consente al consumer di creare un servizio pubblicato come produttore per consentire a Looker di accedere agli endpoint on-premise, in un VPC, ai servizi gestiti e a internet. Le connessioni in uscita possono essere implementate in qualsiasi regione, indipendentemente da dove è implementato Looker PSC, come evidenziato nella Figura 2.

Figura 2.

Cosa imparerai a fare

• Requisiti di rete
• Creare un servizio producer di Private Service Connect
• Creare un endpoint Private Service Connect in Looker
• Stabilisci la connettività all'istanza GitLab autogestita

Che cosa ti serve

• Progetto Google Cloud con autorizzazioni di proprietario
• Account e repository GitLab
• Istanza PSC di Looker esistente

2. Cosa creerai

Stabilirai una rete di produttori, looker-psc-demo, per implementare il bilanciatore del carico proxy TCP interno e il NEG di internet pubblicato come servizio tramite Private Service Connect (PSC). Una volta pubblicata, dovrai eseguire le seguenti azioni per convalidare l'accesso al servizio Producer:

• Crea un endpoint PSC in Looker associato al collegamento del servizio del produttore
• Utilizza Looker Console per creare un nuovo progetto e testare la connettività HTTPS con il tuo ambiente GitLab Self-Managed.

NOTA: il tutorial non fornisce test per il deployment di un'istanza Gitlab Self-Managed

3. Requisiti di rete

Di seguito è riportata la suddivisione dei requisiti di rete per la rete del produttore. Il consumatore in questo codelab è l'istanza PSC di Looker.

Componenti	Descrizione
VPC (looker-psc-demo)	VPC in modalità personalizzata
Subnet NAT PSC	I pacchetti della rete VPC del consumer vengono tradotti utilizzando il NAT di origine (SNAT) in modo che i relativi indirizzi IP di origine originali vengano convertiti in indirizzi IP di origine della subnet NAT nella rete VPC del producer.
Subnet della regola di inoltro PSC	Utilizzato per allocare un indirizzo IP per il Bilanciatore del carico del proxy TCP regionale interno
Subnet NEG PSC	Utilizzato per allocare un indirizzo IP per il gruppo di endpoint di rete
Subnet solo proxy	A ciascuno dei proxy del bilanciatore del carico viene assegnato un indirizzo IP interno. I pacchetti inviati da un proxy a un endpoint o a una VM di backend hanno un indirizzo IP di origine della subnet solo proxy.
NEG Internet	Una risorsa utilizzata per definire un backend esterno per il bilanciatore del carico configurato come FQDN che indica il FQDN on-premise di Gitlab Self-Managed. L'FQDN internet esegue la ricerca DNS all'interno del VPC per la risoluzione.
Servizio di backend	Un servizio di backend funge da ponte tra il bilanciatore del carico e le risorse di backend. Nel tutorial, il servizio di backend è associato al NEG internet.

NOTA: nella nostra configurazione, un NEG di internet configurato con FQDN viene implementato nel VPC del consumatore per risolvere l'indirizzo IP dell'istanza GitLab self-managed on-premise. Per impostazione predefinita, il NEG di internet eseguirà una ricerca DNS per l'FQDN fornito, pertanto se l'FQDN della tua istanza GitLab Self-Managed può essere risolto da un'istanza GCE, non è necessaria alcuna azione ulteriore. Se non è possibile risolvere l'FQDN, devi implementare una zona privata Cloud DNS insieme a un record A dell'indirizzo IP del server Gitlab self-managed. Nel tutorial, configureremo una zona DNS privata per gitlabonprem.com e un record A che ha come target il server Gitlab Self-Managed.

4. Topologia del codelab

5. Configurazione e requisiti

Configurazione dell'ambiente a tuo ritmo

1. Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.

• Il nome del progetto è il nome visualizzato per i partecipanti al progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
• L'ID progetto è univoco per tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca; di solito non ti interessa quale sia. Nella maggior parte dei codelab, dovrai fare riferimento al tuo ID progetto (in genere identificato come PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare il tuo e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimane invariato per tutta la durata del progetto.
• Per tua informazione, esiste un terzo valore, un Numero progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.

Attenzione:un ID progetto è univoco a livello globale e non può essere utilizzato da altri dopo la selezione. Sei l'unico utente di quell'ID. Anche se un progetto viene eliminato, l'ID non può essere riutilizzato

Nota:se utilizzi un account Gmail, puoi lasciare l'impostazione predefinita su Nessuna organizzazione. Se utilizzi un account Google Workspace, scegli una località adatta alla tua organizzazione.

2. Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare le API/risorse Cloud. La partecipazione a questo codelab non ha costi, o quasi. Per arrestare le risorse ed evitare di incorrere in fatturazione al termine di questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud sono idonei al programma Prova senza costi di 300$.

Avvia Cloud Shell

Sebbene Google Cloud possa essere utilizzato da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

Nella console Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:

Dovrebbe richiedere solo pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere qualcosa di simile a questo:

Questa macchina virtuale contiene tutti gli strumenti di sviluppo di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione di rete. Tutto il lavoro in questo codelab può essere svolto in un browser. Non devi installare nulla.

6. Prima di iniziare

Abilita API

In Cloud Shell, assicurati che l'ID progetto sia configurato:

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

Attiva tutti i servizi necessari:

gcloud services enable compute.googleapis.com

7. Crea la rete VPC del producer

Rete VPC

In Cloud Shell, svolgi i seguenti passaggi:

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

Creare subnet

La subnet del PSC verrà associata al collegamento del servizio PSC ai fini della Network Address Translation.

In Cloud Shell, crea la subnet NAT del 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

In Cloud Shell, crea la subnet della regola di inoltro del produttore:

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

In Cloud Shell, crea la subnet solo proxy regionale del produttore:

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

Prenota l'indirizzo IP del bilanciatore del carico

In Cloud Shell, prenota un indirizzo IP interno per il bilanciatore del carico:

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

In Cloud Shell, visualizza l'indirizzo IP riservato.

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

Output di esempio:

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

Configura il NEG internet

Crea un NEG internet e imposta il parametro –network-endpoint-type su internet-fqdn-port (il nome host e la porta su cui è possibile raggiungere il backend esterno).

In Cloud Shell, crea un NEG internet utilizzato per accedere all'istanza Gitlab Self-Managed, 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

NOTA: la convalida del certificato richiede fqdn=gitlabonprem,port=443 per supportare HTTPS

In Cloud Shell, aggiorna il NEG internet gitlab-self-managed-internet-neg con il FQDN gitlabonprem.com e la porta 443

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

Crea regole firewall di rete

Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:

• Si applica a tutte le istanze VM a cui vuoi accedere tramite IAP.
• Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP che utilizzati da IAP per l'inoltro TCP.

In Cloud Shell, crea la regola firewall 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. Crea servizio producer

Creare componenti del bilanciatore del carico

In Cloud Shell, svolgi i seguenti passaggi:

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

In Cloud Shell, crea un proxy TCP di destinazione per instradare le richieste al servizio di backend:

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

Nella seguente sintassi, crea una regola di inoltro (bilanciatore del carico del proxy TCP interno).

In Cloud Shell, svolgi i seguenti passaggi:

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

Creare un collegamento al servizio

In Cloud Shell, crea l'attacco al servizio gitlab-self-managed-svc-attachment-https con approvazione automatica che consente la connettività di Looker Core all'attacco al servizio. Se vuoi controllare l'accesso all'allegato del servizio, è supportata l'opzione delle approvazioni esplicite.

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

Successivamente, ottieni e prendi nota del collegamento al servizio elencato nell'URI selfLink a partire dai progetti per configurare l'endpoint PSC in Looker.

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

In Cloud Shell, svolgi i seguenti passaggi:

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

Esempio:

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

In Cloud Console, vai a:

Servizi di rete → Private Service Connect → Servizi pubblicati

9. Stabilire una connessione dell'endpoint PSC in Looker

Nella sezione seguente, assocerai il collegamento a un servizio dei produttori a PSC di Looker Core tramite l'utilizzo dei flag –psc-service-attachment in Cloud Shell per un singolo dominio.

NOTA: ogni volta che esegui un comando di aggiornamento con i flag –psc-service-attachment, devi includere tutte le connessioni che vuoi attivare, incluse quelle già attivate in precedenza. Consulta la documentazione di Looker PSC per un esempio.

NOTA: il flag domain=gitlabonprem.com è necessario per stabilire una connessione HTTPS a gitlabonprem.com

NOTA: prima di procedere, devi attivare l'istanza PSC di Looker .

In Cloud Shell, crea l'associazione psc aggiornando i seguenti parametri in base al tuo ambiente:

• INSTANCE_NAME: il nome dell'istanza di Looker (Google Cloud core).
• DOMAIN_1: gitlabonprem.com
• SERVICE_ATTACHMENT_1: URI acquisito durante la descrizione del collegamento al servizio, gitlab-self-managed-svc-attachment-https.
• REGION: la regione in cui è ospitata l'istanza di Looker (Google Cloud core).

In Cloud Shell, svolgi i seguenti passaggi:

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

Esempio:

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

In Cloud Shell, convalida che lo stato di connessione dei collegamenti a un servizio sia "ACCEPTED", aggiornalo con il nome dell'istanza PSC di Looker

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

Esempio:

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

Esempio:

{
  "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"
}

Convalida l'endpoint PSC nella console Cloud

Dalla console Cloud puoi convalidare la connessione al PSC

In Cloud Console, vai a:

Looker → Istanza Looker → Dettagli

10. risoluzione DNS

Nella sezione seguente, crea un'istanza GCE e convalida la risoluzione DNS all'istanza Gitlab self-managed, gitlabonprem.com, eseguendo un PING. Come previsto, la risoluzione non andrà a buon fine perché è richiesta una zona DNS privata per gitlabonprem.com.

11. Crea un'istanza GCE

In Cloud Shell, crea l'istanza GCE utilizzata per convalidare la risoluzione 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

Accedi a consumer-vm utilizzando IAP in Cloud Shell per convalidare la connettività al servizio di produzione eseguendo un comando curl. Riprova se si verifica un timeout.

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

Esegui un PING a gitlabonprem.com dal sistema operativo. L'errore è previsto.

ping gitlabonprem.com

Esempio:

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

Esci dal sistema operativo e torna al terminale Cloud Shell.

exit

12. Creare una zona DNS privata

In Cloud Shell, crea la zona privata 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"

In Cloud Shell, crea il record A costituito dall'indirizzo IP dell'istanza Gitlab Self-Managed, 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"

Accedi a consumer-vm utilizzando IAP in Cloud Shell per convalidare la connettività al servizio di produzione eseguendo un comando curl. Riprova se si verifica un timeout.

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

Dall'OS, esegui un PING a gitlabonprem.com, che risolve in 192.168.10.4.

ping gitlabonprem.com

Esempio:

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

Esci dal sistema operativo per tornare al terminale Cloud Shell.

exit

13. Connettività ibrida

Ora l'FQDN gitlabonprem.com può essere risolto con l'indirizzo IP privato ospitato on-premise. Successivamente, per abilitare la connettività, è necessario configurare la rete ibrida (ad es. interconnessione, VPN ad alta disponibilità) tra la VPC looker-psc-demo e la rete on-premise.

Di seguito sono riportati i passaggi necessari per stabilire la connettività NEG ibrida con l'on-premise:

• Scegliere un prodotto per la connettività di rete | Google Cloud
• In un'architettura hub e spoke con peering VPC, il NEG ibrido viene di solito implementato nella stessa VPC del router Cloud (hub).
• Assicurati che i firewall on-premise siano aggiornati per supportare l'intervallo di subnet solo proxy, in quanto questa subnet funge da indirizzo IP di origine per la comunicazione con i workload on-premise.
• Annuncia la subnet solo proxy dal router Cloud come annuncio di route personalizzato

14. Testare la connettività

Nei passaggi seguenti, utilizzerai la console di Looker per creare un progetto per convalidare la connettività HTTPS a gitlabonprem.com utilizzando la procedura descritta in Configurazione e test di una connessione Git.

NOTA: assicurati di configurare la connessione Git con il FQDN locale definito quando applichi l'attacco del servizio a Looker Core. Se non utilizzi lo stesso FQDN locale nel passaggio di configurazione di Git, la connessione non andrà a buon fine.

15. Esegui la pulizia

Eliminare i componenti del lab da un singolo terminale 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. Complimenti

Congratulazioni, hai configurato e convalidato correttamente la connettività a un'istanza GitLab self-managed utilizzando la console di Looker basata su Private Service Connect.

Hai creato l'infrastruttura del producer, hai imparato a creare un endpoint NEG internet, un servizio producer e un endpoint PSC di Looker che consentisse la connettività al servizio producer.

Cosmopup pensa che i codelab siano fantastici.

Passaggi successivi

Dai un'occhiata ad alcuni di questi codelab…

• Utilizzare Private Service Connect per pubblicare e utilizzare i servizi
• Connettersi ai servizi on-premise tramite Hybrid Networking utilizzando Private Service Connect e un bilanciatore del carico proxy TCP interno
• Accesso a tutti i codelab di Private Service Connect pubblicati

Letture e video di approfondimento

• Configurazione e test di una connessione Git | Looker | Google Cloud
• Panoramica di Private Service Connect

Documentazione di riferimento

• Configura un bilanciatore del carico di rete proxy interno regionale con un backend esterno
• Crea un'istanza Private Service Connect di Looker (Google Cloud core)
• Come pubblicare un servizio utilizzando Private Service Connect