Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Privater Cloud Run-Zugriff auf den globalen und regionalen Cloud Storage-Endpunkt

1. Einführung

Google API-Endpunkt

Google Cloud APIs bieten verschiedene Arten von Endpunkten für den Zugriff auf Dienste. Sie unterscheiden sich hauptsächlich in der Art und Weise, wie sie die Weiterleitung von Anfragen, den Datenstandort und die regionale Isolation handhaben.

Weitere Informationen finden Sie in der Produktdokumentation zu den API-Endpunkttypen.

Im Folgenden finden Sie eine Aufschlüsselung der globalen, regionalen und standortbezogenen Endpunkte:

Globale Endpunkte

Format : {service}.googleapis.com (z.B. storage.googleapis.com)
Beschreibung:Diese Endpunkte bieten einen einzigen globalen Zugriffspunkt auf einen Dienst. Sie geben keine Region in der URL an.
Weiterleitung:Anfragen werden von globalen Google Front Ends (GFEs) und dem globalen Load-Balancing für Dienste weitergeleitet. In der Regel wird der Traffic an die nächste fehlerfreie Region weitergeleitet, um die Latenz zu minimieren.
TLS-Terminierung:Erfolgt am GFE, das dem Client am nächsten ist. Dieses GFE befindet sich möglicherweise außerhalb der Google Cloud-Region, in der sich die Daten oder Ressourcen befinden.
Datenstandort: Für Daten bei der Übertragung werden keine Garantien gegeben. Daten können nach der Entschlüsselung am GFE regionale Grenzen überschreiten.
Regionale Isolation:Begrenzt. Während Backends oft regional sind, sind der Einstiegspunkt und das Load-Balancing global. Das bedeutet, dass Probleme in einem Teil der globalen Infrastruktur möglicherweise Auswirkungen auf Dienste in anderen Regionen haben können.
Anwendungsfall:Zugriff für allgemeine Zwecke, bei dem eine niedrige Latenz für geografisch verteilte Nutzer wichtig ist und ein strenger Datenstandort bei der Übertragung keine primäre Rolle spielt.

Regionale Endpunkte (REP)

Format : {service}.{location}.rep.googleapis.com (z.B. storage.us-east1.rep.googleapis.com)
Beschreibung:Diese Endpunkte bieten eine starke regionale Isolation und Garantien für den Datenstandort. Der Standort (eine bestimmte Google Cloud-Region) wird als Subdomain angegeben. Dies ist der moderne Standard und ersetzt standortbezogene Endpunkte.
Weiterleitung:Verwendet einen vollständig regionalisierten Frontend-Stack, einschließlich regionaler externer Load-Balancer und regionalem Load-Balancing für Dienste . Der gesamte Anfragepfad, von DNS bis zum Dienst-Backend, bleibt innerhalb der angegebenen Region.
TLS-Terminierung:Erfolgt innerhalb der angegebenen Region auf den regionalen externen Load-Balancern.
Datenstandort:Garantiert, dass Daten sowohl bei der Übertragung als auch bei der Verwendung in der angegebenen Region verbleiben. So werden strenge Compliance- und Souveränitätsanforderungen erfüllt.
Regionale Isolation:Stark. Fehler in der Frontend-Infrastruktur einer Region haben keine Auswirkungen auf andere Regionen.
Anwendungsfall:Anwendungen, die einen strengen Datenstandort, eine hohe regionale Isolation und Compliance erfordern.

Nicht jede Google API hat einen regionalen Endpunkt. Eine Liste aller unterstützten regionalen Endpunkte finden Sie hier.

Multiregionale regionale Endpunkte (mREP) sind ebenfalls regionale Endpunkte, z. B. „us“ (USA), „eu“ (Europäische Union) usw. (z. B. storage.us.rep.googleapis.com).

Standortbezogene Endpunkte (LEP)

Format : {location}-{service}.googleapis.com (z.B. us-east1-storage.googleapis.com)
Beschreibung:Diese Endpunkte waren ein früherer Ansatz, um standortspezifischen Zugriff zu ermöglichen. Der Standort ist Teil des Haupt-Hostnamens. Hinweis:Standortbezogene Endpunkte werden durch regionale Endpunkte ersetzt.
Weiterleitung:Verwendet weiterhin die globalen Google Front Ends.
TLS-Terminierung:Erfolgt in der Regel am GFE, das sich möglicherweise nicht in der im Hostnamen angegebenen Region befindet.
Datenstandort: Es kann **nicht garantiert werden** , dass Daten bei der Übertragung für Traffic aus dem öffentlichen Internet in der angegebenen Region verbleiben.
Regionale Isolation:Schwächer als bei regionalen Endpunkten, da sie die globale Frontend-Infrastruktur verwenden.
Anwendungsfall:Wurden in der Vergangenheit für einige regionale Zugriffsszenarien verwendet, werden aber jetzt im Allgemeinen zugunsten regionaler Endpunkte mit stärkeren Garantien nicht mehr empfohlen.

Private Service Connect für Google APIs

Private Service Connect ist eine Funktion des Google Cloud-Netzwerks, mit der Nutzer auf Producer-Dienste zugreifen können. Dazu gehört auch die Möglichkeit, über einen privaten Endpunkt, der in der VPC des Nutzers gehostet wird, eine Verbindung zu Google APIs herzustellen.

So verwenden Sie einen PSC-Endpunkt für den Zugriff auf Google APIs:

PSC-Endpunkt für globale Google APIs
PSC-Endpunkt für regionale Google APIs
Sie verwenden einen PSC-Endpunkt für globale Google APIs, um privat auf standortbezogene Google APIs zuzugreifen.

So verwenden Sie ein PSC-Backend für den Zugriff auf Google APIs:

PSC-Backend für globale Google APIs
PSC-Backend für regionale Google APIs
Sie verwenden ein PSC-Backend für globale Google APIs, um privat auf standortbezogene Google APIs zuzugreifen.

Cloud Run sendet Traffic an das VPC-Netzwerk

Ausgehender Direct VPC-Traffic bietet eine erweiterte Infrastruktur und eine einfachere Konfiguration von ausgehendem VPC-Traffic an Cloud Run, einschließlich folgender Vorteile:

Einrichtung: Cloud Run-Dienste und -Jobs können Traffic an ein VPC-Netzwerk senden, ohne dass ein Connector für serverlosen VPC-Zugriff verwaltet werden muss.
Kosten: Sie zahlen nur für Netzwerkverkehrsgebühren. Diese skalieren wie der Dienst selbst auf null.
Sicherheit: Für eine detailliertere Netzwerksicherheit können Sie Netzwerk-Tags direkt für Dienstüberarbeitungen verwenden.
Leistung: Niedrigere Latenz, höherer Durchsatz.

Sie können Ihren Cloud Run-Dienst, Ihre Funktion, Ihren Job oder Ihren Worker-Pool so aktivieren, dass der gesamte Traffic über ausgehenden Direct VPC-Traffic an ein VPC-Netzwerk gesendet wird.

2. Lerninhalte

PSC-Endpunkt für globale Google APIs erstellen
PSC-Endpunkt für regionale Google APIs erstellen
API-Endpunkt im Cloud Run-Code ändern und Netzwerk für ausgehenden Traffic konfigurieren

3. Gesamtarchitektur des Labs

4. Vorbereitungsschritte

Erforderliche IAM-Rollen für das Lab

Weisen Sie zuerst die erforderlichen IAM-Rollen dem GCP-Konto auf Projektebene zu.

Compute Network Admin (roles/compute.networkAdmin): Diese Rolle bietet Ihnen vollständige Kontrolle über die Compute Engine-Netzwerkressourcen.
Logging-Administrator (roles/logging.admin): Diese Rolle bietet Ihnen Zugriff auf alle Logging-Berechtigungen und abhängigen Berechtigungen.
Service Usage-Administrator (roles/serviceusage.serviceUsageAdmin): Mit dieser Rolle können Sie Dienststatus aktivieren, deaktivieren und überprüfen, Vorgänge überprüfen sowie Kontingent und Abrechnung für ein Nutzerprojekt verarbeiten.
DNS-Administrator (roles/dns.admin): Diese Rolle bietet Ihnen Lese-/Schreibzugriff auf alle Cloud DNS-Ressourcen.
Cloud Run Admin (roles/run.admin): Diese Rolle bietet Ihnen vollständige Kontrolle über alle Cloud Run-Ressourcen.
Storage-Administrator (roles/storage.admin): Diese Rolle bietet Ihnen vollständige Kontrolle über Objekte und Buckets.

APIs aktivieren

Achten Sie in Cloud Shell darauf, dass Ihr Projekt richtig konfiguriert ist, und legen Sie Ihre Umgebungsvariablen fest.

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud auth login
gcloud config set project <your project id>
export project_id=<your project id>
export region=<your region>
export zone=$region-a
echo $project_id
echo $region

Aktivieren Sie alle erforderlichen Google APIs im Projekt. Führen Sie in Cloud Shell folgende Schritte aus:

gcloud services enable \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  run.googleapis.com \
  compute.googleapis.com \
  dns.googleapis.com \
  servicedirectory.googleapis.com \
  networkconnectivity.googleapis.com

VPC erstellen

Erstellen Sie im Projekt ein VPC-Netzwerk mit benutzerdefiniertem Subnetzmodus. Führen Sie in Cloud Shell folgende Schritte aus:

gcloud compute networks create mynet \
    --subnet-mode=custom

Subnetze erstellen

Führen Sie in Cloud Shell folgende Schritte aus, um ein IPv4-Subnetz zu erstellen:

gcloud compute networks subnets create mysubnet \
    --network=mynet \
    --range=10.0.0.0/24 \
    --region=$region

Cloud NAT und Cloud Router erstellen

Cloud NAT wird verwendet, damit Cloud Run-Jobs eine Verbindung zu externen Websites herstellen können.

gcloud compute routers create $region-cr \
   --network=mynet \
   --region=$region 
gcloud compute routers nats create $region-nat \
    --router=$region-cr \
    --region=$region \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

5. PSC-Endpunkt für Cloud Storage erstellen

Sie erstellen zwei PSC-Endpunkte für Cloud Storage: einen für den globalen Bereich und einen für den regionalen Bereich.

PSC-Endpunkt mit globalem Bereich erstellen

Mit Private Service Connect können Sie private Endpunkte mit globalem Bereich mithilfe globaler interner IP-Adressen in Ihrem VPC-Netzwerk erstellen.

Sie müssen eine eindeutige IP-Adresse zuweisen, die nicht in Ihrer VPC definiert ist. Weitere Informationen zu dieser Anforderung an die IP-Adresse finden Sie in der Dokumentation.

Führen Sie in Cloud Shell folgende Schritte aus, um eine IP-Adresse zu erstellen. Ändern Sie „–addresses=<pscendpointip>“ so, dass die zugewiesene IP-Adresse verwendet wird.

gcloud compute addresses create pscglobalip \
    --global \
    --purpose=PRIVATE_SERVICE_CONNECT \
    --addresses=<pscendpointip> \
    --network=mynet
pscendpointip=$(gcloud compute addresses list --filter=name:pscglobalip --format="value(address)")
echo $pscendpointip

Erstellen Sie eine Weiterleitungsregel, um den Endpunkt mit Google APIs und Google-Diensten zu verbinden.

gcloud compute forwarding-rules create pscendpoint \
    --global \
    --network=mynet \
    --address=pscglobalip \
    --target-google-apis-bundle=all-apis

„p.googleapis.com“ in Cloud DNS prüfen

Wenn Sie einen Endpunkt erstellen, werden die folgenden DNS-Konfigurationen automatisch erstellt:

Eine private DNS-Zone von Service Directory wird für „p.googleapis.com“ erstellt.
DNS-Einträge werden in „p.googleapis.com“ für einige häufig verwendete Google APIs und Google-Dienste erstellt, die über Private Service Connect verfügbar sind und standardmäßig DNS-Namen haben, die auf „googleapis.com“ enden.

Globale Endpunkte sind im Service Directory registriert. Sie verwenden „storage-[psc endpoint name].p.googleapis.com“, um auf Cloud Storage zuzugreifen. Weitere Informationen finden Sie in der Produktdokumentation.

Prüfen Sie mit dem folgenden Befehl, ob die Zone „p.googleaps.com“ bereits erstellt wurde.

gcloud dns managed-zones list

Wenn Sie den Standard-DNS-Namen „storage.googleapis.com“ verwenden möchten, erstellen Sie in Cloud DNS eine private Zone „storage.googleapis.com“ und fügen einen Apex-Eintrag hinzu, der auf die IP-Adresse des PSC-Endpunkts mit globalem Bereich verweist.

PSC-Endpunkt mit regionalem Bereich für Cloud Storage erstellen

Sie benötigen eine IP-Adresse aus dem VPC-Subnetz. Führen Sie den folgenden Befehl aus. Eine IP-Adresse aus dem Subnetz wird für den PSC-Endpunkt zugewiesen.

gcloud network-connectivity regional-endpoints create psc-regional-endpoint \
    --region=$region \
    --network=projects/$project_id/global/networks/mynet \
    --subnetwork=projects/$project_id/regions/$region/subnetworks/mysubnet \
    --target-google-api=storage.us-central1.rep.googleapis.com

Rufen Sie die IP-Adresse des Endpunkts ab, die im vorherigen Schritt erstellt wurde.

regionalip=$(gcloud network-connectivity regional-endpoints describe psc-regional-endpoint --region=$region --format="value(address)")
echo $regionalip

Sie verwenden „storage.us-central1.rep.googleapis.com“, um auf Cloud Storage zuzugreifen. Sie müssen eine private Zone für „storage.us-central1.rep.googleapis.com“ und den Apex-Eintrag der IP-Adresse erstellen, die Sie gerade für den regionalen Endpunkt in Cloud DNS erstellt haben.

Private Zone für regionalen Cloud Storage-Endpunkt erstellen

Sie verwenden „storage.[region name].rep.googleapis.com“, um auf den regionalen Cloud Storage-Endpunkt zuzugreifen.

Sie müssen eine private Zone in Cloud DNS erstellen und einen Apex-Eintrag hinzufügen, der auf die IP-Adresse des regionalen Cloud Storage-Endpunkts verweist.

Im folgenden Befehl ist „us-central1“ die Beispielregion. Sie sollten die Zone mit dem Namen Ihrer Region erstellen.

gcloud dns managed-zones create psc-regional-endpoint-zone \
  --description="" \
  --dns-name="storage.us-central1.rep.googleapis.com" \
  --visibility="private" \
  --networks="mynet"

gcloud dns record-sets create storage.us-central1.rep.googleapis.com. \
  --rrdatas=$regionalip \
  --ttl=300 \
  --type=A \
  --zone=psc-regional-endpoint-zone

6. Cloud Run-Job mit PSC-Endpunkt mit globalem Bereich konfigurieren

Code abrufen

Zuerst sehen Sie sich eine Node.js-Anwendung an, mit der Screenshots von Webseiten erstellt und in Cloud Storage gespeichert werden. Später erstellen Sie ein Container-Image für die Anwendung und führen es als Job in Cloud Run aus.

Führen Sie in Cloud Shell den folgenden Befehl aus, um den Anwendungscode aus diesem Repository zu klonen:

git clone https://github.com/GoogleCloudPlatform/jobs-demos.git

Wechseln Sie zum Verzeichnis mit der Anwendung:

cd jobs-demos/screenshot

Die Dateistruktur sollte so aussehen:

├── Dockerfile

├── README.md

├── screenshot.js

├── package.json

Hier finden Sie eine kurze Beschreibung der einzelnen Dateien:

„screenshot.js“ enthält den Node.js-Code für die Anwendung. Die Anwendung erstellt Screenshots von Webseiten und speichert sie in Cloud Storage.
„package.json“ definiert die Bibliotheksabhängigkeiten.
„Dockerfile“ definiert das Container-Image.

Öffnen Sie den Code „screenshot.js“ und ändern Sie „apiEndpoint“ in den globalen PSC-Endpunkt. Suchen Sie den Code und ersetzen Sie const storage = new Storage(); durch Folgendes:

const storage = new Storage(
    {
      apiEndpoint:'https://storage-pscendpoint.p.googleapis.com.',
      useAuthWithCustomEndpoint: true
    }
  );

Job bereitstellen

Bevor Sie einen Job erstellen, müssen Sie ein Dienstkonto erstellen, mit dem Sie den Job ausführen.

gcloud iam service-accounts create screenshot-sa --display-name="Screenshot app service account"

Weisen Sie dem Dienstkonto die Rolle „storage.admin“ zu, damit es zum Erstellen von Buckets und Objekten verwendet werden kann.

gcloud projects add-iam-policy-binding $project_id \
  --role roles/storage.admin \
  --member serviceAccount:screenshot-sa@$project_id.iam.gserviceaccount.com

Weisen Sie dem Standard-Compute-Dienstkonto die Rolle „Storage Object User“ , „Logs Writer“ und „Artifact Registry Repository Administrator“ zu.

project_number=$(gcloud projects describe $project_id --format="value(projectNumber)")

gcloud projects add-iam-policy-binding $project_id \
  --role roles/storage.objectUser \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

gcloud projects add-iam-policy-binding $project_id \
  --role roles/logging.logWriter \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

gcloud projects add-iam-policy-binding $project_id \
  --role roles/artifactregistry.repoAdmin \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

Sie aktivieren ausgehenden Direct VPC-Traffic für Cloud Run-Jobs, um den gesamten Traffic an ein VPC-Netzwerk zu senden.

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud run jobs deploy screenshot-1 \
  --source=. \
  --args="https://example.com" \
  --args="https://cloud.google.com" \
  --tasks=2 \
  --task-timeout=5m \
  --region=$region \
  --set-env-vars=BUCKET_NAME=screenshot-$project_id-$RANDOM \
  --service-account=screenshot-sa@$project_id.iam.gserviceaccount.com \
  --vpc-egress=all-traffic \
  --network=mynet \
  --subnet=mysubnet

Job ausführen

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud run jobs execute screenshot-1 --region=$region

Prüfen Sie den Status des Jobs und die Logs. Suchen Sie in der Cloud Run Console nach dem Job. Klicken Sie auf den Job und prüfen Sie den Logverlauf. Sie sehen ein ähnliches Ergebnis der Jobausführung wie unten.

Klicken Sie in der Aufgabe auf „Log ansehen“, um detaillierte Logs zur Jobausführung aufzurufen. Sie sehen ähnliche Joblogs wie unten.

Ein neuer Bucket wurde erstellt. Sie können in der Cloud Storage Console den neu erstellten Bucket prüfen. Da Sie den globalen Cloud Storage-Endpunkt verwenden, ist der Bucket ein multiregionaler Bucket. Sie können die in den Bucket hochgeladenen Bilder prüfen.

Das Testergebnis zeigt, dass Cloud Run privat auf den globalen Cloud Storage-Endpunkt zugegriffen hat, den Sie im Cloud Run-Job geändert haben:

apiEndpoint:‘https://storage-pscendpoint.p.googleapis.com.'

7. Cloud Run-Job mit PSC-Endpunkt mit regionalem Bereich konfigurieren

Ändern Sie im Code „apiEndpoint“ in den PSC-Endpunkt mit regionalem Bereich.

Suchen Sie den Code und ersetzen Sie const storage = new Storage(); durch Folgendes ( wir verwenden „us-central1“ als Beispiel. Ändern Sie es in Ihre Region.) :

const storage = new Storage(
    {
      apiEndpoint:'https://storage.us-central1.rep.googleapis.com.',
      useAuthWithCustomEndpoint: true
    }
  );

Job bereitstellen

Achten Sie darauf, dass Sie sich im Verzeichnis mit der Anwendung befinden (jobs-demos/screenshot).

pwd

Sie aktivieren ausgehenden Direct VPC-Traffic für Jobs, um den gesamten Traffic an ein VPC-Netzwerk zu senden.

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud run jobs deploy screenshot-2 \
  --source=. \
  --args="https://example.com" \
  --args="https://cloud.google.com" \
  --tasks=2 \
  --task-timeout=5m \
  --region=$region \
  --set-env-vars=BUCKET_NAME=screenshot-$PROJECT_ID-$RANDOM \
  --service-account=screenshot-sa@$project_id.iam.gserviceaccount.com \
  --vpc-egress=all-traffic \
  --network=mynet \
  --subnet=mysubnet

Job ausführen

Führen Sie in Cloud Shell folgende Schritte aus:

gcloud run jobs execute screenshot-2 --region=$region

Prüfen Sie den Status des Jobs und die Logs. Suchen Sie in der Cloud Run Console nach dem Job. Klicken Sie auf den Job und prüfen Sie den Jobverlauf. Sie sehen ein ähnliches Ergebnis der Jobausführung wie unten.

Klicken Sie auf „Log ansehen“, um detaillierte Logs zur Jobausführung aufzurufen. Sie sehen ähnliche Joblogs wie unten.

Ein neuer Bucket wurde erstellt. Sie können in der Cloud Storage Console den neu erstellten Bucket prüfen. Da Sie den regionalen Cloud Storage-Endpunkt verwenden, ist der Bucket ein Bucket mit einer einzelnen Region. Sie können die in den Bucket hochgeladenen Bilder prüfen.

Das Testergebnis zeigt, dass Cloud Run privat auf den regionalen Cloud Storage-Endpunkt zugegriffen hat, den Sie im Cloud Run-Job geändert haben:

apiEndpoint:‘https://storage.us-central1.rep.googleapis.com.'

8. Bereinigen

Cloud Run-Job bereinigen

gcloud run jobs delete screenshot-1 \
  --region=$region --quiet
gcloud run jobs delete screenshot-2 \
  --region=$region --quiet

gcloud iam service-accounts delete screenshot-sa@$project_id.iam.gserviceaccount.com --quiet

PSC-Endpunkt bereinigen

gcloud compute forwarding-rules delete pscendpoint \
    --global --quiet
gcloud network-connectivity regional-endpoints delete psc-regional-endpoint \
    --region=$region --quiet
gcloud compute addresses delete pscglobalip \
    --global --quiet

Cloud NAT, Cloud Router und VPCs bereinigen

gcloud compute routers nats delete $region-nat \
    --router=$region-cr \
    --region=$region --quiet
gcloud compute routers delete $region-cr \
    --region=$region --quiet
gcloud compute networks subnets delete mysubnet \
    --region=$region --quiet
gcloud compute networks delete mynet --quiet

9. Glückwunsch

Sie haben den privaten Zugriff von Cloud Run auf Cloud Storage über den globalen und den regionalen Endpunkt erfolgreich getestet.