Agentspace zu selbst gehosteter Datenbank für zonale NEG

1. Einführung

HINWEIS: In diesem Codelab finden Sie eine Konfigurationsanleitung für den Zugriff auf eine vorhandene selbst gehostete Datenbank in GCE über eine zonale NEG, die über Private Service Connect veröffentlicht wurde. Passen Sie das Codelab nach Bedarf an die spezifischen Anforderungen Ihrer Organisation an.

In diesem Codelab stellen Sie einen internen TCP-Proxy-Loadbalancer und eine zonale Netzwerk-Endpunktgruppe (NEG) bereit, die als PSC-Producer-Dienst veröffentlicht werden. Die NEG besteht aus einer oder mehreren Compute-Instanzen in GCP, auf denen eine Datenbank selbst gehostet wird, z. B. JIRA, Confluence oder SharePoint.

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 ihrem eigenen VPC- oder Cross-Cloud-Netzwerk hosten und ihren Nutzern eine private Verbindung bieten. Wenn Sie beispielsweise Private Service Connect verwenden, um auf eine zonale NEG zuzugreifen, sind Sie der Dienstersteller und Google (Agentspace) ist der Dienstnutzer.

Lerninhalte

• Netzwerkanforderungen für Agentspace
• Best Practices für die Vernetzung in Agentspace
• Private Service Connect-Producer-Dienst erstellen

Voraussetzungen

• Google Cloud-Projekt mit Inhaberberechtigungen

2. Aufgaben

Sie richten ein Erstellernetzwerk ein, agentspace-psc-demo, um einen internen TCP-Proxy-Load-Balancer und eine zonale NEG bereitzustellen, die als Dienst über Private Service Connect (PSC) veröffentlicht wird.

3. Netzwerkanforderungen

Im Folgenden finden Sie die Aufschlüsselung der Netzwerkanforderungen für das Produzentennetzwerk. Der Consumer in diesem Codelab ist Agentspace.

Komponenten	Beschreibung
VPC (agentspace-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. PSC NAT unterstützt ein /29-Subnetz pro Dienstanhang.
Subnetz der PSC-Weiterleitungsregel	Wird verwendet, um eine IP-Adresse für den regionalen internen TCP-Proxy-Load-Balancer zuzuweisen.Das Subnetz der Weiterleitungsregel gilt als reguläres Subnetz.
NEG-Subnetz	Wird verwendet, um der Netzwerk-Endpunktgruppe eine IP-Adresse aus einem regulären Subnetz zuzuweisen.
Nur-Proxy-Subnetz	Jedem der Proxys des Load-Balancers wird eine interne IP-Adresse zugewiesen. Pakete, die von einem Proxy an eine Back-End-VM oder eine Netzwerk-Endpunktgruppe gesendet werden, haben eine Quell-IP-Adresse aus dem Nur-Proxy-Subnetz.Ein /23-Subnetz wird empfohlen , obwohl das Minimum von /26 unterstützt wird. Pro Region ist ein regionales Proxy-Subnetz erforderlich.
Backend-Dienst	Ein Back-End-Dienst fungiert als Brücke zwischen Ihrem Load-Balancer und Ihren Back-End-Ressourcen. Im Tutorial ist der Back-End-Dienst mit der zonalen NEG verknüpft.

4. Best Practices

• Zonale NEGs unterstützen eine oder mehrere zonale GCE-Instanzen basierend auf GCE_VM_IP_PORT.
• Aktivieren Sie den globalen Zugriff für die Weiterleitungsregel des Dienstanbieters, bevor Sie den Dienstanhang erstellen.
• Aktivieren Sie beim Erstellen des Agentspace-Endpunkts den globalen Zugriff.
• Der interne TCP-Proxy-Load-Balancer unterstützt auch verwaltete und nicht verwaltete Instanzgruppen.
• Ein vorhandener Google Cloud-TCP-Proxy- oder Passthrough-Load-Balancer kann als Producer-Dienst bereitgestellt werden.

5. Codelab-Topologie

6. 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 eins 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 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_ID angegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie es mit einem eigenen Namen versuchen und sehen, 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

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 zu verwenden. Die Durchführung dieses Codelabs kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um weitere Kosten zu vermeiden, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am Programm Kostenlose Testversion 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 in der Symbolleiste oben rechts auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung dauert nur einen Moment. 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.

7. 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]
zone1a=[YOUR-ZONE1a]
zone1b=[YOUR-ZONE1b]
echo $project
echo $region
echo $zone1a
echo $zone1b

Aktivieren Sie alle erforderlichen Dienste:

gcloud services enable compute.googleapis.com

8. Ersteller-VPC-Netzwerk erstellen

VPC-Netzwerk

Führen Sie in Cloud Shell folgende Schritte aus:

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

Subnetze erstellen

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

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

gcloud compute networks subnets create producer-psc-nat-subnet --network agentspace-psc-demo --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

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

gcloud compute networks subnets create producer-psc-fr-subnet --network agentspace-psc-demo --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

Erstellen Sie in Cloud Shell das Subnetz für die Netzwerk-Endpunktgruppe:

gcloud compute networks subnets create neg-subnet --network agentspace-psc-demo --range 172.16.30.0/28 --region $region --enable-private-ip-google-access

Erstellen Sie in Cloud Shell das regionale Nur-Proxy-Subnetz für den Producer.

gcloud compute networks subnets create $region-proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=agentspace-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 zonal-neg-lb-ip \
  --region=$region \
  --subnet=producer-psc-fr-subnet

Sehen Sie sich in Cloud Shell die reservierte IP-Adresse an.

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

Beispielausgabe:

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

Zonale NEG einrichten

Im folgenden Abschnitt erstellen Sie eine zonale Netzwerkendpunktgruppe, die eine oder mehrere Kombinationen aus IP-Adresse oder IP-Adresse und Zielport enthält:

• Die primäre interne IPv4-Adresse einer VM-Netzwerkschnittstelle
• Die primäre interne IPv4-Adresse einer VM-Netzwerkschnittstelle plus eine Zielportnummer
• Eine interne IPv4-Adresse aus dem Alias-IP-Adressbereich, der einer VM-Netzwerkschnittstelle zugewiesen ist
• Eine interne IPv4-Adresse aus dem Alias-IP-Adressbereich, der einer VM-Netzwerkschnittstelle zugewiesen ist, sowie eine Zielportnummer

Die Netzwerkschnittstelle mit dem GCE_VM_IP_PORT-Endpunkt muss sich im Subnetz der NEG befinden. Wenn Sie bei einem GCE_VM_IP_PORT-Endpunkt eine Portnummer weglassen, verwendet Google Cloud die Standardportnummer der NEG für den Endpunkt.

In der Referenzarchitektur bestehen die GCE-Instanzen, die mit der zonalen NEG verknüpft sind, aus Folgendem:

• database-us-central1-a | us-central1-a | IP: 100.100.10.2 | Port: 443
• database-us-central1-a | us-central1-b | IP: 100.100.10.3 | Port: 443
• Subnetzname: database-subnet-1

Zonale NEG für zone1a erstellen

Im folgenden Abschnitt erstellen Sie die Netzwerk-Endpunktgruppe pro Zone, z. B. „us-central1-a“, und geben den Subnetznamen an, der zum Erstellen der GCE-Instanz verwendet wurde. In der Referenzarchitektur lautet der Subnetzname „database-subnet-1“.

Erstellen Sie in Cloud Shell ein zonales NEG:

gcloud compute network-endpoint-groups create us-central-zonal-neg-1a \
    --zone=$zone1a \
    --network=agentspace-psc-demo \
    --subnet=database-subnet-1 \
    --default-port=443

Aktualisieren Sie in Cloud Shell das zonale NEG mit der IP-Adresse und dem Port der GCE-Instanz, die in zone1a bereitgestellt wurde. In der Referenzarchitektur ist die GCE-Instanz 100.100.10.2 Port 443, die in der Zone us-central1-a bereitgestellt wurde.

gcloud compute network-endpoint-groups update us-central-zonal-neg-1a --zone=$zone1a --add-endpoint instance=database-us-central1-a,port=443

Zonale NEG für zone1b erstellen

Im folgenden Abschnitt erstellen Sie die Netzwerk-Endpunktgruppe pro Zone, z. B. „us-central1-b“, und geben den Subnetznamen an, der zum Erstellen der GCE-Instanz verwendet wurde. In der Referenzarchitektur lautet der Subnetzname „database-subnet-1“.

Erstellen Sie in Cloud Shell ein zonales NEG:

gcloud compute network-endpoint-groups create us-central-zonal-neg-1b \
    --zone=$zone1b \
    --network=agentspace-psc-demo \
    --subnet=database-subnet-1 \
    --default-port=443

Aktualisieren Sie in Cloud Shell das zonale NEG mit der IP-Adresse und dem Port der GCE-Instanz, die in zone1b bereitgestellt wurde. In der Referenzarchitektur ist die GCE-Instanz 100.100.10.3 Port 443, die in der Zone „us-central1-b“ bereitgestellt wurde.

gcloud compute network-endpoint-groups update us-central-zonal-neg-1b --zone=$zone1b --add-endpoint instance=database-us-central1-b,port=443

Regionale Systemdiagnose erstellen

Erstellen Sie in Cloud Shell eine Systemdiagnose, die den lokalen Datenbankport 443 prüft:

gcloud compute health-checks create tcp zonal-443-healthcheck \
    --region=$region \
    --port=443

Netzwerk-Firewallrichtlinie und Firewallregeln erstellen

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud compute network-firewall-policies create agentspace-psc-demo-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy agentspace-psc-demo-policy --network agentspace-psc-demo --name agentspace-psc-demo --global-firewall-policy

Die folgende Firewallregel lässt Traffic vom PSC-NAT-Subnetzbereich zu allen Instanzen im Netzwerk zu.

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud compute network-firewall-policies rules create 2001 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow traffic from PSC NAT subnet to GCE" --direction INGRESS --src-ip-ranges 172.16.10.0/28 --global-firewall-policy --layer4-configs=tcp

Die folgende Firewallregel lässt Traffic aus dem Bereich für Systemdiagnoseprüfungen zu allen Instanzen im Netzwerk zu. Der Port der Systemdiagnose und der Anwendungsport müssen übereinstimmen.

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud compute network-firewall-policies rules create 2002 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow internal probe health check range to GCE" --direction INGRESS --src-ip-ranges 35.191.0.0/16,130.211.0.0/22 --global-firewall-policy --layer4-configs=tcp:443

Die folgende Firewallregel lässt Traffic aus dem Nur-Proxy-Subnetz -Bereich zu allen Instanzen im Netzwerk zu. Das Proxy-Subnetz und der Anwendungsport müssen übereinstimmen.

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud compute network-firewall-policies rules create 2003 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow internal tcp proxy health check range to GCE" --direction INGRESS --src-ip-ranges 10.10.10.0/24 --global-firewall-policy --layer4-configs=tcp:443

9. Producer-Dienst erstellen

Load-Balancer-Komponenten erstellen

Erstellen Sie in Cloud Shell einen Back-End-Dienst:

gcloud compute backend-services create producer-backend-svc --region=$region --load-balancing-scheme=INTERNAL_MANAGED --protocol=TCP --region=$region --health-checks=zonal-443-healthcheck --health-checks-region=$region

Ordnen Sie in Cloud Shell die zonale NEG „us-central-zonal-neg-1a“ dem Backend-Dienst zu:

gcloud compute backend-services add-backend producer-backend-svc \
   --network-endpoint-group=us-central-zonal-neg-1a  \
   --network-endpoint-group-zone=$zone1a \
   --balancing-mode=CONNECTION \
   --max-connections-per-endpoint=100 \
   --region=$region

Ordnen Sie in Cloud Shell die zonale NEG „us-central-zonal-neg-1b“ dem Backend-Dienst zu:

gcloud compute backend-services add-backend producer-backend-svc \
   --network-endpoint-group=us-central-zonal-neg-1b  \
   --network-endpoint-group-zone=$zone1b \
   --balancing-mode=CONNECTION \
   --max-connections-per-endpoint=100 \
   --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) mit aktiviertem globalen Zugriff.

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud compute forwarding-rules create producer-zonal-neg-fr \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=agentspace-psc-demo \
     --subnet=producer-psc-fr-subnet \
     --address=zonal-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --allow-global-access \
     --ports=443

Back-End-Systemdiagnose validieren

Prüfen Sie im folgenden Abschnitt in der Cloud Console den Systemstatus (grüner Status) des Backend-Dienstes und der zugehörigen Compute-Instanzen. Rufen Sie Folgendes auf:

„Netzwerkdienste“ → „Load Balancing“ → „Producer-backend-svc“

Dienstanhang erstellen

Zum Veröffentlichen eines Dienstes müssen Sie einen Private Service Connect-Dienstanhang erstellen. Sie können den Dienst entweder mit automatischer oder mit expliziter Genehmigung veröffentlichen.

• Wenn Sie den Dienst veröffentlichen und allen Nutzern automatisch die Verbindung zu diesem Dienst ermöglichen möchten, folgen Sie der Anleitung unter Dienst mit automatischer Genehmigung veröffentlichen.
• Wenn Sie den Dienst mit expliziter Nutzergenehmigung veröffentlichen möchten, wählen Sie in den Verbindungseinstellungen des Dienstanhangs „Verbindungen für ausgewählte Projekte akzeptieren“ aus und lassen Sie das Feld „Akzeptierte Projekte“ leer.
• Nachdem Sie den Dienstanhang generiert haben, befinden sich Nutzerendpunkte, die Zugriff auf den Erstellerdienst anfordern, anfangs im Status „Ausstehend“. Um die Verbindung zu autorisieren, muss der Dienstersteller das Projekt akzeptieren, aus dem die Nutzerendpunktanfrage stammt.

Erstellen Sie in Cloud Shell die Service Attachment „cc-database1-svc-attachment“ mit automatischer Genehmigung:

gcloud compute service-attachments create zonal-database1-svc-attachment --region=$region --producer-forwarding-rule=producer-zonal-neg-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-subnet

Rufen Sie als Nächstes den Dienstanhang ab, der im selfLink-URI aufgeführt ist, der mit „projects“ beginnt, und notieren Sie ihn, um den PSC-Endpunkt im Agentspace zu konfigurieren.

selfLink: projects/<your-project-id>/regions/<your-region>/serviceAttachments/zonal-database1-svc-attachment

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud compute service-attachments describe zonal-database1-svc-attachment --region=$region

Beispiel für die erwartete Ausgabe:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2025-07-12T16:00:22.429-07:00'
description: ''
enableProxyProtocol: false
fingerprint: zOpeRQnPWSc=
id: '1784245893044590569'
kind: compute#serviceAttachment
name: zonal-database1-svc-attachment
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '119824781489996776'
  low: '1784245893044590569'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/serviceAttachments/zonal-database1-svc-attachment
targetService: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/forwardingRules/producer-zonal-neg-fr

Rufen Sie in der Cloud Console Folgendes auf:

„Network Services“ → „Private Service Connect“ → „Published Services“

10. PSC-Endpunktverbindung in Agentspace herstellen

Ordnen Sie den URI des Producer-Dienstanhangs dem Agentspace zu und achten Sie darauf, dass der globale Zugriff ausgewählt ist. Unten sehen Sie ein Beispiel für die Aktivierung des globalen Zugriffs mit der Referenzarchitektur „Service Attachment“.

Weitere Informationen zum Einrichten privater Netzwerke finden Sie unter Drittanbieter-Datenquellen in Agentspace.

PSC-Endpunkt in der Cloud Console validieren

Um eine erfolgreiche PSC-Verbindung zwischen Agentspace (dem Nutzer) und dem Ersteller zu bestätigen, prüfen Sie das Agentspace-Mandantenprojekt, das mit dem Erstellerservice verknüpft ist. Sie finden sie unter „Verknüpfte Projekte“. Die Mandantenprojekt-ID wird zufällig zugewiesen, endet aber immer mit „tp“.

In der Cloud Console können Sie die PSC-Verbindung prüfen. Rufen Sie in der Cloud Console Folgendes auf:

Wählen Sie „Network Services“ → „Private Service Connect“ → „Published Service“ aus und wählen Sie dann den Dienst „zonal-database1-svc-attachment“ aus.

11. Bereinigen

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

gcloud compute service-attachments delete zonal-database1-svc-attachment --region=$region -q

gcloud compute forwarding-rules delete producer-zonal-neg-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-firewall-policies rules delete 2001 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2002 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2003 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=agentspace-psc-demo-policy  --name=agentspace-psc-demo --global-firewall-policy -q

gcloud compute network-firewall-policies delete agentspace-psc-demo-policy --global -q

gcloud compute network-endpoint-groups delete us-central-zonal-neg-1a --zone=$zone1a -q

gcloud compute network-endpoint-groups delete us-central-zonal-neg-1b --zone=$zone1b -q

gcloud compute addresses delete zonal-neg-lb-ip --region=$region -q

gcloud compute networks subnets delete $region-proxy-only-subnet --region=$region -q

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

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

gcloud compute networks subnets delete neg-subnet --region=$region -q

gcloud compute health-checks delete zonal-443-healthcheck --region=us-central1 -q

gcloud compute networks delete agentspace-psc-demo -q

12. Glückwunsch

Herzlichen Glückwunsch! Sie haben einen Diensterstellerdienst mit Private Service Connect erfolgreich konfiguriert und veröffentlicht.

Sie haben die Producer-Infrastruktur erstellt und gelernt, wie Sie ein zonales NEG und einen Producer-Dienst erstellen und die Dienstanhänge mit Agentspace verknüpfen.

Cosmopup findet Codelabs toll!!

Nächste Schritte

Hier sind einige Codelabs:

• Private Service Connect zum Veröffentlichen und Nutzen von Diensten verwenden
• Zugriff auf alle veröffentlichten Private Service Connect-Codelabs

Weitere Informationen und Videos

• Private Service Connect – Übersicht

Referenzdokumente

• Interner Proxy-Network Load Balancer – Übersicht
• Regionalen internen Proxy-Network Load Balancer mit zonalen NEG-Back-Ends einrichten
• Dienste mit Private Service Connect veröffentlichen