Das ist Cloud Run: Konfiguration für Windows 7,8,10,11-Winpcsoft.com

Das ist Teil 3 aus der „This is Cloud Run“-Reihe. In Teil 1, Wir haben erläutert, was Cloud Run ist und wann man es wählen sollte. In Teil 2, Wir gingen die Bereitstellungsoptionen und das Revisionsmanagement durch. Jetzt lasst es uns optimieren.

Die Standardeinstellungen von Cloud Run sind gut. Wir haben das im Teil behandelt 1. Aber jede Arbeitsbelastung hat ihre eigenen Anforderungen, und Cloud Run gibt Ihnen die Knöpfe, um sie darauf einzustellen. In diesem Artikel werden die Einstellungen behandelt, die Sie am häufigsten aufrufen.

CPU und Speicher

Jede Cloud Run-Instanz erhält einen Anteil an CPU und Arbeitsspeicher. Die Standardeinstellungen (1 vCPU, 512 MiB) sind für eine leichtgewichtige API sinnvoll, Sie sollten sie jedoch anpassen, wenn Sie die Anforderungen Ihrer Arbeitslast verstehen.

CPU reicht von 0.08 vCPU (weniger als ein Zehntel eines Kerns) Zu 8 vCPUs. Erinnerung reicht von 128 MiB zu 32 GiB. Die beiden sind miteinander verbunden: Höhere CPU-Zuweisungen erfordern Mindestspeicherschwellenwerte, und einige Speicherkonfigurationen erfordern eine minimale CPU.

Aber die wichtigere Entscheidung ist die CPU-Zuweisungsmodus:

Nur auf Anfrage (Standard). CPU wird nur zugewiesen, während Ihre Instanz aktiv eine Anfrage verarbeitet. Zwischen Anfragen, Die CPU wird auf nahezu Null gedrosselt. Sie zahlen nur für die Zeit, die Sie mit der Bearbeitung von Anfragen verbringen. Dies ist das serverlose Modell, und es ist die richtige Wahl für die meisten HTTP-APIs.
Immer an. CPU ist immer verfügbar, auch zwischen Anfragen. Das kostet mehr, Es ist jedoch für Workloads erforderlich, die außerhalb der Anforderungsbearbeitung funktionieren: WebSocket-Verbindungen, die den Status beibehalten, Hintergrundthreads, die Warteschlangen verarbeiten, oder Dienste, die In-Memory-Caches warm halten müssen.

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --CPU 2 \
  --Speicher 1Gi \
  --Keine CPU-Drosselung \
  --Region US-Zentral1

Der –Das No-CPU-Throttling-Flag ermöglicht eine Always-On-CPU. Ohne es (oder mit –CPU-Drosselung), Sie erhalten den standardmäßigen Nur-Anfrage-Modus.

Der Preisunterschied ist erheblich. Mit Nur-Anfrage-Zuteilung, Sie zahlen nur pro vCPU-Sekunde und GiB-Sekunde für die Bearbeitung von Anfragen. Mit Always-On, Sie zahlen für den gesamten Lebenszyklus der Instanz. Für einen Dienst, der stoßartigen HTTP-Verkehr mit Leerlaufzeiten dazwischen verarbeitet, Nur auf Anfrage kann erheblich günstiger sein. Für einen Dienst, der Hintergrundaufgaben ausführt oder WebSocket-Verbindungen verwaltet, Always-On ist die einzige Option, die ordnungsgemäß funktioniert.

Gesundheitschecks

Cloud Run sendet keinen Datenverkehr an eine Instanz, bis diese bereit ist. Standardmäßig, es verwendet a TCP-Startprobe: Es wartet darauf, dass Ihr Container den erwarteten Port überwacht, hält es dann für fertig.

Für die meisten Dienste, das reicht. Wenn Ihre Anwendung jedoch Zeit zum Laden von Daten benötigt, warme Caches, oder Datenbankverbindungen herstellen, nachdem der Port geöffnet ist, Sie möchten eine Sonderanfertigung HTTP-Startprobe:

StartupProbe:
  httpGet:
    Weg: /Gesundheit
    Hafen: 8080
  initialDelaySeconds: 0
  periodSekunden: 2
  Fehlerschwelle: 15

Dadurch wird Cloud Run angewiesen, jeden Tag /healthz abzurufen 2 Sekunden. Wenn es fehlschlägt 15 mal, Die Instanz wird als fehlerhaft markiert und neu gestartet. Erst wenn die Prüfung erfolgreich ist, empfängt die Instanz Datenverkehr. Dies verhindert das 502 errors that happen when a load balancer sends requests to an instance that's technically listening but not yet ready to serve.

Cloud Run unterstützt auch Lebendigkeitssonden die nach dem Start kontinuierlich laufen. Wenn eine Liveness-Prüfung fehlschlägt, Cloud Run startet die Instanz neu. Nützlich zum Erkennen festsitzender Prozesse, Deadlocks, oder Speicherlecks, die den Container nicht zum Absturz bringen, ihn aber nicht mehr reagieren lassen.

Für gRPC Dienstleistungen, Cloud Run unterstützt gRPC-Integritätsprüfungstests gemäß gRPC-Zustandsprüfungsprotokoll.

Zeitüberschreitung anfordern

Jede Cloud Run-Anfrage hat eine Time-out. Die Standardeinstellung ist 300 Sekunden (5 Minuten). Das Maximum ist 3600 Sekunden (60 Minuten).

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --Time-out 600 \
  --Region US-Zentral1

Wenn Ihr Dienst große Datei-Uploads verarbeitet, generiert Berichte, oder führt langwierige Berechnungen durch, Sie möchten dies erhöhen. Aber denken Sie daran: Das Timeout gilt pro Anfrage. Wenn eine einzelne Anfrage länger als das Timeout dauert, Cloud Run beendet es. Auch WebSocket-Verbindungen unterliegen diesem Timeout, weshalb Teil 1 erwähnte das Verbindungslimit von ca. 60 Minuten.

Ein gängiges Muster für Langzeitarbeiten: Akzeptieren Sie die Anfrage, Starten Sie die Verarbeitung asynchron (über Cloud-Aufgaben oder Pub/Sub), und gib a zurück 202 sofort. Der Client fragt den Status ab oder erhält einen Rückruf, wenn die Arbeit erledigt ist. Dadurch bleibt die Zeitüberschreitung Ihrer Anfrage kurz und Ihr Dienst reagiert reaktionsfähig.

Wenn Sie feststellen, dass Sie regelmäßig das 60-Minuten-Maximum erreichen, Das ist ein Signal dafür, dass Ihr Arbeitspensum möglicherweise besser geeignet ist Cloud Run-Jobs (für die Stapelverarbeitung) oder eine ganz andere Plattform.

Skalierung: Instanzen und Parallelität

Der Autoscaler von Cloud Run verwaltet drei verwandte Einstellungen:

Mindestinstanzen steuert, wie viele Instanzen warm bleiben, wenn kein Datenverkehr stattfindet. Die Standardeinstellung ist 0 (Skalierung auf Null). Stellen Sie es ein 1 or higher eliminates cold starts but means you're paying for idle instances. It's the classic serverless trade-off: Latenz vs. kosten. Für latenzempfindliche Produktionsdienste, 1 ist oft die richtige Zahl. Für Entwicklungsumgebungen, 0 hält Ihre Rechnung auf Null.

Maximale Instanzen begrenzt, wie weit Cloud Run skaliert werden kann. Die Standardeinstellung ist 100. Dies schützt Sie vor unkontrollierbarer Skalierung (und eine überraschende Rechnung) bei unerwarteten Verkehrsspitzen. Aber stellen Sie dies mit Bedacht ein: wenn Ihr Dienst mit einer Datenbank mit einem Pool mit 20 Verbindungen kommuniziert, 100 Instanzen, die alle versuchen, eine Verbindung herzustellen, werden es überfordern. Match your max instances to your backend's capacity.

Parallelität steuert, wie viele Anfragen eine einzelne Instanz gleichzeitig bearbeitet. Die Standardeinstellung ist 80. This is one of Cloud Run's key advantages over the old Cloud Functions 1st gen model, die jeweils eine Anfrage pro Instanz verarbeitete. Mit Parallelität bei 80, eine einzelne Instanz kann dienen 80 gleichzeitige Anfragen, bevor Cloud Run eine weitere Instanz startet.

Verringern Sie die Parallelität für CPU-intensive Arbeitslasten, bei denen jede Anfrage eine dedizierte Verarbeitungsleistung benötigt. Erhöhe es (bis zu 1000) für leichtgewichtige I/O-gebundene Handler, die die meiste Zeit damit verbringen, auf Netzwerkanrufe zu warten. Parallelität festlegen auf 1 mimics the one-request-per-instance model if your code isn't thread-safe.

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --Min-Instanzen 1 \
  --max-instanzen 10 \
  --Parallelität 80 \
  --Region US-Zentral1

Und denken Sie daran CPU-Boost beim Start ab Teil 1: Cloud Run verdoppelt vorübergehend die CPU während der Instanzinitialisierung, um Instanzen schneller einsatzbereit zu machen. Kombiniert mit Mindestinstanzen, Dadurch sind Kaltstarts für die meisten Workloads kein Problem.

Umgebungsvariablen und Geheimnisse

Cloud Run unterstützt zwei Mechanismen zum Übergeben der Konfiguration an Ihre Container, und es ist wichtig, das richtige für den Job zu verwenden.

Umgebungsvariablen sind für eine nicht sensible Konfiguration vorgesehen: Feature-Flags, API-Endpunkte, Protokollierungsstufen, Datenbank-Hostnamen. Legen Sie sie zum Zeitpunkt der Bereitstellung mit fest –set-env-vars:

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --set-env-vars "DB_HOST=10.0.0.1,LOG_LEVEL=info,ENV=Produktion" \
  --Region US-Zentral1

Dies folgt dem 12-Faktor-App Methodik: Die Konfiguration lebt in der Umgebung, nicht im Code.

Geheimnisse sind für sensible Anmeldeinformationen: API-Schlüssel, Datenbank-Passwörter, TLS-Zertifikate, Geheimnisse des OAuth-Clients. Diese sollten niemals Seien Sie einfache Umgebungsvariablen. Einfache Umgebungsvariablen sind in der Cloud Run-Konsole sichtbar, werden in Debug-Protokollen angezeigt, und können in Fehlerberichte eindringen. Stattdessen, Bewahren Sie sie auf Geheimmanager und referenzieren Sie sie zum Zeitpunkt der Bereitstellung:

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --set-secrets "API_KEY=my-api-key:letzte" \
  --set-secrets "/secrets/tls.key=tls-private-key:letzte" \
  --Region US-Zentral1

Geheimnisse können als Umgebungsvariablen oder als Dateien bereitgestellt werden. Im ersten Beispiel oben wird das Geheimnis als Umgebungsvariable mit dem Namen API_KEY bereitgestellt. Der zweite mountet es als Datei unter /secrets/tls.key. Geheimnisse sind versioniert, Zugriffsgesteuert über IAM, und auditprotokolliert. Wenn ein Geheimnis kompromittiert wird, Sie rotieren es im Secret Manager und stellen es erneut bereit. Keine Codeänderungen.

Volumenhalterungen

Cloud Run-Instanzen sind kurzlebig, Aber manchmal benötigen Sie temporären Speicher oder Zugriff auf freigegebene Dateien. Cloud Run unterstützt drei Arten von Volume-Mounts:

In-Memory-Volumes are tmpfs-style mounts backed by your instance's RAM. They're fast but volatile (verschwunden, wenn die Instanz beendet wird) und zählen auf Ihr Speicherlimit. Nützlich für die temporäre Dateiverarbeitung, als würde man eine Datei herunterladen, es umwandeln, und Hochladen des Ergebnisses:

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --Name des Add-Volumes = Scratch,Typ = im Speicher,Größenbeschränkung=256Mi \
  --add-volume-mount volume=scratch,mount-path=/tmp/work \
  --Region US-Zentral1

Cloud-Speichersicherung Reittiere a Cloud-Speicher Bucket als lokales Dateisystem. Ihr Code liest und schreibt Dateien normal, Und GCS-SICHERUNG übersetzt diese Vorgänge in Cloud Storage API-Aufrufe:

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --Name des Add-Volumes = Modelle,Typ = Cloud-Speicher,Bucket=meine-ml-Modelle \
  --add-volume-mount volume=models,mount-path=/mnt/models \
  --Region US-Zentral1

Der Haken: es ist letztendlich konsistent. Keine Dateisperre, Der letzte Schreibvorgang gewinnt. Gut zum Lesen geteilter Assets (ML-Modelle, Konfigurationsdateien) oder Artefakte schreiben (Protokolle, Exporte). Nicht geeignet für gleichzeitige Schreibvorgänge in derselben Datei.

NFS über Filestore gibt Ihnen ein voll POSIX-kompatibles Netzwerkdateisystem mit ordnungsgemäßer Dateisperrung. Geringere Latenz als GCS FUSE für zufällige Lesevorgänge. Erfordert VPC-Konnektivität seit Dateispeicher Instanzen leben auf Ihrer VPC. Am besten für Workloads geeignet, die gemeinsamen Lese-/Schreibzugriff mit Konsistenz auf Dateiebene benötigen.

Für die meisten Cloud Run-Dienste, Sie werden nichts davon brauchen. Aber wenn du es tust (Bildverarbeitungspipelines, ML-Modellbereitstellung, Gemeinsame Konfiguration über Instanzen hinweg), Sie ersparen Ihnen die Erstellung von Workarounds.

Netzwerkkonfiguration

Die Netzwerkstandards von Cloud Run sind einfach: Ihr Dienst ist öffentlich, und es stellt eine Verbindung zum Internet für ausgehenden Datenverkehr her. Aber wenn Sie mehr Kontrolle brauchen, Es gibt drei Bereiche zur Konfiguration.

Eindringen

Ingress-Einstellungen Kontrollieren Sie, wer Ihren Dienst erreichen kann:

Alle (Standard). Akzeptiert Datenverkehr von überall im Internet. Gut für öffentliche APIs und Web-Apps.
Intern. Akzeptiert nur Datenverkehr aus Ihrem Inneren VPC oder von anderen Google Cloud-Diensten (wie Pub/Sub, Cloud-Planer, oder Cloud-Aufgaben). Der Dienst ist für das öffentliche Internet unsichtbar. Verwenden Sie dies für Backend-Dienste, die niemals direkt von externen Clients aufgerufen werden sollten.
Intern + Cloud-Lastausgleich. Dasselbe wie intern, akzeptiert aber auch Verkehr über a globaler externer Application Load Balancer. Dies ist der Pfad zu benutzerdefinierten Domänen, CDN-Caching mit Cloud-CDN, und WAF-Schutz mit Wolkenrüstung. Dieses Load-Balancer-Muster wird in den Abschnitten „Benutzerdefinierte Domänen“ und „Cloud Armor“ unten erneut angezeigt.

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --Eingang intern \
  --Region US-Zentral1

Egress und VPC-Konnektivität

Standardmäßig, Ihre Cloud Run-Instanzen stellen eine direkte Verbindung zum Internet her. Aber wenn Ihr Dienst private Ressourcen erreichen muss (A Cloud SQL Datenbank, A Speicherspeicher Redis-Instanz, eine interne API), es benötigt VPC-Zugriff.

Zwei Möglichkeiten:

Serverlose VPC-Zugriffsanschlüsse. Der ursprüngliche Ansatz. Sie erstellen eine Connector-Ressource, die Cloud Run und Ihre VPC verbindet. Funktioniert, fügt aber einen Netzwerk-Hop hinzu und hat Durchsatzbeschränkungen.
Direkter VPC-Ausgang. Der neuere Ansatz. Cloud Run-Instanzen werden direkt in Ihrem VPC-Subnetz platziert. Kein Stecker erforderlich, kein zusätzlicher Hopfen, kein Durchsatzengpass. Dies ist der empfohlene Pfad für neue Bereitstellungen.

Wenn Sie neu anfangen, Entscheiden Sie sich für direkten VPC-Ausgang. Wenn Sie über vorhandene Dienste verfügen, die Connectors verwenden, Sie werden weiterarbeiten, Aber erwägen Sie eine Migration, wenn es Ihnen passt.

Benutzerdefinierte Domänen

Jeder Cloud Run-Dienst erhält eine *.run.app-URL mit automatischem HTTPS. Aber für die Produktion, you'll want your own domain. Zwei Wege:

Cloud Run-Domänenzuordnung. Die einfachere Variante. Ordnen Sie eine Domäne direkt Ihrem Cloud Run-Dienst zu. SSL-Zertifikate werden automatisch bereitgestellt und erneuert. Funktioniert für einfache Setups, bei denen lediglich api.example.com auf Ihren Dienst verweisen muss.
Globaler externer Application Load Balancer. Die leistungsfähigere Option. Bietet Ihnen CDN-Caching, Cloud Armor WAF, Mehrregionales Routing, und URL-basiertes Routing zu verschiedenen Diensten. Mehr Setup, Aber es erschließt Funktionen, die die Domänenzuordnung allein nicht bieten kann.

Sicherheitskonfiguration

Die Sicherheitsstandards von Cloud Run sind streng (behandelt in Teil 1). Aber für Produktionsdienstleistungen, Sie möchten einige Einstellungen anpassen.

Dienstkonten

Jeder Cloud Run-Dienst wird als ausgeführt Dienstkonto, Dadurch wird bestimmt, auf welche Google Cloud-Ressourcen es zugreifen kann. Standardmäßig, Cloud Run verwendet das Standard-Rechendienstkonto des Projekts, die normalerweise über weitreichende Berechtigungen verfügt.

Für die Produktion, Erstellen Sie eine dediziertes Dienstkonto pro Dienst mit nur den Berechtigungen, die es benötigt. Wenn Ihr Dienst aus Cloud Storage liest und in Pub/Sub schreibt, Sein Dienstkonto sollte über storage.objectViewer und pubsub.publisher verfügen. Mehr nicht. Dies ist das Prinzip des geringsten Privilegs, und es begrenzt den Explosionsradius, wenn ein Dienst beeinträchtigt wird.

gcloud ausführen und „my-service bereitstellen“ ausführen \
  --Bild mein Bild \
  --service-account [email protected] \
  --Region US-Zentral1

IAM-Authentifizierung

Standardmäßig, Cloud Run erfordert eine Authentifizierung. Jede Anfrage muss ein gültiges Identitätstoken enthalten, und der Aufrufer muss die Rolle „roles/run.invoker“ für den Dienst haben. Dies ist die richtige Standardeinstellung für die Service-zu-Service-Kommunikation.

Für öffentlich zugängliche Dienste (APIs, Webhooks, Web-Apps), Sie deaktivieren dies ausdrücklich, indem Sie allUsers die Rolle „roles/run.invoker“ zuweisen:

gcloud run services add-iam-policy-binding my-service \
  --member="allUsers" \
  --role="roles/run.invoker" \
  --Region US-Zentral1

Aber auch bei aktiviertem nicht authentifiziertem Zugriff, Sie können Ihre eigene Authentifizierungsschicht in Ihrem Anwendungscode implementieren. Cloud Run übernimmt die Transportsicherheit (HTTPS) und Identität auf Plattformebene (die IAM-Aufruferprüfung). Ihre App verwaltet die Identität auf Anwendungsebene: Benutzeranmeldungen, API-Schlüssel, JWT-Validierung.

Binärautorisierung

Binärautorisierung erzwingt Richtlinien zur Bereitstellungszeit: Es können nur Container-Images bereitgestellt werden, die von Ihrer CI/CD-Pipeline signiert wurden. Dadurch wird verhindert, dass jemand ein ungetestetes Image direkt in der Produktion bereitstellt, selbst wenn sie über die IAM-Berechtigungen dafür verfügen.

Es handelt sich um eine Governance-Ebene, die für Organisationen mit Compliance-Anforderungen oder strengen Änderungsmanagementprozessen sinnvoll ist.

Wolkenrüstung

Wolkenrüstung ist die WAF von Google Cloud (Webanwendungs-Firewall). Es befindet sich vor Ihrem Cloud Run-Dienst und kann Durchsetzungsmaßnahmen ergreifen:

IP-Zulassungs- und Sperrlisten
Geografische Einschränkungen
Ratenbegrenzung pro Kunde
Vorkonfigurierte WAF-Regeln (SQL-Injection, XSS, usw.)

Cloud Armor erfordert eine globaler externer Application Load Balancer vor Ihrem Cloud Run-Dienst. Wenn Sie die Standard-URL *.run.app ohne Load Balancer verwenden, Cloud Armor isn't available. Aber wenn Ihr Dienst öffentlich zugänglich ist und vertrauliche Daten verarbeitet, Der Load Balancer + Die Kombination aus Cloud Armor ist die zusätzliche Einrichtung wert.

Abschluss

Cloud Run bietet Ihnen genügend Konfigurationsknöpfe, um sich an echte Arbeitslasten anzupassen. Aber Sie müssen nicht alle auf einmal berühren.

Das Muster, das ich empfehle: Beginnen Sie mit den Standardeinstellungen. Stellen Sie Ihren Dienst bereit, Sehen Sie, wie es sich im realen Verkehr verhält, dann anpassen. Erweitern Sie den Speicher, wenn Sie an Ihre Grenzen stoßen. Verringern Sie die Parallelität, wenn Anfragen CPU-lastig sind. Fügen Sie eine Gesundheitsprüfung hinzu, wenn Ihr Start langsam ist. Richten Sie ein dediziertes Dienstkonto ein, bevor Sie mit der Produktion beginnen. Jede Änderung wird bei der nächsten Bereitstellung wirksam, ohne Ausfallzeiten. Nichts ist dauerhaft.

Wenn Teil 1 ging es um ob Cloud Run gehört in Ihre Architektur, und Teil 2 ging es um Holen Sie sich Ihren Code darauf, In diesem Artikel geht es darum Damit es gut auf Ihre spezifischen Bedürfnisse zugeschnitten ist. Fangen Sie einfach an. Erhöhen Sie die Komplexität, wenn Ihre Arbeitsbelastung dies erfordert, nicht vorher.

Wenn Sie gerade erst in die Serie einsteigen, Teil 1 ist der Ausgangspunkt.

Ressourcen

Das ist Cloud Run: Die Konfiguration wurde ursprünglich in Google Developer Experts auf Medium veröffentlicht, wo die Leute das Gespräch fortsetzen, indem sie diese Geschichte hervorheben und darauf reagieren.