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 aktivieren, dass er auf HTTPS-Anfragen reagiert.
Alle Cloud Run-Dienste haben eine stabile HTTPS-URL, die den Standard-HTTPS-Endpunkt für den Dienst darstellt. Sie können aber auch benutzerdefinierte Domains konfigurieren.
Beispiele für Anwendungsfälle sind:
- Benutzerdefinierte RESTful-Web-API
- Privater Mikrodienst
- HTTP-Middleware oder Reverse-Proxy für Ihre Webanwendungen
- Vorgepackte Webanwendung
Öffentliche Dienste erstellen
Zum 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 nicht authentifizierter (öffentlicher) Zugriff auf den Dienst zulässig ist.
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-URLs deaktivieren.run.app
Sie können die URL Ihres Dienstes abrufen, indem Sie in der Google Cloud Console 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 Priorität.
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 vor dem Erstellen des Dienstes vorhersagen. Das kann für die Dienst-zu-Dienst-Kommunikation 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. Da das zweite Feld der URL ein zufälliger Hash ist, können Sie die vollständige URL nicht vorhersagen, bevor Sie die Dienste bereitstellen. Nachdem Sie den Dienst bereitgestellt haben, 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 für die angeforderte Überarbeitung verweist und SERVICE_IDENTIFIER eine stabile und eindeutige
Kennung für einen Cloud Run-Dienst ist. Analysieren Sie die
SERVICE_IDENTIFIER nicht, da sie 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.
Für die Aktivierung der Funktion ist keine Konfiguration erforderlich.
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.
So können Sie einen Webbrowser oder ein Tool wie curl verwenden.
Dies ist die empfohlene Methode, um eine Website oder API privat in Ihrem Browser zu testen.
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 und übergeben ein Autorisierungstoken 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 zum Aufrufen eines privaten Dienstes
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 Service Mesh wie Istio.
Google Cloud Zu den Produkten, mit denen Sie Ihren Cloud Run-Dienst optimieren können, gehören:
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.