Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

1. Einführung

HINWEIS: Looker unterstützt Southbound-Produzenten in jeder Region. Für den Northbound-Zugriff auf Looker muss sich der Endpunkt oder das Backend des Verbrauchers in derselben Region wie die PSC-Instanz von Looker befinden.

In diesem Codelab stellen Sie eine southbound-HTTPS-Verbindung zu Ihrer selbst verwalteten GitLab-Umgebung mit einem internen TCP-Proxy-Load Balancer und einer Internet-Netzwerk-Endpunktgruppe (NEG) her, die von Looker PSC als Dienstverbraucher aufgerufen wird.

Private Service Connect ist eine Funktion des Google Cloud-Netzwerks, mit der Nutzer privat aus ihrem VPC-Netzwerk auf verwaltete Dienste zugreifen können. Ebenso können Ersteller verwalteter Dienste diese Dienste in ihren eigenen separaten VPC-Netzwerken hosten und ihren Nutzern eine private Verbindung bieten. Wenn Sie beispielsweise Private Service Connect für den Zugriff auf Looker verwenden, sind Sie der Dienstnutzer und Google der Dienstersteller, wie in Abbildung 1 dargestellt.

Abbildung 1:

Mit dem Downstreamzugriff, auch als umgekehrter PSC bezeichnet, kann der Nutzer einen veröffentlichten Dienst als Ersteller erstellen, um Looker Zugriff auf lokale Endpunkte, auf ein VPC, auf verwaltete Dienste und auf das Internet zu gewähren. Südgerichtete Verbindungen können in jeder Region bereitgestellt werden, unabhängig davon, wo Looker PSC bereitgestellt wird, wie in Abbildung 2 dargestellt.

Abbildung 2.

Aufgaben in diesem Lab

• Netzwerkanforderungen
• Private Service Connect-Producer-Dienst erstellen
• Private Service Connect-Endpunkt in Looker erstellen
• Verbindung zur selbstverwalteten GitLab-Instanz herstellen

Voraussetzungen

• Google Cloud-Projekt mit Inhaberberechtigungen
• GitLab-Konto und ‑Repository
• Vorhandene Looker-PSC-Instanz

2. Aufgaben

Sie richten ein Producer-Netzwerk namens looker-psc-demo ein, um einen internen TCP-Proxy-Load Balancer und eine Internet-NEG bereitzustellen, die als Dienst über Private Service Connect (PSC) veröffentlicht wird. Nach der Veröffentlichung führst du die folgenden Aktionen aus, um den Zugriff auf den Producer-Dienst zu bestätigen:

• PSC-Endpunkt in Looker erstellen, der mit dem Dienstanhang des Diensterstellers verknüpft ist
• Erstellen Sie mit der Looker Console ein neues Projekt und testen Sie die HTTPS-Verbindung zu Ihrer selbst verwalteten GitLab-Umgebung.

HINWEIS: In diesem Tutorial werden keine Tests zum Bereitstellen einer selbst verwalteten GitLab-Instanz bereitgestellt.

3. Netzwerkanforderungen

Unten finden Sie eine Aufschlüsselung der Netzwerkanforderungen für das Produzentennetzwerk. Der Nutzer in diesem Codelab ist die Looker-PSC-Instanz.

Komponenten	Beschreibung
VPC (looker-psc-demo)	VPC im benutzerdefinierten Modus
PSC-NAT-Subnetz	Pakete aus dem VPC-Netzwerk des Nutzers werden mithilfe von Quell-NAT (SNAT) übersetzt, sodass ihre ursprünglichen Quell-IP-Adressen in Quell-IP-Adressen aus dem NAT-Subnetz im VPC-Netzwerk des Erstellers umgewandelt werden.
Subnetz der PSC-Weiterleitungsregel	Wird verwendet, um eine IP-Adresse für den internen regionalen TCP-Proxy-Load Balancer zuzuweisen.
PSC-NEG-Subnetz	Wird verwendet, um eine IP-Adresse für die Netzwerk-Endpunktgruppe zuzuweisen.
Nur-Proxy-Subnetz	Jedem Proxy des Load Balancers wird eine interne IP-Adresse zugewiesen. Pakete, die von einem Proxy an eine Backend-VM oder einen Backend-Endpunkt gesendet werden, haben eine Quell-IP-Adresse aus dem Nur-Proxy-Subnetz.
Internet-NEG	Eine Ressource, mit der ein externes Backend für den Load Balancer definiert wird, konfiguriert als FQDN, der den FQDN der selbstverwalteten On-Premises-Gitlab-Instanz angibt. Der Internet-FQDN führt einen DNS-Lookup innerhalb des VPC zur Auflösung durch.
Backend-Dienst	Ein Back-End-Dienst dient als Brücke zwischen Ihrem Load Balancer und Ihren Back-End-Ressourcen. In diesem Tutorial ist der Back-End-Dienst mit der Internet-NEG verknüpft.

HINWEIS: In unserer Konfiguration wird ein mit FQDN konfigurierter Internet-NEG in der Kunden-VPC bereitgestellt, um die IP-Adresse der lokal gehosteten GitLab-Instanz aufzulösen. Standardmäßig führt der Internet-NEG eine DNS-Suche für den angegebenen FQDN durch. Wenn der FQDN Ihrer selbst verwalteten GitLab-Instanz von einer GCE-Instanz aufgelöst werden kann, sind keine weiteren Maßnahmen erforderlich. Wenn der FQDN nicht aufgelöst werden kann, müssen Sie eine private Cloud DNS-Zone zusammen mit einem A-Eintrag für die IP-Adresse des selbst verwalteten Gitlab-Servers bereitstellen. In diesem Tutorial konfigurieren wir eine private DNS-Zone für gitlabonprem.com und einen A-Eintrag, der auf den selbst verwalteten Gitlab-Server verweist.

4. Codelab-Topologie

5. Einrichtung und Anforderungen

Einrichtung der Umgebung im eigenen Tempo

1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto erstellen.

• Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. In der Regel spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Konto ausprobieren und prüfen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.

Achtung:Eine Projekt-ID ist global eindeutig und kann nach der Auswahl nicht mehr von anderen verwendet werden. Sie sind der einzige Nutzer dieser ID. Auch wenn ein Projekt gelöscht wird, kann die ID nicht wiederverwendet werden.

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie den Standardspeicherort auf Keine Organisation belassen. Wenn Sie ein Google Workspace-Konto verwenden, wählen Sie einen Standort aus, der für Ihre Organisation sinnvoll ist.

2. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Durchführung dieses Codelabs ist kostenlos oder kostet nur sehr wenig. Wenn Sie die Ressourcen deaktivieren möchten, um weitere Kosten nach Abschluss dieser Anleitung zu vermeiden, können Sie die von Ihnen erstellten Ressourcen oder das Projekt löschen. Neuen Google Cloud-Nutzern steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

Cloud Shell starten

Sie können Google Cloud zwar per Fernzugriff von Ihrem Laptop aus nutzen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der Google Cloud Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Minuten dauern. Wenn der Vorgang abgeschlossen ist, sollte in etwa Folgendes angezeigt werden:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Dadurch werden Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.

6. Hinweis

APIs aktivieren

Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist:

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

Aktivieren Sie alle erforderlichen Dienste:

gcloud services enable compute.googleapis.com

7. Ersteller-VPC-Netzwerk erstellen

VPC-Netzwerk

Führen Sie in Cloud Shell folgende Schritte aus:

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

Subnetze erstellen

Das PSC-Subnetz wird dem PSC-Dienstanhang zum Zweck der Network Address Translation zugeordnet.

Erstellen Sie in Cloud Shell das PSC-NAT-Subnetz:

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

Erstellen Sie in Cloud Shell das Subnetzwerk für die Weiterleitungsregel des Producers:

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

Erstelle in Cloud Shell das regionale Nur-Proxy-Subnetz des Producers:

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

IP-Adresse des Load-Balancers reservieren

Reservieren Sie in Cloud Shell eine interne IP-Adresse für den Load Balancer:

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

Rufen Sie in Cloud Shell die reservierte IP-Adresse auf.

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

Beispielausgabe:

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

Internet-NEG einrichten

Erstellen Sie eine Internet-NEG und legen Sie den „–network-endpoint-type“ auf „internet-fqdn-port“ fest (Hostname und Port, an dem Ihr externes Back-End erreicht werden kann).

Erstellen Sie in Cloud Shell eine Internet-NEG, die für den Zugriff auf die selbst verwaltete GitLab-Instanz gitlabonprem.com verwendet wird.

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

HINWEIS: Für die Zertifikatsvalidierung ist fqdn=gitlabonprem,port=443 erforderlich, um HTTPS zu unterstützen.

Aktualisieren Sie in Cloud Shell die Internet-NEG „gitlab-self-managed-internet-neg“ mit dem FQDN „gitlabonprem.com“ und dem Port 443.

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

Netzwerk-Firewallregeln erstellen

Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, erstellen Sie eine Firewallregel, die:

• Gilt für alle VM-Instanzen, die über IAP zugänglich sein sollen.
• Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.

Erstellen Sie in Cloud Shell die IAP-Firewallregel.

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. Producer-Dienst erstellen

Load Balancer-Komponenten erstellen

Führen Sie in Cloud Shell folgende Schritte aus:

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

Erstellen Sie in Cloud Shell einen Ziel-TCP-Proxy, um Anfragen an Ihren Backend-Dienst weiterzuleiten:

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

Erstellen Sie mit der folgenden Syntax eine Weiterleitungsregel (interner TCP-Proxy-Load Balancer).

Führen Sie in Cloud Shell folgende Schritte aus:

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

Dienstanhang erstellen

Erstellen Sie in Cloud Shell die Dienstverknüpfung „gitlab-self-managed-svc-attachment-https“ mit automatischer Genehmigung, die eine Verbindung von Looker Core zur Dienstverknüpfung ermöglicht. Wenn Sie den Zugriff auf den Dienstanhang steuern möchten, wird die Option explizite Genehmigungen unterstützt.

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

Rufen Sie als Nächstes den im selfLink-URI aufgeführten Dienstanhang ab und notieren Sie sich den Anfang, der mit „projects“ beginnt, um den PSC-Endpunkt in Looker zu konfigurieren.

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

Führen Sie in Cloud Shell folgende Schritte aus:

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

Beispiel:

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

Rufen Sie in der Cloud Console Folgendes auf:

Netzwerkdienste → Private Service Connect → Veröffentlichte Dienste

9. PSC-Endpunktverbindung in Looker herstellen

Im folgenden Abschnitt ordnen Sie den Dienstanhang des Erstellers dem PSC von Looker Core mithilfe der Flags „–psc-service-attachment“ in Cloud Shell für eine einzelne Domain zu.

HINWEIS: Jedes Mal, wenn Sie einen Update-Befehl mit den Flags „–psc-service-attachment“ ausführen, müssen Sie alle Verbindungen angeben, die aktiviert werden sollen, einschließlich Verbindungen, die bereits zuvor aktiviert waren. In der Looker-PSC-Dokumentation finden Sie ein Beispiel.

HINWEIS: Das Flag „domain=gitlabonprem.com“ ist erforderlich, um eine HTTPS-Verbindung zu gitlabonprem.com herzustellen.

HINWEIS: Ihre Looker-PSC-Instanz muss aktiviert sein, bevor Sie fortfahren können.

Erstellen Sie in Cloud Shell die PSC-Verknüpfung, indem Sie die folgenden Parameter an Ihre Umgebung anpassen:

• INSTANCE_NAME: Der Name Ihrer Looker (Google Cloud Core)-Instanz.
• DOMAIN_1: gitlabonprem.com
• SERVICE_ATTACHMENT_1: URI, der bei der Beschreibung des Dienstanhangs erfasst wurde, gitlab-self-managed-svc-attachment-https.
• REGION: Die Region, in der Ihre Looker (Google Cloud Core)-Instanz gehostet wird.

Führen Sie in Cloud Shell folgende Schritte aus:

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

Beispiel:

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

Prüfen Sie in Cloud Shell, ob der Verbindungsstatus von „serviceAttachments“ „ACCEPTED“ ist. Aktualisieren Sie ihn mit Ihrem Looker-PSC INSTANCE_NAME.

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

Beispiel:

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

Beispiel:

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

PSC-Endpunkt in der Cloud Console prüfen

In der Cloud Console können Sie die PSC-Verbindung prüfen.

Rufen Sie in der Cloud Console Folgendes auf:

Looker → Looker-Instanz → Details

10. DNS-Auflösung

Im folgenden Abschnitt erstellen Sie eine GCE-Instanz und validieren die DNS-Auflösung für die selbst verwaltete Gitlab-Instanz gitlabonprem.com mit einem PING. Wie erwartet schlägt die Auflösung fehl und es ist eine private DNS-Zone für gitlabonprem.com erforderlich.

11. GCE-Instanz erstellen

Erstellen Sie in Cloud Shell die GCE-Instanz, die zum Validieren der DNS-Auflösung verwendet wird.

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

Melden Sie sich in Cloud Shell mit IAP in der Consumer-VM an, um die Verbindung zum Erstellerdienst mithilfe eines Curl-Befehls zu prüfen. Wiederholen Sie den Vorgang bei einer Zeitüberschreitung.

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

Führen Sie über das Betriebssystem einen PING zu gitlabonprem.com aus. Der Fehler ist zu erwarten.

ping gitlabonprem.com

Beispiel:

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

Beenden Sie das Betriebssystem, um zum Cloud Shell-Terminal zurückzukehren.

exit

12. Private DNS-Zone erstellen

Erstellen Sie in Cloud Shell die private Cloud DNS-Zone.

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"

Erstellen Sie in Cloud Shell den A-Eintrag mit der IP-Adresse der selbstverwalteten Gitlab-Instanz, 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"

Melden Sie sich in Cloud Shell mit IAP in der Consumer-VM an, um die Verbindung zum Erstellerdienst mithilfe eines Curl-Befehls zu prüfen. Wiederholen Sie den Vorgang bei einer Zeitüberschreitung.

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

Führen Sie über das Betriebssystem einen PING auf gitlabonprem.com aus, der zu 192.168.10.4 aufgelöst wird.

ping gitlabonprem.com

Beispiel:

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

Beenden Sie das Betriebssystem, um zum Cloud Shell-Terminal zurückzukehren.

exit

13. Hybridkonnektivität

Der FQDN gitlabonprem.com kann jetzt mit der lokal gehosteten privaten IP-Adresse aufgelöst werden. Als Nächstes muss ein Hybridnetzwerk (z.B. Interconnect, HA-VPN) zwischen dem VPC „looker-psc-demo“ und dem lokalen Netzwerk konfiguriert werden, um eine Verbindung zu ermöglichen.

Im Folgenden sind die Schritte aufgeführt, die erforderlich sind, um eine Hybrid-NEG-Verbindung zu On-Premises-Umgebungen herzustellen:

• Produkt für die Netzwerkverbindung auswählen | Google Cloud
• In einer Hub-and-Spoke-Architektur mit VPC-Peering wird die hybride NEG im selben VPC wie der Cloud-Router (Hub) bereitgestellt.
• Achten Sie darauf, dass die lokalen Firewalls für den Bereich des Nur-Proxy-Subnetzes aktualisiert werden, da dieses Subnetz als Quell-IP-Adresse für die Kommunikation mit lokalen Arbeitslasten dient.
• Nur-Proxy-Subnetz über den Cloud Router als benutzerdefinierte Route bewerben

14. Konnektivität testen

In den folgenden Schritten erstellen Sie mit der Looker Console ein Projekt, um die HTTPS-Verbindung zu gitlabonprem.com zu validieren. Folgen Sie dazu der Anleitung unter Git-Verbindung einrichten und testen.

HINWEIS: Konfigurieren Sie die Git-Verbindung mit dem lokalen FQDN, der beim Anwenden des Dienst-Anhangs auf Looker Core definiert wurde. Wenn Sie nicht denselben lokalen FQDN im Schritt „git konfigurieren“ verwenden, führt dies zu einem Verbindungsfehler.

15. Bereinigen

Lab-Komponenten über ein einzelnes Cloud Shell-Terminal löschen

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. Glückwunsch

Herzlichen Glückwunsch! Sie haben die Verbindung zu einer selbst verwalteten GitLab-Instanz mithilfe der Looker Console und Private Service Connect erfolgreich konfiguriert und validiert.

Sie haben die Erstellerinfrastruktur erstellt und gelernt, wie Sie einen Internet-NEG, einen Erstellerdienst und einen Looker-PSC-Endpunkt erstellen, um eine Verbindung zum Erstellerdienst herzustellen.

Cosmopup findet Codelabs super!

Was liegt als Nächstes an?

Sehen Sie sich einige dieser Codelabs an:

• Private Service Connect zum Veröffentlichen und Nutzen von Diensten verwenden
• Über Private Service Connect und einen internen TCP-Proxy-Load Balancer eine Verbindung zu On-Premise-Diensten über Hybridnetzwerke herstellen
• Zugriff auf alle veröffentlichten Private Service Connect-Codelabs

Weitere Lesematerialien und Videos

• Git-Verbindung einrichten und testen | Looker | Google Cloud
• Private Service Connect – Übersicht

Referenzdokumente

• Regionalen internen Proxy-Network Load Balancer mit einem externen Backend einrichten
• Private Service Connect-Instanz für Looker (Google Cloud Core) erstellen
• Dienste mit Private Service Connect veröffentlichen