Nachdem Sie einen Dienst oder eine Funktion erstellt haben, stellt Cloud Run einen HTTPS-Endpunkt für den Dienst bereit. Sie können den Dienst so konfigurieren, dass er als Reaktion auf HTTPS-Anfragen ausgeführt wird.
Alle Cloud Run-Dienste haben eine stabile HTTPS-URL, die den standardmäßigen HTTPS-Endpunkt für den Dienst darstellt. Sie können aber auch benutzerdefinierte Domains konfigurieren.
Hier einige Beispiele für Anwendungsfälle:
- Benutzerdefinierte RESTful-Web-API
- Privater Mikrodienst
- HTTP-Middleware oder Reverse-Proxy für Ihre Webanwendungen
- Vorgepackte Webanwendung
Öffentliche Dienste erstellen
Für das Erstellen eines öffentlichen Dienstes in Cloud Run ist Folgendes erforderlich:
- Zugriff auf den Dienst über das öffentliche Internet
- Eine URL zur öffentlichen Verwendung
Wenn Sie einen Dienst öffentlich machen möchten, legen Sie fest, dass der Dienst nicht authentifiziert (öffentlich) sein soll.
Service-URL
Cloud Run weist allen Diensten eine hashbasierte nicht deterministische URL zu. Wenn die Länge des Dienstnamens dies zulässt, weist Cloud Run dem Dienst auch eine deterministische URL zu.
Sie können diese Standard-run.app
-URLs deaktivieren.
Sie können die URL Ihres Dienstes abrufen, indem Sie in derGoogle Cloud -Konsole auf den Dienstnamen klicken oder den folgenden Befehl in der gcloud CLI ausführen:
gcloud run services describe SERVICE --format 'value(status.url)'
Die deterministische URL hat bei der Anzeige Vorrang.
Wenn der Cloud Run-Dienst als Funktion mit der Cloud Functions v2 API erstellt wurde, wird dem Dienst auch eine cloudfunctions.net
-URL zugewiesen.
Deterministische URL
Mit der deterministischen URL können Sie die Dienst-URL vorhersagen, bevor der Dienst erstellt wird. Das kann für die Kommunikation zwischen Diensten nützlich sein.
Die deterministische URL ist nur für DNS-Segmente mit maximal 63 Zeichen verfügbar. Das DNS-Segment enthält den Dienstnamen, die Projektnummer und alle Traffic-Tags oder Tags.
Die deterministische URL für einen Cloud Run-Dienst hat das folgende Format:
https://[TAG---]SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
Dabei gilt:
- TAG ist das optionale Traffic-Tag für die angeforderte Überarbeitung.
- PROJECT_NUMBER ist die Google Cloud Projektnummer.
- SERVICE_NAME ist der Name des Cloud Run-Dienstes.
- REGION ist der Name der Region, z. B.
europe-west1
.
Nicht deterministische URL
Nicht deterministische URLs haben kein deterministisches Format. Das heißt, da das zweite Feld der URL ein zufälliger Hash ist, können Sie nicht vorhersagen, was die vollständige URL sein wird, bevor Sie die Dienste bereitstellen. Nach der Bereitstellung des Dienstes bleibt die URL jedoch stabil.
Die nicht deterministische URL für einen Cloud Run-Dienst hat das Format https://[
TAG---]
SERVICE_IDENTIFIER.run.app
, wobei TAG auf das optionale Traffic-Tag verweist für die angeforderte Überarbeitung verweist und SERVICE_IDENTIFIER eine stabile und eindeutige Kennung für einen Cloud Run-Dienst ist. Parsen Sie das SERVICE_IDENTIFIER nicht, da es kein festes Format hat und sich die Logik für die SERVICE_IDENTIFIER-Generierung ändern kann.
Antwort streamen
Cloud Run unterstützt das Streamen von HTTP-Antworten.
Es ist keine Konfiguration erforderlich, um das Feature zu aktivieren.
Der Server muss mit einem Transfer-Encoding: chunked
-Antwortheader antworten.
HTTP-zu-HTTPS-Weiterleitung
Cloud Run leitet alle HTTP-Anfragen an HTTPS weiter, beendet jedoch TLS, bevor sie Ihren Webdienst erreichen. Wenn Ihr Dienst Webressourcen generiert, die auf andere Webressourcen mit nicht gesicherten URLs verweisen, etwa http://
, können bei Ihrer Seite Warnungen oder Fehler bei gemischten Inhalten auftreten.
Verwenden Sie das Protokoll https
für alle Referenzweb-URIs oder berücksichtigen Sie Proxyanweisungen in der HTTP-Anfrage wie den HTTP-Header X-Forwarded-Proto
.
HTTP und HTTP/2
Standardmäßig werden für Cloud Run HTTP/2-Anfragen auf HTTP/1 herabgestuft, wenn diese Anfragen an den Container gesendet werden. Wenn Sie für Ihren Dienst explizit HTTP/2 einstellen möchten, finden Sie weitere Informationen unter HTTP/2 verwenden.
Private Dienste erstellen
Zum Erstellen eines privaten Dienstes in Cloud Run müssen Sie den Zugriff auf den Dienst einschränken, indem Sie die IAM-Aufrufer-Berechtigung nutzen.
Sie können den Zugriff auf einen Dienst auch mithilfe eines Autorisierungs- und Authentifizierungsmechanismus auf Anwendungsebene beschränken, z. B. mit der Identity Platform.
Private Dienste testen
Am einfachsten können Sie private Dienste mit dem Cloud Run-Proxy in der Google Cloud CLI testen.
Dadurch wird der private Dienst per Proxy an http://localhost:8080
weitergeleitet
(oder an den mit --port
angegebenen Port), sodass eine
Bereitstellung des Tokens des aktiven Kontos oder eines anderen von Ihnen angegebenen Tokens stattfindet.
Dazu können Sie einen Webbrowser oder ein Tool wie curl
verwenden.
Dies ist die empfohlene Methode zum privaten Testen einer Website oder API in Ihrem Browser.
Sie können einen Dienst lokal über die folgende Befehlszeile in einem Linux-, macOS-, WSL (bevorzugt)- oder in einer cygwin-Umgebung per Proxy weiterleiten:
gcloud run services proxy SERVICE --project PROJECT-ID
Sie können private Dienste auch ohne den Proxy testen. Dazu verwenden Sie ein Tool wie curl
oder übergeben ein Authentifizierungstoken im Header Authorization
:
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" SERVICE_URL
Privater Dienst-zu-Dienst
Ein Cloud Run-Dienst kann einen anderen Cloud Run-Dienst aufrufen mit Dienst-zu-Dienst-Authentifizierung.
Beispielcode, der einen privaten Dienst aufruft
Codebeispiele zum Abrufen eines ID-Tokens und zum Senden einer HTTP-Anfrage an einen privaten Dienst finden Sie unter Dienst-zu-Dienst-Authentifizierung.
Middleware zur Optimierung Ihres Dienstes verwenden
HTTPS-Proxys können allgemeine Funktionen aus einem HTTP-Dienst wie Caching, Anfragevalidierung oder Autorisierung auslagern. Bei Mikrodiensten sind viele HTTP-Proxys Teil einer API-Gateway-Lösung oder eines Servicenetzwerks wie Istio.
Google Cloud Produkte, mit denen Sie Ihren Cloud Run-Dienst optimieren können:
API Gateway, mit dem Sie APIs erstellen, sichern und überwachen können, um sie als Proxys für andere Cloud Run-Dienste zu verwenden.
Firebase Hosting, mit dem Sie ein Webanwendungs-Frontend für Cloud Run als dynamisches Backend erstellen können.