Ausgehenden Direct VPC-Traffic für Funktionen der 2. Generation konfigurieren

Mit ausgehendem Direct VPC-Traffic können Sie Traffic von Ihrer Cloud Run-Funktion (2. Generation) direkt an Ihr VPC-Netzwerk weiterleiten.

Beschränkungen

Hinweis

  • Wählen Sie die Cloud Functions API aus.
  • Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit dem Befehl gcloud init.

  • Aktualisieren Sie die gcloud-Komponenten auf Version 558.0.0 oder höher: 

    gcloud components update

  • Wenn Sie in Ihrem Projekt noch kein VPC-Netzwerk haben, erstellen Sie eins.

  • Optional: Wenn Ihre Funktion über die internen IP-Adressen auf Google APIs und ‑Dienste zugreifen muss, aktivieren Sie den privater Google-Zugriff für das Subnetz, das Sie für den direkten VPC-Ausgang verwenden.

IAM-Berechtigungen einrichten

Wenn Sie den direkten VPC-Ausgang autorisieren möchten, bitten Sie Ihren Administrator, dem Dienstkonto Ihrer Funktion die Rolle „Cloud Run Invoker“ (roles/run.invoker) zuzuweisen.

Achten Sie darauf, dass Cloud Run Zugriff auf das VPC-Netzwerk hat. Verwenden Sie dazu eine der folgenden Methoden:

  • Rolle „Cloud Run-Dienst-Agent“: Standardmäßig hat der Cloud Run-Dienst-Agent die Rolle Cloud Run-Dienst-Agent (roles/run.serviceAgent), die die erforderlichen Berechtigungen enthält.

  • Benutzerdefinierte Berechtigungen: Für eine detaillierte Kontrolle erteilen Sie dem Cloud Run-Dienst-Agent die folgenden zusätzlichen Berechtigungen für das Projekt:

    • compute.networks.get
    • compute.subnetworks.get
    • compute.subnetworks.use für das Projekt oder das jeweilige Subnetz
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.create (nur für Dual-Stack-Subnetze mit externen IPv6-Adressen erforderlich)
    • compute.addresses.delete (nur für Dual-Stack-Subnetze mit externen IPv6-Adressen erforderlich)
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal
    • compute.regionOperations.get

  • Rolle „Compute-Netzwerknutzer“: Wenn Sie die Standardrolle „Cloud Run-Dienst-Agent“ oder die benutzerdefinierten Berechtigungen nicht verwenden, weisen Sie dem Dienstkonto des Cloud Run-Dienst-Agents die Rolle Compute-Netzwerknutzer (roles/compute.networkUser) zu. Für Subnetze mit externen IPv6-Adressen ist auch die Rolle Administrator öffentlicher IP-Adressen für Compute Engine (roles/compute.publicIpAdmin) erforderlich.

    Wenn Sie beispielsweise die Rolle „Compute Network User“ zuweisen möchten, führen Sie den folgenden Befehl aus:

    gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com" \
--role "roles/compute.networkUser"

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • PROJECT_NUMBER: Die Projektnummer, in der Sie Ihre Cloud Run-Funktion bereitstellen.

Ausgehenden Direct VPC-Traffic konfigurieren

Ausgehenden Direct VPC-Traffic für neue oder vorhandene Funktionen der 2. Generation konfigurieren

gcloud

  1. Wenn Sie beim Bereitstellen einer Funktion ausgehenden VPC-Traffic konfigurieren möchten, verwenden Sie den Befehl gcloud functions deploy mit Flags für Ihre Netzwerkeinstellungen.

    gcloud functions deploy FUNCTION_NAME \
    --source . \
    --runtime RUNTIME \
    --trigger-http \
    --region REGION \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --direct-vpc-egress=EGRESS_SETTING

    Ersetzen Sie Folgendes:

    • FUNCTION_NAME: Der Name Ihrer Funktion.
    • RUNTIME: Die Laufzeit für Ihre Funktion, z. B. nodejs20.
    • REGION: die Region, in der Sie Ihre Funktion bereitstellen.
    • Optional: NETWORK durch den Namen Ihres VPC-Netzwerks. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, hat das Subnetz denselben Namen wie das Netzwerk.
    • Optional: SUBNET durch den Namen Ihres Subnetzes. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, verwendet das Subnetz denselben Namen wie das Netzwerk. Sie können mehrere Funktionen im selben Subnetz bereitstellen oder ausführen.
    • Optional: NETWORK_TAG_NAMES mit den kommagetrennten Namen der Netzwerk-Tags, die Sie mit einer Funktion verknüpfen möchten. Jede Funktion kann unterschiedliche Netzwerk-Tags haben, z. B. network-tag-2.
    • EGRESS_SETTING durch einen Wert für die Einstellung für ausgehenden Traffic:
      • all: Standard. Sendet den gesamten ausgehenden Traffic über das VPC-Netzwerk.
      • private-ranges-only: Sendet nur Traffic an interne Adressen über das VPC-Netzwerk.

  2. Optional: Wenn Sie alle Einstellungen für ausgehenden Direct VPC-Traffic aus einer Funktion entfernen möchten, stellen Sie die Funktion mit den Flags --clear-network und --clear-network-tags neu bereit.

Terraform

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

Mit dieser Funktion (Unterstützung für die Verwendung von Direct VPC-Ausgang mit Cloud Run-Funktionen der 2. Generation) werden die Felder direct_vpc_network_interface.network und direct_vpc_egress hinzugefügt.

Beachten Sie bei der Verwendung dieser Funktion die folgenden Richtlinien:

  • Sie müssen Terraform-Version 7.21.0 oder höher verwenden.
  • Wenn Sie eine Funktion mit vorhandener Direct VPC neu bereitstellen, müssen Sie die Werte in der Konfiguration jetzt explizit festlegen.

Aktualisieren Sie die folgenden Felder anhand des Beispiels für ausgehenden Direct VPC-Traffic für Cloud Run-Funktionen (2. Generation):

  • service_config.direct_vpc_network_interface.network: der Name des VPC-Netzwerk.
  • service_config.direct_vpc_network_interface.subnetwork: der Name des VPC-Subnetzwerks.
  • service_config.direct_vpc_egress: welcher Traffic an das VPC-Netzwerk gesendet werden soll. VPC_EGRESS_ALL_TRAFFIC leitet den gesamten ausgehenden Traffic durch das VPC-Netzwerk. VPC_EGRESS_PRIVATE_RANGES_ONLY sendet Traffic nur an private IP-Adressbereiche im VPC-Netzwerk.

Beispiel: Internen Dienst über eine Funktion aufrufen

In diesem Beispiel wird gezeigt, wie Sie einen internen Cloud Run-Dienst erstellen und ihn dann über eine Cloud Run Functions-Funktion (2. Generation) aufrufen, die direkten ausgehenden VPC-Traffic verwendet.

Internen Backend-Dienst erstellen

  1. Erstellen Sie ein neues Verzeichnis für den Backend-Dienst und wechseln Sie dorthin:

    mkdir backend-service
cd backend-service

  2. Erstellen Sie eine package.json-Datei mit folgendem Inhalt:

    {
    "name": "backend-service",
    "version": "1.0.0",
    "description": "",
    "scripts": {
        "start": "node index.js"
    },
    "dependencies": {
        "express": "^4.18.1"
    }
}

  3. Erstellen Sie eine index.js-Datei mit folgendem Inhalt:

    const express = require('express');
const app = express();

app.get('/', (req, res) => {
    res.send("hello world");
});

const port = parseInt(process.env.PORT) || 8080;
app.listen(port, () => {
    console.log(`helloworld: listening on port ${port}`);
});

  4. Stellen Sie den Dienst in Cloud Run mit internem Ingress bereit:

    gcloud run deploy backend \
    --source . \
    --no-allow-unauthenticated \
    --region=REGION \
    --ingress internal

    Ersetzen Sie REGION durch Ihre Region, z. B. us-west1.

  5. Speichern Sie die URL des neuen Dienstes. Sie benötigen sie im nächsten Abschnitt.

Funktion erstellen und bereitstellen

  1. Erstellen Sie ein neues Verzeichnis für die Funktion und wechseln Sie dorthin:

    cd ..
mkdir dvpc-function
cd dvpc-function

  2. Erstellen Sie eine package.json-Datei mit folgendem Inhalt:

    {
  "name": "sample-http",
  "version": "0.0.1",
  "dependencies": {
    "axios": "0.21.1",
    "@google-cloud/functions-framework": "^3.0.0"
  }
}

  3. Erstellen Sie eine index.js-Datei mit folgendem Inhalt: Mit diesem Code wird eine authentifizierte Anfrage an den internen Backend-Dienst gesendet.

    const axios = require('axios');
const functions = require('@google-cloud/functions-framework');

const callVPCService = async (req, res) => {
  const backendUrl = process.env.BACKEND_URL;

  if (!backendUrl) {
    console.error('BACKEND_URL environment variable not set.');
    res.status(500).send('BACKEND_URL not configured.');
    return;
  }

  try {
    const metadataServerURL = 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=';
    const tokenUrl = metadataServerURL + backendUrl;

    const tokenResponse = await axios.get(tokenUrl, {
      headers: {
        'Metadata-Flavor': 'Google',
      },
    });
    const token = tokenResponse.data;

    const response = await axios.get(backendUrl, {
      headers: {
        Authorization: `bearer ${token}`,
      },
});

res.status(200).send(`Response from backend: ${response.data}`);
  } catch (error) {
    console.error(`Error calling backend service: ${error.message}`);
    res.status(500).send(`Error calling backend: ${error.message}`);
  }
};

functions.http('callVPCService', callVPCService);

  4. Stellen Sie die Funktion mit ausgehendem Direct VPC-Traffic bereit, der so konfiguriert ist, dass der gesamte Traffic an Ihr Standard-VPC-Netzwerk weitergeleitet wird:

    gcloud functions deploy my-2ndgen-function \
  --source . \
  --runtime nodejs20 \
  --trigger-http \
  --entry-point callVPCService \
  --network=default \
  --subnet=default \
  --direct-vpc-egress=all \
  --region=REGION \
  --allow-unauthenticated \
  --set-env-vars BACKEND_URL=BACKEND_URL

    Ersetzen Sie Folgendes:

    • REGION: die Region, in der Sie den Backend-Dienst bereitgestellt haben.
    • BACKEND_URL: die URL des von Ihnen erstellten Backend-Dienstes.

  5. Nachdem die Funktion bereitgestellt wurde, können Sie sie aufrufen, indem Sie ihre URL aufrufen. Die Funktion ruft den internen Backend-Dienst auf und gibt dessen Antwort zurück.

Nächste Schritte