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

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

Beschränkungen

Hinweise

  • 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 mit einer der folgenden Methoden Zugriff auf das VPC-Netzwerk hat:

  • 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 die Rolle Compute-Netzwerknutzer (roles/compute.networkUser) für das Dienstkonto von Cloud Run-Dienst-Agent 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 durch die durch Kommas getrennten Namen der Netzwerk-Tags ersetzen, 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. Verwenden Sie dazu das Beispiel für ausgehenden Direct VPC-Traffic für Cloud Run-Funktionen (2. Generation) als Ausgangspunkt:

  • 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 über das VPC-Netzwerk weiter. 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 Direct VPC Egress verwendet.

Internen Back-End-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 Back-End-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 konfiguriertem ausgehenden VPC-Traffic bereit, um den gesamten Traffic an Ihr Standard-VPC-Netzwerk weiterzuleiten:

    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