Anleitung zur Verwendung von Filestore mit Cloud Run

Diese Anleitung zeigt, wie Sie Filestore als Netzwerkdateisystem für einen Cloud Run-Dienst bereitstellen, um Daten zwischen mehreren Containern und Diensten zu teilen. In dieser Anleitung wird die Ausführungsumgebung der zweiten Generation von Cloud Run verwendet.

Die Ausführungsumgebung der zweiten Generation ermöglicht die Bereitstellung von Netzwerkdateisystemen in einem Verzeichnis in einem Container. Durch das Bereitstellen eines Dateisystems können Sie Ressourcen zwischen einem Hostsystem und Instanzen gemeinsam nutzen und Ressourcen beibehalten, nachdem für eine Instanz ein automatische Speicherbereinigung durchgeführt wurde.

Die Verwendung eines Netzwerkdateisystems mit Cloud Run erfordert erweiterte Docker-Kenntnisse, da der Container mehrere Prozesse ausführen muss, einschließlich der Dateisystembereitstellung und des Anwendungsprozesses. In dieser Anleitung werden die erforderlichen Konzepte anhand eines praktischen Beispiels erläutert. Wenn Sie diese Anleitung jedoch an Ihre eigene Anwendung anpassen, müssen Sie die Auswirkungen der möglichen Änderungen verstehen.

Designübersicht

Die Filestore-Instanz wird in einem VPC-Netzwerk (Virtual Private Cloud) gehostet. Ressourcen innerhalb eines VPC-Netzwerks verwenden einen privaten IP-Adressbereich, um mit Google APIs und Google-Diensten zu kommunizieren. Daher müssen sich Clients im selben Netzwerk wie die Filestore-Instanz befinden, um auf die auf dieser Instanz gespeicherten Dateien zugreifen zu können. Es ist ein Connector für serverlosen VPC-Zugriff erforderlich, damit der Cloud Run-Dienst eine Verbindung zum VPC-Netzwerk für die Kommunikation mit Filestore herstellen kann. Weitere Informationen zum Serverlosen VPC-Zugriff.

filesystem-architecture

Das Diagramm zeigt den Cloud Run-Dienst, der über einen Connector für serverlosen VPC-Zugriff eine Verbindung zur Filestore-Instanz herstellt. Die Filestore-Instanz und der Connector befinden sich im selben VPC-Netzwerk „default“ und in derselben Region/Zone wie der Cloud Run-Dienst, um eine optimale Leistung zu erzielen.

Beschränkungen

  • In dieser Anleitung wird nicht beschrieben, wie Sie ein Dateisystem oder produktionsbereite Anforderungen auswählen. Weitere Informationen zu Filestore und den verfügbaren Dienststufen

  • In dieser Anleitung wird nicht gezeigt, wie Sie mit einem Dateisystem arbeiten und geht nicht auf Dateizugriffsmuster ein.

Ziele

  • Erstellen Sie eine Filestore-Instanz im Standard-VPC-Netzwerk, das als Dateifreigabe dient.

  • Erstellen Sie einen Connector für serverlosen VPC-Zugriff im selben Standard-VPC-Netzwerk, um eine Verbindung zum Cloud Run-Dienst herzustellen.

  • Ein Dockerfile mit Systempaketen und dem init-Prozess erstellen, um die Bereitstellungs- und Anwendungsprozesse zu verwalten.

  • Bereitstellung in Cloud Run und Überprüfung des Zugriffs auf das Dateisystem im Dienst.

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten von Google Cloud verwendet, darunter:

Hinweis

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

    6. IAM-Berechtigungen steuern nur den Zugriff auf Filestore-Vorgänge, z. B. das Erstellen einer Filestore-Instanz. Verwenden Sie POSIX-Dateiberechtigungen, um den Zugriff auf Vorgänge in der Dateifreigabe zu steuern, z. B. Lesen oder Ausführen. Weitere Informationen zur Zugriffssteuerung.

  6. Enable the Cloud Run, Filestore, Serverless VPC Access, Artifact Registry, and Cloud Build APIs.

    Enable the APIs

  7. Installieren und initialisieren Sie die gcloud CLI.
  8. Aktualisieren Sie die Google Cloud CLI: gcloud components update

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Ausführen der Anleitung benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

gcloud-Standardeinstellungen einrichten

So konfigurieren Sie gcloud mit Standardeinstellungen für den Cloud Run-Dienst:

  1. Legen Sie ein Standardprojekt fest:

    gcloud config set project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch den Namen des Projekts, das Sie für diese Anleitung erstellt haben.

  2. Konfigurieren Sie gcloud für die von Ihnen ausgewählte Region:

    gcloud config set run/region REGION

    Ersetzen Sie REGION durch die unterstützte Cloud Run-Region Ihrer Wahl.

  3. Konfigurieren Sie gcloud für Filestore:

    gcloud config set filestore/zone ZONE

    Ersetzen Sie ZONE durch die unterstützte Filestore-Zone Ihrer Wahl.

Codebeispiel abrufen

So rufen Sie das gewünschte Codebeispiel ab:

  1. Klonen Sie das Repository der Beispiel-App auf Ihren lokalen Computer:

    Node.js 

    git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git

    Sie können auch das Beispiel als ZIP-Datei herunterladen und extrahieren.

    Python 

    git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git

    Sie können auch das Beispiel als ZIP-Datei herunterladen und extrahieren.

    Java 

    git clone https://github.com/GoogleCloudPlatform/java-docs-samples.git

    Sie können auch das Beispiel als ZIP-Datei herunterladen und extrahieren.

  2. Wechseln Sie in das Verzeichnis, das den Cloud Run-Beispielcode enthält:

    Node.js

    cd nodejs-docs-samples/run/filesystem/

    Python 

    cd python-docs-samples/run/filesystem/

    Java 

    cd java-docs-samples/run/filesystem/

Code verstehen

Normalerweise sollten Sie in einem Container einen einzelnen Prozess oder eine einzelne Anwendung ausführen. Die Ausführung eines einzelnen Prozesses pro Container vereinfacht die Verwaltung des Lebenszyklus mehrerer Prozesse: Verwaltung von Neustarts, Beenden des Containers, wenn ein Prozess fehlschlägt, und PID 1-Aufgaben wie Signalweiterleitung und Zombie Child Reaping. Wenn Sie jedoch Netzwerkdateisysteme in Cloud Run verwenden, müssen Sie Multi-Prozess-Container verwenden, um sowohl den Dateisystem-Bereitstellungsprozess als auch die Anwendung auszuführen. In dieser Anleitung wird gezeigt, wie der Container bei einem Prozessfehler beendet und die PID 1-Zuständigkeiten verwaltet werden. Der Bereitstellungsbefehl hat eine integrierte Funktion zur Verarbeitung von Wiederholungsversuchen.

Als Einstiegspunkt für den Container können Sie einen Prozessmanager zum Ausführen und Verwalten mehrerer Prozesse verwenden. In dieser Anleitung wird tini verwendet, ein Init-Ersatz, der Zombie-Prozesse bereinigt und die Signalweiterleitung durchführt. Insbesondere ermöglicht dieser Init-Prozess, das SIGTERM-Signal beim Herunterfahren an die Anwendung weiterzuleiten. Das SIGTERM-Signal kann für die ordnungsgemäße Beendigung der Anwendung genutzt werden. Weitere Informationen zum Lebenszyklus eines Containers in Cloud Run

Umgebungskonfiguration mit dem Dockerfile definieren

Für diesen Cloud Run-Dienst sind ein oder mehrere zusätzliche Systempakete erforderlich, die standardmäßig nicht verfügbar sind. Die RUN-Anweisung installiert tini als unseren Init-Prozess und nfs-common, das minimale NFS-Client-Funktionalität bietet. Weitere Informationen zum Arbeiten mit Systempaketen in Ihrem Cloud Run-Dienst finden Sie in der Anleitung zum Verwenden von Systempaketen.

Mit den nächsten Anweisungen erstellen Sie ein Arbeitsverzeichnis, kopieren den Quellcode und installieren die Anwendungsabhängigkeiten.

Der ENTRYPOINT gibt die Binärdatei des Init-Prozesses an, die der CMD-Anleitung vorangestellt ist. In diesem Fall ist es das Startskript. Dieser startet einen einzelnen Tini-Prozess und leitet dann alle empfangenen Signale an eine Sitzung weiter, die ihren Root in diesem untergeordneten Prozess haben.

Die CMD-Anweisung legt den Befehl fest, der beim Ausführen des Images, also des Startskripts, ausgeführt werden soll. Außerdem werden Standardargumente für den ENTRYPOINT bereitgestellt. Funktionsweise von CMD und ENTRYPOINT

Node.js

run/filesystem/Dockerfile 

# Use the official Node.js image.
# https://hub.docker.com/_/node
FROM node:20-slim

# Install system dependencies
RUN apt-get update -y && apt-get install -y \
    tini \
    nfs-common \
	libtool \
    && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/nfs/filestore

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY package*.json ./

# Install production dependencies.
RUN npm install --only=production

# Copy local code to the container image.
COPY . ./

# Ensure the script is executable
RUN chmod +x /app/run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Pass the wrapper script as arguments to tini
CMD ["/app/run.sh"]

Python

run/filesystem/Dockerfile 
# Use the official lightweight Python image.
# https://hub.docker.com/_/python
FROM python:3.11-slim

# Install system dependencies
RUN apt-get update -y && apt-get install -y \
    tini \
    nfs-common \
    && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/nfs/filestore

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./

# Install production dependencies.
RUN pip install -r requirements.txt

# Ensure the script is executable
RUN chmod +x /app/run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Pass the startup script as arguments to tini
CMD ["/app/run.sh"]

Java

run/filesystem/Dockerfile 

# Use the official maven image to create a build artifact.
# https://hub.docker.com/_/maven
FROM maven:3-eclipse-temurin-17-alpine as builder

# Copy local code to the container image.
WORKDIR /app
COPY pom.xml .
COPY src ./src

# Build a release artifact.
RUN mvn package -DskipTests

# Use Eclipse Temurin for base image.
# https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
FROM eclipse-temurin:18-jdk-focal

# Install filesystem dependencies
RUN apt-get update -y && apt-get install -y \
    tini \
    nfs-kernel-server \
    nfs-common \
    && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/nfs/filestore

# Copy the jar to the production image from the builder stage.
COPY --from=builder /app/target/filesystem-*.jar /filesystem.jar

# Copy the statup script
COPY run.sh ./run.sh
RUN chmod +x ./run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Run the web service on container startup.
CMD ["/run.sh"]

Prozesse im Startskript definieren

Das Startskript erstellt ein Verzeichnis als Bereitstellungspunkt, auf dem die Filestore-Instanz zugänglich sein wird. Als Nächstes verwendet das Skript den Befehl mount, um die Filestore-Instanz anzuhängen. Dazu werden die IP-Adresse und der Dateifreigabename der Instanz an den Bereitstellungspunkt des Dienstes angehängt und der Anwendungsserver wird gestartet. Der Befehl mount hat eine integrierte Wiederholungsfunktion. Daher ist keine weitere Bash-Skripterstellung erforderlich. Schließlich wird mit dem Befehl wait geprüft, ob Hintergrundprozesse beendet werden, und dann das Skript beendet.

Node.js

run/filesystem/run.sh 
#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service.
mkdir -p $MNT_DIR

echo "Mounting Cloud Filestore."
mount -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR
echo "Mounting completed."

# Start the application
node index.js &

# Exit immediately when one of the background processes terminate.
wait -n

Python

run/filesystem/run.sh 
#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service.
mkdir -p $MNT_DIR

echo "Mounting Cloud Filestore."
mount -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR
echo "Mounting completed."

# Run the web service on container startup. Here we use the gunicorn
# webserver, with one worker process and 8 threads.
# For environments with multiple CPU cores, increase the number of workers
# to be equal to the cores available.
# Timeout is set to 0 to disable the timeouts of the workers to allow Cloud Run to handle instance scaling.
exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

Java

run/filesystem/run.sh 
#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service
mkdir -p $MNT_DIR

echo "Mounting Cloud Filestore."
mount -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR
echo "Mounting completed."

# Start the application
java -jar filesystem.jar

# Exit immediately when one of the background processes terminate.
wait -n

Mit Dateien arbeiten

Node.js

Weitere Informationen zur Interaktion mit dem Dateisystem finden Sie unter index.js.

Python

Weitere Informationen zur Interaktion mit dem Dateisystem finden Sie unter main.py.

Java

Weitere Informationen zur Interaktion mit dem Dateisystem finden Sie unter FilesystemApplication.java.

Dienst versenden

  1. Filestore-Instanz erstellen:

    gcloud filestore instances create INSTANCE_ID \
    --tier=basic-hdd \
    --file-share=name=FILE_SHARE_NAME,capacity=1TiB \
    --network=name="default"

    Ersetzen Sie INSTANCE_ID durch den Namen der Filestore-Instanz, d. h. my-filestore-instance, und FILE_SHARE_NAME durch den Namen des Verzeichnisses, das von der Filestore-Instanz bereitgestellt wird, also vol1. Weitere Informationen finden Sie unter Instanz benennen und Dateifreigabe benennen.

    Clients (Cloud Run-Dienst) müssen sich im selben Netzwerk wie die Filestore-Instanz befinden, um auf die auf dieser Instanz gespeicherten Dateien zugreifen zu können. Mit diesem Befehl wird die Instanz im Standard-VPC-Netzwerk erstellt und ein freier IP-Adressbereich zugewiesen. Neue Projekte beginnen mit einem Standardnetzwerk und erstellen höchstwahrscheinlich kein separates Netzwerk.

    Weitere Informationen zur Instanzkonfiguration finden Sie unter Instanzen erstellen.

  2. Richten Sie einen Connector für serverlosen VPC-Zugriff ein.

    Zum Herstellen einer Verbindung zu Ihrer Filestore-Instanz benötigt Ihr Cloud Run-Dienst Zugriff auf das autorisierte VPC-Netzwerk der Filestore-Instanz.

    Jeder VPC-Connector benötigt ein eigenes /28-Subnetz, um Connector-Instanzen zu platzieren. Dieser IP-Bereich darf sich nicht mit vorhandenen IP-Adressreservierungen im VPC-Netzwerk überschneiden. 10.8.0.0 (/28) funktioniert beispielsweise in den meisten neuen Projekten oder Sie können einen anderen nicht verwendeten benutzerdefinierten IP-Bereich wie 10.9.0.0 angeben (/28). Sie können in der Google Cloud Console sehen, welche IP-Bereiche derzeit reserviert sind.

    gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
  --region REGION \
  --range "10.8.0.0/28"

    Ersetzen Sie CONNECTOR_NAME durch den Namen des Connectors.

    Dieser Befehl erstellt im Standard-VPC-Netzwerk einen Connector, der der Filestore-Instanz entspricht, mit der e2-micro-Maschinengröße. Wenn Sie die Maschinengröße des Connectors erhöhen, kann dadurch der Durchsatz erhöht werden, allerdings steigen auch die Kosten. Der Connector muss sich außerdem in derselben Region wie der Cloud Run-Dienst befinden. Serverlosen VPC-Zugriff konfigurieren

  3. Definieren Sie eine Umgebungsvariable mit der IP-Adresse für die Filestore-Instanz:

    export FILESTORE_IP_ADDRESS=$(gcloud filestore instances describe INSTANCE_ID --format "value(networks.ipAddresses[0])")

  4. Erstellen Sie ein Dienstkonto, das als Dienstidentität dient. Standardmäßig hat dieses keine anderen Berechtigungen als die Projektmitgliedschaft.

    gcloud iam service-accounts create fs-identity

    Dieser Dienst muss nicht mit anderen Komponenten in Google Cloud interagieren. Daher müssen diesem Dienstkonto keine zusätzlichen Berechtigungen zugewiesen werden.

  5. Erstellen Sie das Container-Image und stellen Sie es in Cloud Run bereit:

    gcloud run deploy filesystem-app --source . \
    --vpc-connector CONNECTOR_NAME \
    --execution-environment gen2 \
    --allow-unauthenticated \
    --service-account fs-identity \
    --update-env-vars FILESTORE_IP_ADDRESS=$FILESTORE_IP_ADDRESS,FILE_SHARE_NAME=FILE_SHARE_NAME

    Dieser Befehl erstellt den Cloud Run-Dienst, stellt ihn bereit und gibt den VPC-Connector und die Ausführungsumgebung der zweiten Generation an. Beim Bereitstellen aus der Quelle wird das Image basierend auf dem Dockerfile erstellt und das Image per Push in das Artifact Registry-Repository cloud-run-source-deploy übertragen.

    Weitere Informationen zum Bereitstellen aus Quellcode.

Debugging

Wenn die Bereitstellung nicht erfolgreich ist, prüfen Sie Cloud Logging auf weitere Details.

  • Wenn die Verbindung unterbrochen wird, prüfen Sie, ob Sie die richtige IP-Adresse der Filestore-Instanz angegeben haben.

  • Wenn der Zugriff vom Server verweigert wurde, prüfen Sie, ob der Name der Dateifreigabe korrekt ist.

  • Wenn Sie alle Logs aus dem Bereitstellungsprozess abrufen möchten, verwenden Sie das Flag --verbose in Kombination mit dem Bereitstellungsbefehl: mount --verbose -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR.

Testen

So testen Sie den gesamten Dienst:

  1. Rufen Sie im Browser die URL auf, die Sie im oben beschriebenen Bereitstellungsschritt erhalten haben.
  2. In Ihrer Filestore-Instanz sollte eine neu erstellte Datei angezeigt werden.
  3. Klicken Sie auf die Datei, um sich den Inhalt anzeigen zu lassen.

Wenn Sie sich dafür entscheiden, mit der Entwicklung dieser Dienste fortzufahren, denken Sie daran, dass diese nur eingeschränkten IAM-Zugriff (Identity and Access Management) auf den Rest von Google Cloud haben und ihnen zusätzliche IAM-Rollen zugewiesen werden müssen, um auf viele andere Dienste zugreifen zu können.

Kostendiskussion

Beispiel für die Kostenaufschlüsselung für einen Dienst, der in Iowa (us-central1) gehostet wird, mit einer Filestore-Instanz von 1 TiB und einem Connector für serverlosen VPC-Zugriff. Die aktuellen Preisseiten finden Sie auf den individuellen Preisseiten.

Produkt Kosten pro Monat
Filestore (nicht abhängig von der verwendeten Menge) Kosten = bereitgestellte Kapazität (1.024 GiB oder 1 TiB) * Preis der regionalen Stufe (us-central1)

Basis-HDD-Stufe: 1.024 GiB * 0,16 $/Monat = 163,84 $
Zonal (SSD): 1.024 GiB * 0,25 $/Monat = 256,00 $
Enterprise (SSD, regionale Verfügbarkeit): 1.024 GiB * 0,45 $/Monat = 460,80 $
Serverless VPC Access Kosten = Maschinengrößenpreis * Anzahl der Instanzen (Mindestanzahl der Instanzen ist standardmäßig 2)

f1-micro: 3,88 $ * 2 Instanzen = 7,76 $
e2- Micro: 6,11 $ * 2 Instanzen = 12,22 $
e2-standard-4: 97,83 $ * 2 Instanzen = 195,66 $
Cloud Run Kosten = CPU + Arbeitsspeicher + Anfragen + Netzwerk
Summe $163.84 + $12.22 = $176.06/mo + Cloud Run-Kosten

In dieser Anleitung wird eine Filestore-Instanz der Stufe Basic HDD verwendet. Die Dienststufe einer Filestore-Instanz setzt sich aus dem Instanztyp und dem Speichertyp zusammen. Der Instanztyp kann aktualisiert werden, um mehr Kapazität und Skalierbarkeit zu erzielen. Der Speichertyp kann aktualisiert werden, um die Leistung zu verbessern. Weitere Informationen zu Speichertypempfehlungen. Region und Kapazität wirken sich auch auf die Filestore-Preise aus. Beispiel: Eine Instanz der Stufe Basic HDD mit 1 TiB in Iowa (us-central1) kostet 0,16 $ pro GiB und Monat, was ungefähr 163,84 $ pro Monat entspricht.

Der Connector für den serverlosen VPC-Zugriff wird nach Instanzgröße und -anzahl sowie nach ausgehendem Netzwerkpreis abgerechnet. Wenn Sie Größe und Anzahl erhöhen, können Sie den Durchsatz verbessern oder die Latenz von Nachrichten reduzieren. Es gibt drei Maschinengrößen: f1-micro, e2-micro und e2-standard-4. Die Mindestanzahl der Instanzen ist 2, daher sind die Mindestkosten doppelt so hoch wie die Kosten dieser Maschinengröße.

Der Preis für Cloud Run wird nach Ressourcennutzung und auf die nächste Zehntelsekunde gerundet berechnet, wobei Arbeitsspeicher, CPU, Anzahl der Anfragen und Netzwerknutzung berücksichtigt werden. Daher variieren die Kosten je nach Diensteinstellungen, Anzahl der Anfragen und Ausführungszeit. Dieser Dienst kostet mindestens 176,06 $ pro Monat. Mit dem Google Cloud-Preisrechner können Sie einen Kostenvoranschlag erstellen und anzeigen lassen.

Bereinigen

Wenn Sie ein neues Projekt für diese Anleitung erstellt haben, löschen Sie das Projekt. Wenn Sie ein vorhandenes Projekt verwendet haben und es beibehalten möchten, ohne die Änderungen in dieser Anleitung hinzuzufügen, löschen Sie die für die Anleitung erstellten Ressourcen.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Anleitungsressourcen löschen

  1. Löschen Sie den Cloud Run-Dienst, den Sie in dieser Anleitung bereitgestellt haben:

    gcloud run services delete SERVICE-NAME

    Dabei ist SERVICE-NAME der von Ihnen ausgewählte Dienstname.

    Sie können Cloud Run-Dienste auch über die Google Cloud Console löschen.

  2. Entfernen Sie die Konfiguration der Standardregion gcloud, die Sie während der Einrichtung für die Anleitung hinzugefügt haben:

     gcloud config unset run/region

  3. Entfernen Sie die Projektkonfiguration:

     gcloud config unset project

  4. Löschen Sie sonstige Google Cloud-Ressourcen, die in dieser Anleitung erstellt wurden:

Nächste Schritte