Anleitung zum Erstellen eines WebSocket-Chatdienstes für Cloud Run

In dieser Anleitung erfahren Sie, wie Sie einen Multiroom-Echtzeit-Chatdienst mithilfe von WebSockets mit einer persistenten Verbindung für bidirektionale Kommunikation erstellen. Mit WebSockets können sowohl der Client als auch der Server Nachrichten gegenseitig übertragen, ohne den Server nach Updates abzufragen.

Obwohl Cloud Run die Anzahl der Containerinstanzen automatisch skaliert, um den gesamten Traffic zu verarbeiten, bietet Cloud Run keine Sitzungsaffinität. Das bedeutet, dass jede neue Anfrage an eine andere Containerinstanz weitergeleitet werden kann. Nutzernachrichten müssen daher im Chatdienst über alle Containerinstanzen hinweg synchronisiert werden, und nicht nur zwischen den Clients, die mit einer Containerinstanz verbunden sind.

Designübersicht

Dieser Beispiel-Chatdienst verwendet eine Memorystore for Redis-Instanz, um Nutzernachrichten in allen Container-Instanzen zu speichern und zu synchronisieren. Redis verwendet einen Pub/Sub-Mechanismus, der nicht mit dem Produkt Cloud Pub/Sub verwechselt werden sollte, um Daten an abonnierte Clients zu senden, die mit einer Container-Instanz verbunden sind, um HTTP-Abfragen zu vermeiden.

Selbst bei Push-Updates erhält jede hochgefahrene Containerinstanz nur neue Nachrichten an den Container. Zum Laden vorheriger Nachrichten muss der Nachrichtenverlauf gespeichert und aus einer nichtflüchtigen Speicherlösung abgerufen werden. In diesem Beispiel werden die konventionellen Funktionen eines Objektspeichers von Redis zum Zwischenspeichern und Abrufen des Nachrichtenverlaufs verwendet.

Architekturdiagramm
Das Diagramm zeigt mehrere Clientverbindungen zu jeder Cloud Run-Containerinstanz. Jede Containerinstanz stellt über einen Connector für serverlosen VPC-Zugriff eine Verbindung zu einer Memorystore for Redis-Instanz her.

Die Redis-Instanz ist über private IP-Adressen mit Zugriffssteuerung geschützt und auf Dienste beschränkt, die im selben virtuellen privaten Netzwerk wie die Redis-Instanz ausgeführt werden. Daher ist ein Connector für serverlosen VPC-Zugriff erforderlich, damit der Cloud Run-Dienst eine Verbindung zu Redis herstellen kann. Weitere Informationen zum Serverlosen VPC-Zugriff.

Beschränkungen

  • In dieser Anleitung wird weder auf Endnutzerauthentifizierungs- oder Sitzungs-Caching eingegangen. Weitere Informationen zur Endnutzerauthentifizierung finden Sie in der Cloud Run-Anleitung zur Endnutzerauthentifizierung.

  • In dieser Anleitung wird keine Datenbank wie Firestore zum unbefristeten Speichern und Abrufen des Chat-Nachrichtenverlaufs implementiert.

  • Für diesen produktionsbereiten Dienst sind zusätzliche Elemente erforderlich. Für die Bereitstellung von Hochverfügbarkeit mit Replikation und automatischem Failover wird eine Redis-Instanz der Standardstufe empfohlen.

Ziele

  • Schreiben, Erstellen und Bereitstellen eines Cloud Run-Dienstes, der WebSockets verwendet.

  • Stellen Sie eine Verbindung zu einer Memorystore for Redis-Instanz her, um neue Nachrichten auf Containerinstanzen zu veröffentlichen und zu abonnieren.

  • Verbinden Sie den Cloud Run-Dienst mit Memorystore über Connectors für den serverlosen VPC-Zugriff.

Kosten

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

Sie können mithilfe des Preisrechners eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.

Sie sollten dieses Projekt mithilfe des Guthabens der kostenlosen Testversion durchführen können.

Neuen Cloud Platform-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Vorbereitung

  1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
  2. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  3. Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

  4. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  5. Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

  6. Cloud Run, Memorystore for Redis, Serverless VPC Access, Artifact Registry, and Cloud Build APIs aktivieren.

    Aktivieren Sie die APIs

  7. Installieren und initialisieren Sie das Cloud SDK.

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.

Cloud Run-Standorte

Cloud Run ist regional. Die Infrastruktur, in der die Cloud Run-Dienste ausgeführt werden, befindet sich demnach in einer bestimmten Region. Aufgrund der Verwaltung durch Google sind die Anwendungen in allen Zonen innerhalb dieser Region redundant verfügbar.

Bei der Auswahl der Region, in der Ihre Cloud Run-Dienste ausgeführt werden, ist vorrangig, dass die Anforderungen hinsichtlich Latenz, Verfügbarkeit oder Langlebigkeit erfüllt werden. Sie können im Allgemeinen die Region auswählen, die Ihren Nutzern am nächsten liegt, aber Sie sollten den Standort der anderen Google Cloud-Produkte berücksichtigen, die von Ihrem Cloud Run-Dienst verwendet werden. Die gemeinsame Nutzung von Google Cloud-Produkten an mehreren Standorten kann sich auf die Latenz und die Kosten des Dienstes auswirken.

Cloud Run ist in diesen Regionen verfügbar:

Unterliegt Preisstufe 1

Unterliegt Preisstufe 2

  • asia-east2 (Hongkong)
  • asia-northeast3 (Seoul, Südkorea)
  • asia-southeast1 (Singapur)
  • asia-southeast2 (Jakarta)
  • asia-south1 (Mumbai, Indien)
  • asia-south2 (Delhi, Indien)
  • australia-southeast1 (Sydney)
  • australia-southeast2 (Melbourne)
  • europe-central2 (Warschau, Polen)
  • europe-west2 (London, Vereinigtes Königreich)
  • europe-west3 (Frankfurt, Deutschland)
  • europe-west6 (Zürich, Schweiz) Blattsymbol Niedriger CO2-Wert
  • northamerica-northeast1 (Montreal) Blattsymbol Niedriger CO2-Wert
  • northamerica-northeast2 (Toronto)
  • southamerica-east1 (Sao Paulo, Brasilien) Blattsymbol Niedriger CO2-Wert
  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Wenn Sie bereits einen Cloud Run-Dienst erstellt haben, können Sie die Region in der Cloud Console im Cloud Run-Dashboard aufrufen.

Codebeispiel abrufen

So rufen Sie das gewünschte Codebeispiel ab:

  1. Klonen Sie das Beispiel-Repository 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.

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

    Node.js

    cd nodejs-docs-samples/run/websockets/

Code verstehen

Socket.io ist eine Bibliothek, die eine bidirektionale Echtzeitkommunikation zwischen Browser und Server ermöglicht. Obwohl Socket.io keine WebSocket-Implementierung ist, umfasst es die Funktion, eine einfachere API für mehrere Kommunikationsprotokolle mit zusätzlichen Features, wie verbesserter Zuverlässigkeit, automatischer Neuverbindung sowie Broadcasting an einen oder alle Clients, bereitzustellen.

Clientseitige Integration

<script src="/socket.io/socket.io.js"></script>

Der Client instanziiert eine neue Socket-Instanz für jede Verbindung. Da dieses Beispiel serverseitig gerendert wird, muss die Server-URL nicht definiert werden. Die Socket-Instanz kann Ereignisse ausgeben und abhören.

// Initialize Socket.io
const socket = io('', {
  transports: ['websocket'],
});
// Emit "sendMessage" event with message
socket.emit('sendMessage', msg, error => {
  if (error) {
    console.error(error);
  } else {
    // Clear message
    $('#msg').val('');
  }
});
// Listen for new messages
socket.on('message', msg => {
  log(msg.user, msg.text);
});

// Listen for notifications
socket.on('notification', msg => {
  log(msg.title, msg.description);
});

// Listen connect event
socket.on('connect', () => {
  console.log('connected');
});

Serverseitige Integration

Auf der Serverseite wird der Socket.io-Server initialisiert und mit dem HTTP-Server verbunden. Ähnlich wie auf der Clientseite wird nach dem Herstellen einer Verbindung zum Client mit Socket.io eine Socket-Instanz für jede Verbindung erstellt, mit Nachrichten ausgegeben und überwacht werden können. Socket.io bietet auch eine einfache Schnittstelle zum Erstellen von "Chatrooms" oder einem beliebigen Kanal, dem Sockets beitreten und ihn verlassen können.

// Initialize Socket.io
const server = require('http').Server(app);
const io = require('socket.io')(server);

const redisAdapter = require('@socket.io/redis-adapter');
// Replace in-memory adapter with Redis
io.adapter(redisAdapter(redisClient, redisClient.duplicate()));

// Listen for new connection
io.on('connection', socket => {
  // Add listener for "signin" event
  socket.on('signin', async ({user, room}, callback) => {
    try {
      // Record socket ID to user's name and chat room
      addUser(socket.id, user, room);
      // Call join to subscribe the socket to a given channel
      socket.join(room);
      // Emit notification event
      socket.in(room).emit('notification', {
        title: "Someone's here",
        description: `${user} just entered the room`,
      });
      // Retrieve room's message history or return null
      const messages = await getRoomFromCache(room);
      // Use the callback to respond with the room's message history
      // Callbacks are more commonly used for event listeners than promises
      callback(null, messages);
    } catch (err) {
      callback(err, null);
    }
  });

  // Add listener for "updateSocketId" event
  socket.on('updateSocketId', async ({user, room}) => {
    try {
      addUser(socket.id, user, room);
      socket.join(room);
    } catch (err) {
      console.error(err);
    }
  });

  // Add listener for "sendMessage" event
  socket.on('sendMessage', (message, callback) => {
    // Retrieve user's name and chat room  from socket ID
    const {user, room} = getUser(socket.id);
    if (room) {
      const msg = {user, text: message};
      // Push message to clients in chat room
      io.in(room).emit('message', msg);
      addMessageToCache(room, msg);
      callback();
    } else {
      callback('User session not found.');
    }
  });

  // Add listener for disconnection
  socket.on('disconnect', () => {
    // Remove socket ID from list
    const {user, room} = deleteUser(socket.id);
    if (user) {
      io.in(room).emit('notification', {
        title: 'Someone just left',
        description: `${user} just left the room`,
      });
    }
  });
});

Socket.io stellt auch einen Redis-Adapter bereit, um Ereignisse an alle Clients zu senden, unabhängig davon, welcher Server den Socket bereitstellt. Socket.io verwendet ausschließlich den Pub/Sub-Mechanismus von Redis und speichert keine Daten.

const redisAdapter = require('@socket.io/redis-adapter');
// Replace in-memory adapter with Redis
io.adapter(redisAdapter(redisClient, redisClient.duplicate()));

Der Redis-Adapter von Socket.io kann den Redis-Client wiederverwenden, der zum Speichern des Nachrichtenverlaufs des Chatrooms verwendet wird. Jeder Container erstellt eine Verbindung zur Redis-Instanz und Cloud Run hat maximal 1.000 Instanzen. Das sind deutlich weniger als die 65.000 Verbindungen, die Redis unterstützen kann. Wenn Sie diese Menge an Traffic unterstützen müssen, müssen Sie auch den Durchsatz des Connectors für den serverlosen VPC-Zugriff auswerten.

Verbindung wiederherstellen

Cloud Run hat eine maximale Zeitüberschreitung von 60 Minuten. Daher müssen Sie eine erneute Verbindungslogik für mögliche Zeitlimits hinzufügen. In einigen Fällen versucht Socket.io automatisch, die Verbindung nach einem Verbindungs- oder Verbindungsfehler wiederherzustellen. Es gibt keine Garantie dafür, dass der Client wieder eine Verbindung zur selben Containerinstanz herstellt.

// Listen for reconnect event
socket.io.on('reconnect', () => {
  console.log('reconnected');
  // Emit "updateSocketId" event to update the recorded socket ID with user and room
  socket.emit('updateSocketId', {user, room}, error => {
    if (error) {
      console.error(error);
    }
  });
});
// Add listener for "updateSocketId" event
socket.on('updateSocketId', async ({user, room}) => {
  try {
    addUser(socket.id, user, room);
    socket.join(room);
  } catch (err) {
    console.error(err);
  }
});

Containerinstanzen bleiben bei einer aktiven Verbindung bestehen, bis alle Anfragen geschlossen oder das Zeitlimit überschritten werden. Da es keine Sitzungsaffinität gibt, erfolgt das Load-Balancing neuer Anfragen auf aktive Container, sodass Container horizontal skaliert werden können. Wenn Sie befürchten, dass eine große Anzahl von Containern nach einer Traffic-Spitze bestehen bleibt, können Sie den maximalen Zeitüberschreitungswert verringern, damit nicht verwendete Sockets häufiger bereinigt werden.

Dienst versenden

  1. Erstellen einer Instanz von Memorystore for Redis:

    gcloud redis instances create INSTANCE_ID --size=1 --region=REGION

    Ersetzen Sie INSTANCE_ID durch den Namen der Instanz, z. B. my-redis-instance, und REGION_ID durch die Region für alle Ihre Ressourcen und Dienste, z. B. us-central1.

    Der Instanz wird automatisch ein IP-Bereich aus dem Standarddienstnetzwerkbereich zugewiesen. In dieser Anleitung wird für den lokalen Cache von Nachrichten in der Redis-Instanz 1 GB Arbeitsspeicher verwendet. Weitere Informationen zum Bestimmen der anfänglichen Größe einer Memorystore-Instanz für Ihren Anwendungsfall.

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

    Zum Herstellen einer Verbindung zu Ihrer Redis-Instanz benötigt Ihr Cloud Run-Dienst Zugriff auf das autorisierte VPC-Netzwerk der Redis-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 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 einen Connector im Standard-VPC-Netzwerk, genauso wie die Redis-Instanz, mit der Maschinengröße e2-micro. 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 die Redis-Instanz befinden. Serverlosen VPC-Zugriff konfigurieren

  3. Definieren Sie eine Umgebungsvariable mit der IP-Adresse des autorisierten Netzwerks der Redis-Instanz:

     export REDISHOST=$(gcloud redis instances describe INSTANCE_ID --region REGION --format "value(host)")
  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 chat-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 beta run deploy chat-app --source . \
        --vpc-connector CONNECTOR_NAME \
        --allow-unauthenticated \
        --timeout 3600 \
        --service-account chat-identity \
        --update-env-vars REDISHOST=$REDISHOST

    Beantworten Sie die Aufforderungen, die erforderlichen APIs zu installieren, indem Sie nach Aufforderung y antworten. Dies ist nur einmal für ein Projekt erforderlich. Antworten Sie auf andere Aufforderungen, indem Sie die Plattform und Region angeben, sofern Sie diese nicht wie auf der Einrichtungsseite beschrieben eingerichtet haben. Weitere Informationen zum Aus Quellcode bereitstellen.

Testen

So testen Sie den gesamten Dienst:

  1. Rufen Sie im Browser die URL auf, die Sie im oben beschriebenen Bereitstellungsschritt erhalten haben.

  2. Geben Sie Ihren Namen und einen Chatroom ein, um sich anzumelden.

  3. Nachricht an den Chatroom senden.

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 Chatdienst, der in Iowa (us-central1) gehostet wird, mit einer Redis-Instanz mit 5 GB und einem Connector für serverlosen VPC-Zugriff.

Produkt Kosten pro Monat
Redis Kosten = Bereitgestellte Kapazität (5 GB) * Preis für die regionale Stufe (us-central1)

Standardstufe: 5 GB * 0,054 GB/Std. * 730 Std./Monat = 197 $
Basis-Stufe: 5 GB 0,027 GB/Std. * 730 Std./Monat = 99 $
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 = Ressourcennutzungszeit des Cloud Run-Dienstes price Preis * Anzahl der Instanzen

Arbeitsspeicher: 0,5 GiB $ 0,00000250 $ / GiB-s 60 s/min 60 Min./Std. 8 Stunden * 30,5 Tage * 4 Instanzen = 4,39 $†
CPU: 1 vCPU * 0,00002400 $ / vCPU-s * 60 s/Min. * 60 Minuten/Stunde * 8 Stunden * 30,5 Tage * 4 Instanzen = 84,33 $†
Anfragen: 0,40 $ / Million ~= 0
Netzwerk: 0,085 $/GB/Monat ~= 0 $
Summe 197 $ + 12.22 $ + 89 $ ~= 298 $ pro Monat

† Weitere Informationen zum Szenariokontext finden Sie weiter unten.

In dieser Anleitung wird eine eigenständige Redis-Instanz der Basis-Stufe verwendet. Für eine hohe Verfügbarkeit mit automatisch aktivierter zonenübergreifender Replikation und automatischem Failover kann die Dienststufe auf Standard aktualisiert werden. Region und Kapazität wirken sich auch auf die Redis-Preise aus. Eine 5-GB-Instanz der Standard-Stufe in Iowa (us-central1) kostet beispielsweise 0,054 $ pro GB und Stunde. Die Kosten pro Stunde betragen also 5 * 0,054 $, was ungefähr 0,27 $ pro Stunde bzw. 197 $ pro Monat entspricht. Legen Sie die Anfangsgröße einer Memorystore-Instanz fest und informieren Sie sich über die Redis-Preise.

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 die doppelt so hoch wie die Maschinengröße.

Der Preis für Cloud Run wird nach Ressourcennutzung auf die nächste Zehntelsekunde gerundet, wobei Speicher, CPU, Anzahl der Anfragen und Netzwerke berücksichtigt werden. In dieser Anleitung werden die standardmäßigen Cloud Run-Einstellungen von 512 MiB und 1 vCPU verwendet, die 0,5 GiB * 0,00000250 $/GiB/Sekunde und 1 vCPU * 0,00002400 $/vCPU-Sekunde oder insgesamt 0,091 $pro Stunde und Instanz kosten. Nebenläufigkeit hat einen großen Einfluss auf die Gesamtkosten, obwohl die Limits und Empfehlungen je nach Sprache variieren. Wenn Sie die Gleichzeitigkeit erhöhen, sinkt die Anzahl der benötigten Containerinstanzen. Cloud Run kann maximal 250 Anfragen gleichzeitig ausführen. Maximal 1.000 Containerinstanzen mit 250 gleichzeitigen Anfragen können bis zu 250.000 Clients bereitstellen. Beispiel: Ein Dienst für 1.000 Mitarbeiter, der 250 Gleichzeitigkeiten bereitstellt, benötigt mindestens 4 Instanzen. 4 Instanzen für 1 Monat von 8 Stunden-Tagen kosten 0,091 $ 4 Instanzen * 8 Stunden 30,5 Tage = 89 $. Die Anzahl der Anfragen und das Netzwerk sind zusätzliche Kosten, aber wahrscheinlich nur minimal.

Dieser in Iowa gehostete Chatdienst (us-central1) würde 197 $für eine Redis-Instanz mit 5 GB Standardkosten, 12,22 $ für einen Standard-Connector für serverlosen VPC-Zugriff, 89 $für den Cloud Run-Dienst, insgesamt 298 $pro Monat, kosten. Kostenvoranschlag im Google Cloud-Preisrechner 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. Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

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