1. Einführung
Nur Looker (Google Cloud Core)-Instanzen, die Zugriff auf private Dienste für ihre private Verbindung verwenden, unterstützen eine Konfiguration mit privater und öffentlicher IP-Adresse.
Eine Looker (Google Cloud Core)-Instanz mit sowohl einer Verbindung über eine private IP-Adresse (Zugriff auf private Dienste) als auch einer Verbindung über eine öffentliche IP-Adresse hat eine öffentliche URL und der gesamte eingehende Traffic wird über die Verbindung über die öffentliche IP-Adresse geleitet. Ausgehender Traffic wird über Ihre VPC weitergeleitet, die so konfiguriert werden kann, dass nur privater IP-Traffic zugelassen wird (siehe Abbildung 1).
Figure1

Die Kommunikation mit github.com wird zu einer öffentlichen IP-Adresse aufgelöst und ist daher von einer Looker-Instanz, die als „Privat“ oder „Öffentlich + Privat“ bereitgestellt wird, nicht erreichbar.
In diesem Codelab stellen Sie eine Southbound-HTTPS-Verbindung zu GitHub her. Dazu verwenden Sie einen internen TCP-Proxy-Load-Balancer und eine Internet-Netzwerkendpunktgruppe (NEG), die von Looker PSA aufgerufen wird.
Lerninhalte
- Netzwerkanforderungen
- Verbindung zu GitHub über „Verbindung testen“ in Looker herstellen
Voraussetzungen
- Google Cloud-Projekt mit Inhaberberechtigungen
- GitHub-Konto und ‑Repository
- Persönliches GitHub-Zugriffstoken (klassisch)
- Vorhandene Looker-PSA-Instanz mit aktivierter öffentlicher und privater oder nur privater IP-Adresse

2. Aufgaben
Sie stellen einen internen TCP-Proxy-Load-Balancer und eine Internet-NEG bereit, die mit der aufgelösten IP-Adresse von github.com konfiguriert ist und Cloud NAT für den Internet-Egress zu github.com-Organisationen nutzt, die von Looker aufgelöst werden.
3. Netzwerkanforderungen
Im Folgenden finden Sie eine Aufschlüsselung der Netzwerkanforderungen:
Komponenten | Beschreibung |
VPC ($vpc_network) | VPC im benutzerdefinierten Modus |
Subnetz der Weiterleitungsregel | Wird verwendet, um eine IP-Adresse für den regionalen internen TCP-Proxy-Load-Balancer zuzuweisen. |
Nur-Proxy-Subnetz | Jedem der Proxys 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. Der Endpunkt darf nicht nur über Cloud VPN oder Cloud Interconnect erreichbar sein. |
Backend-Dienst | Ein Back-End-Dienst fungiert als Brücke zwischen Ihrem Load-Balancer und Ihren Back-End-Ressourcen. Im Tutorial ist der Backend-Dienst mit der Internet-NEG verknüpft. |
Cloud Router | Cloud NAT nutzt Cloud Router für Funktionen der Steuerungsebene, aber nicht für die Verwaltung von BGP-Sitzungen. |
Cloud NAT | Die regionale Internet-NEG nutzt Cloud NAT für ausgehenden Internet-Traffic. |
4. Codelab-Topologie

5. Einrichtung und Anforderungen
Umgebung zum selbstbestimmten Lernen einrichten
- 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 eines erstellen.



- Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird. Sie können sie jederzeit aktualisieren.
- Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich (kann nach dem Festlegen nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (in der Regel als
PROJECT_IDangegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie einen eigenen Namen eingeben und prüfen, ob er 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
- Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs zu verwenden. Die Durchführung dieses Codelabs kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um Kosten zu vermeiden, die über diese Anleitung hinausgehen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am kostenlosen Testzeitraum mit einem Guthaben von 300 $ teilnehmen.
Cloud Shell starten
Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.
Klicken Sie in der Google Cloud Console rechts oben in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

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 in Google Cloud, was die 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]
vpc_network=[VPC Name]
echo $project
echo $region
echo $vpc-network
Aktivieren Sie alle erforderlichen Dienste:
gcloud services enable compute.googleapis.com
7. VPC-Netzwerkkomponenten
VPC-Netzwerk
Voraussetzung für das Tutorial ist eine vorhandene PSA Looker-Instanz. Die zugehörige VPC ist daher bereits erstellt.
Erstellen Sie in Cloud Shell das Subnetz für die Weiterleitungsregel:
gcloud compute networks subnets create psa-fr-subnet --network $vpc_network --range 172.16.20.0/28 --region $region --enable-private-ip-google-access
Erstellen Sie in Cloud Shell das regionale Nur-Proxy-Subnetz:
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
Public NAT-Gateway erstellen
Das NAT-Gateway wird vom regionalen internen TCP-Proxy-Load-Balancer für ausgehenden Internettraffic mit der Konfigurationsoption „–endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB“ verwendet. Daher unterstützt dasselbe NAT-Gateway keinen ausgehenden Internettraffic von GCE/GKE. Stellen Sie ein zusätzliches NAT-Gateway mit –endpoint-types=ENDPOINT_TYPE_VM für den Internet-Egress von GCE/GKE bereit.
Erstellen Sie den Cloud Router in Cloud Shell:
gcloud compute routers create $vpc_network-cloud-router --network $vpc_network --region $region
Erstellen Sie in Cloud Shell das Cloud NAT-Gateway, das den Internet-Egress für den TCP-Proxy-Load-Balancer ermöglicht:
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
IP-Adresse des Load-Balancers reservieren
Reservieren Sie in Cloud Shell eine interne IP-Adresse für den Load Balancer, die später als DNS-A-Eintrag für github.com verwendet wird:
gcloud compute addresses create internet-neg-lb-ip \
--region=$region \
--subnet=psa-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
8. Internet-NEG
Es gibt zwei Möglichkeiten, den externen Endpunkt zu konfigurieren, auf den die Internet-NEG verweist: INTERNET_FQDN_PORT oder INTERNET_IP_PORT. Wenn das Format INTERNET_IP_PORT (Option 1) ausgewählt wird, kann nur eine öffentliche, im Internet routingfähige IP-Adresse verwendet werden. Wenn das Format INTERNET_FQDN_PORT (Option 2) ausgewählt wird, kann der FQDN je nach Umfang des Endpunkts (regional oder global) entweder in eine öffentliche, im Internet routingfähige IP-Adresse oder in eine private IP-Adresse aufgelöst werden.
Option 1: Internet-NEG über IP-Adresse einrichten
Für das Internet-NEG ist die aufgelöste IP-Adresse von Github.com erforderlich. Öffnen Sie daher für eine optimale Leistung ein lokales Terminal, führen Sie einen „dig“-Befehl aus und rufen Sie die IP-Adresse von github.com ab.
Beispiel: Ein lokales Terminal generiert die aufgelöste IP-Adresse 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
Erstellen Sie eine Internet-NEG und legen Sie „–network-endpoint-type“ auf „internet_ip_port“ fest.
Erstellen Sie in Cloud Shell eine Internet-NEG für github.com:
gcloud compute network-endpoint-groups create github-internet-neg \
--network-endpoint-type=INTERNET_IP_PORT \
--network=$vpc_network \
--region=$region
Aktualisieren Sie in Cloud Shell das Internet-NEG „github-internet-neg“ mit der aufgelösten IP-Adresse von github.com und Port 443:
gcloud compute network-endpoint-groups update github-internet-neg \
--add-endpoint="ip=[your-resolved-ip],port=443" \
--region=$region
Beispiel:
gcloud compute network-endpoint-groups update github-internet-neg \
--add-endpoint="ip=140.82.113.4,port=443" \
--region=$region
Option 2: Internet-NEG mit FQDN einrichten
Optional können Sie eine Internet-NEG erstellen und „–network-endpoint-type“ auf „internet_FQDN_port“ festlegen.
Erstellen Sie in Cloud Shell eine Internet-NEG für github.com:
gcloud compute network-endpoint-groups create github-internet-neg \
--network-endpoint-type=INTERNET_FQDN_PORT \
--network=$vpc_network \
--region=$region
Aktualisieren Sie in Cloud Shell die Internet-NEG „github-internet-neg“ mit dem FQDN „github.com“:
gcloud compute network-endpoint-groups update github-internet-neg \
--add-endpoint="fqdn=github.com,port=443" \
--region=$region
9. GitHub-Dienst erstellen
Load Balancer-Komponenten erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
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
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=psa-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 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. GitHub-DNS-Zone
Im folgenden Abschnitt erstellen Sie eine DNS-Antwortrichtlinie für GitHub.com mit einem A-Eintrag, der aus der IP-Adresse des internen TCP-Proxy-Load-Balancers besteht.
Danach wird die Zone „github.com“ über DNS-Peering mit der Looker-PSA geteilt, sodass die Verbindung zu GitHub über den internen Load Balancer in Kombination mit dem Internet-NEG und Cloud NAT möglich ist.
Erstellen Sie in Cloud Shell die Antwortrichtlinienzone:
gcloud dns --project=$project response-policies create github-com --description="" --networks="$vpc_network"
Erstellen Sie in Cloud Shell den DNS-A-Eintrag, der aus der IP-Adresse des TCP-Proxy-Load-Balancers besteht: [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]"
Beispiel:
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"

DNS-Peering aktualisieren
In diesem Abschnitt verwenden Sie die Syntax gcloud services peered-dns-domains create, um eine DNS-Domain mit Peering für eine private Dienstverbindung zu erstellen. Damit werden Anfragen für Datensätze in einem bestimmten Namespace, die aus dem VPC-Netzwerk des Diensterstellers stammen, zur Auflösung an das VPC-Netzwerk des Dienstnutzers gesendet.
Erstellen Sie in Cloud Shell eine „peered-dns-domain“, die Looker für github.com abfragt:
gcloud services peered-dns-domains create github-com --project=$project --network=$vpc_network --dns-suffix=github.com.
11. Verbindung zu GitHub testen
In den folgenden Schritten erstellen Sie mit der Looker-Konsole ein Projekt, um die HTTPS-Verbindung zu github.com zu validieren.
12. Neues Projekt erstellen
Entwicklermodus aktivieren
Rufen Sie in der Looker Console Folgendes auf:
Aktivieren Sie den Entwicklungsmodus (unten links auf der Seite). Wenn er aktiviert ist, wird das Banner „Sie befinden sich im Entwicklungsmodus“ angezeigt.

Neues Projekt erstellen
Rufen Sie in der Cloud Console Folgendes auf:
„Entwickeln“ → „Projekte“

„Neues LookML-Projekt“ auswählen

Geben Sie einen Projektnamen ein, wählen Sie „Leeres Projekt“ aus und klicken Sie auf „Projekt erstellen“.

„Git konfigurieren“ auswählen

Git konfigurieren
Aktualisieren Sie die Repository-URL mit Ihren HTTPS-GitHub-Details. Hängen Sie dazu .git an die URL an und wählen Sie dann „Weiter“ aus.

Beispiel:

Aktualisieren Sie die Auswahl mit Ihrem GitHub-Nutzernamen und dem persönlichen Zugriffstoken (klassisch) und wählen Sie dann „Test and Finalize Setup“ (Einrichtung testen und abschließen) aus.

„Git-Aktionen“ auswählen

„Git-Verbindung testen“ auswählen

Git-Konnektivitätstest validieren

13. Bereinigen
Löschen Sie die Laborkomponenten über ein einzelnes Cloud Shell-Terminal:
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. Glückwunsch
Sie haben die Verbindung zu GitHub über die Looker-Konsole erfolgreich konfiguriert und validiert.
Cosmopup findet Codelabs toll!!
