Cloud Run-Funktion bereitstellen

Auf dieser Seite wird beschrieben, wie Sie eine Cloud Run-Funktion bereitstellen und ändern. Eine Beispielanleitung für die Bereitstellung einer Hello World-Funktion finden Sie unter Beispielfunktion bereitstellen.

Bei der Bereitstellung von Cloud Run-Funktionen werden automatisch die Buildpacks von Google Cloud und Cloud Build verwendet, um Container-Images aus dem Quellcode Ihrer Funktion zu erstellen. Sie müssen Docker nicht auf Ihrem Rechner installieren oder Buildpacks oder Cloud Build einrichten.

Bei Cloud Run-Funktionsbereitstellungen wird auch Artifact Registry zum Speichern von Artefakten und zum Verwalten von Container-Images verwendet. Artifact Registry erstellt automatisch das Artifact Registry-Repository mit dem Namen cloud-run-source-deploy, falls Ihr Projekt noch kein Repository mit diesem Namen erstellt hat.

Wenn Sie vorhandene Funktionen haben und den Befehl gcloud functions deploy, die Cloud Functions v2 API oder die Terraform-Konfiguration google_cloudfunctions2_function für die Abwärtskompatibilität verwenden müssen, lesen Sie den Abschnitt Funktionen mit dem Befehl gcloud functions deploy bereitstellen.

Hinweis

  1. Prüfen Sie, ob Sie ein neues Projekt für Cloud Run eingerichtet haben, wie auf der Seite Einrichtung beschrieben.

  2. Aktivieren Sie die Artifact Registry API, die Cloud Build API, die Cloud Run Admin API und die Cloud Logging API:

      gcloud services enable artifactregistry.googleapis.com \
      cloudbuild.googleapis.com \
      run.googleapis.com \
      logging.googleapis.com

    Aktivieren Sie optional die Eventarc API, um Ereignistrigger zu verwenden:

      gcloud services enable eventarc.googleapis.com

  3. Wenn Sie einer Organisationsrichtlinie zur Domaineinschränkung nicht eingeschränkter Aufrufe für Ihr Projekt unterliegen, müssen Sie auf Ihren bereitgestellten Dienst zugreifen, wie unter Private Dienste testen beschrieben.

Erforderliche Rollen

Zum Bereitstellen von Cloud Run-Funktionen müssen Sie oder Ihr Administrator dem Bereitstellungskonto und dem Dienstkonto die folgenden IAM-Rollen zuweisen:

Klicken, um die erforderlichen Rollen für das Bereitstellerkonto aufzurufen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen und Bereitstellen aus der Quelle benötigen:

Klicken, um die erforderlichen Rollen für das Cloud Build-Dienstkonto aufzurufen

Cloud Build verwendet automatisch das Compute Engine-Standarddienstkonto als Standard-Cloud-Build-Dienstkonto zum Erstellen Ihres Quellcodes und Ihrer Cloud Run-Ressource, es sei denn, Sie überschreiben dieses Verhalten. Damit Cloud Build Ihre Quellen erstellen kann, bitten Sie Ihren Administrator, dem Standarddienstkonto der Compute Engine für Ihr Projekt die Berechtigung Cloud Run Builder (roles/run.builder) zu erteilen:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder

Ersetzen Sie PROJECT_NUMBER durch Ihre Google CloudProjektnummer und PROJECT_ID durch Ihre Google CloudProjekt-ID. Eine detaillierte Anleitung zum Auffinden Ihrer Projekt-ID und Projektnummer finden Sie unter Projekte erstellen und verwalten.

Es dauert einige Minuten, bis die Zuweisung der Rolle „Cloud Run-Builder“ für das Compute Engine-Standarddienstkonto übertragen wurde.

Klicken Sie hier, um die erforderlichen Rollen für das Dienstkonto anzuzeigen, wenn Sie Eventarc verwenden.

Wenn Sie Eventarc verwenden, weisen Sie Ihrem Dienstkonto optional die folgenden Rollen zu:

Weitere Informationen zum Zuweisen bestimmter Rollen für Ihre Eventarc-Trigger finden Sie unter Rollen und Berechtigungen für Cloud Run-Ziele.

Eine Liste der IAM-Rollen und -Berechtigungen im Zusammenhang mit Cloud Run finden Sie unter IAM-Rollen für Cloud Run und IAM-Berechtigungen für Cloud Run. Wenn Ihr Cloud Run-Dienst mitGoogle Cloud -APIs wie Cloud-Clientbibliotheken verknüpft ist, lesen Sie die Konfigurationsanleitung für Dienstidentitäten. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Bereitstellungsberechtigungen und Zugriff verwalten.

Funktion erstellen und bereitstellen

Sie können eine Cloud Run-Funktion über die Google Cloud Console oder die gcloud CLI bereitstellen. Klicken Sie auf den Tab, um eine Anleitung zum Verwenden des gewünschten Tools zu erhalten.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Dienste für Cloud Run auf:

    Zu Cloud Run

  2. Klicken Sie auf Funktion schreiben.

  3. Geben Sie im Feld Dienstname einen Namen ein, um Ihre Funktion zu beschreiben. Dienstnamen müssen mit einem Buchstaben beginnen und dürfen maximal 49 Zeichen enthalten, einschließlich Buchstaben, Zahlen oder Bindestrichen. Dienstnamen dürfen nicht auf Bindestriche enden und müssen pro Region und Projekt eindeutig sein. Ein Dienstname kann später nicht mehr geändert werden und ist öffentlich sichtbar.

  4. Verwenden Sie in der Liste Region den Standardwert oder wählen Sie die Region aus, in der Sie Ihre Funktion bereitstellen möchten.

  5. Verwenden Sie in der Liste Laufzeit den Standardwert oder wählen Sie eine Laufzeitversion aus.

  6. Klicken Sie optional im Bereich Trigger auf Trigger hinzufügen und wählen Sie eine Option aus. Der Bereich Eventarc-Trigger wird geöffnet. Dort können Sie die folgenden Details für den Trigger ändern:

    1. Geben Sie im Feld Triggername einen Namen für den Trigger ein oder verwenden Sie den Standardnamen.

    2. Wählen Sie einen Triggertyp aus der Liste aus, um einen der folgenden Triggertypen festzulegen:

      • Google-Quellen, um Trigger für Pub/Sub, Cloud Storage, Firestore und andere Google-Ereignisanbieter anzugeben.

      • Custom zum Erzeugen und Verbrauchen von Ereignissen aus Ihrem Anwendungscode. Folgen Sie der Anleitung im Bereich Eventarc-Trigger, um einen Kanal zu erstellen. Ein Kanal ist eine Ressource, die als Pipeline verwendet wird, um benutzerdefinierte Ereignisse von Erstellern an Nutzer bereitzustellen. Benutzerdefinierte Ereignisse werden in einem Kanal veröffentlicht und ein Eventarc-Trigger abonniert diese Ereignisse.

      • Drittanbieter zur Integration mit Nicht-Google-Anbietern, die eine Eventarc-Quelle anbieten. Weitere Informationen finden Sie unter Drittanbieterereignisse in Eventarc.

    3. Wählen Sie in der Liste einen Ereignisanbieter aus, um ein Produkt auszuwählen, das den Ereignistyp zum Auslösen Ihrer Funktion bereitstellt. Eine Liste der Ereignisanbieter finden Sie unter Ereignisanbieter und -ziele.

    4. Wählen Sie einen Ereignistyp aus der Liste aus. Die Triggerkonfiguration variiert je nach unterstütztem Ereignistyp. Weitere Informationen finden Sie unter Ereignistypen.

    5. Wählen Sie im Feld Region einen Standort für den Eventarc-Trigger aus. Im Allgemeinen sollte der Standort eines Eventarc-Triggers mit dem Standort des Google Cloud Ressource, die Sie auf Ereignisse überwachen möchten. In den meisten Szenarien sollten Sie Ihre Funktion auch in derselben Region bereitstellen. Weitere Informationen zu Eventarc-Trigger-Standorten finden Sie unter Eventarc-Standorte verstehen.

    6. Wählen Sie im Feld Dienstkonto ein Dienstkonto aus. Eventarc-Trigger sind mit Dienstkonten verknüpft, um sie beim Aufrufen Ihrer Funktion als Identität zu verwenden. Das Dienstkonto Ihres Eventarc-Triggers muss die Berechtigung zum Aufrufen Ihrer Funktion haben. Standardmäßig verwendet Cloud Run das Compute Engine-Standarddienstkonto.

    7. Geben Sie optional den Dienst-URL-Pfad an, an den die eingehende Anfrage gesendet werden soll. Dies ist der relative Pfad im Zieldienst, an den die Ereignisse für den Trigger gesendet werden sollen. Beispiel: /, /route, route und route/subroute.

    8. Sobald Sie die erforderlichen Felder ausgefüllt haben, klicken Sie auf Speichern Sie den Trigger.

  7. Konfigurieren Sie unter Authentifizierung Folgendes:

    • Wenn Sie eine öffentliche HTTP-Funktion erstellen, z. B. einen Webhook, wählen Sie Öffentlichen Zugriff zulassen. Durch Anklicken des Kästchens wird der Sonderkennzeichnung allUser die Rolle "IAM-Invoker" zugewiesen. Sie können die Einstellung mit IAM bearbeiten, nachdem Sie den Dienst erstellt haben. Wenn Sie nicht berechtigt sind (Cloud Run Admin-Rolle), diese Option auszuwählen, wird der Dienst bereitgestellt und erfordert eine Authentifizierung.

    • Wenn Sie eine ereignisgesteuerte Funktion erstellen, wählen Sie Authentifizierung anfordern aus.

  8. Optional können Sie die folgenden zusätzlichen Konfigurationen für Ihre Funktionen aktualisieren:

    1. Legen Sie die Abrechnung nach Bedarf fest.

    2. Unter Service scaling können Sie, wenn Sie die standardmäßige Cloud Run autoscaling verwenden, optional die minimum Instanzen angeben. Wenn Sie die manuelle Skalierung verwenden, geben Sie die Anzahl der Instanzen für den Dienst an.

    3. Legen Sie die Steuerung für eingehenden Traffic nach Bedarf fest.

    4. Maximieren Sie den Abschnitt Container, Volumes, Netzwerk, Sicherheit, um weitere optionale Einstellungen auf den entsprechenden Tabs festzulegen:

  9. Klicken Sie auf Erstellen und warten Sie, bis der Dienst in Cloud Run mit einer Platzhalter-Überarbeitung erstellt wurde.

  10. Die Console leitet Sie zum Tab Quelle weiter, auf dem Sie den Quellcode Ihrer Funktion sehen. Klicken Sie auf Speichern und wieder bereitstellen.

  11. Auf dem Tab Quelle können Sie optional auf Nutzlast anzeigen klicken, um ein Beispiel für die Nutzlast eingehender Ereignisse zu sehen.

  12. Testen Sie die erstellte Funktion nach der Bereitstellung, indem Sie auf die Schaltfläche Testen klicken.

gcloud

  1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Aktualisieren Sie die Komponenten von gcloud auf die neueste Version:

    gcloud components update

  3. Führen Sie den folgenden Befehl in dem Verzeichnis aus, das den Beispielcode enthält:

    gcloud run deploy FUNCTION \
       --source . \
       --function FUNCTION_ENTRYPOINT \
       --base-image BASE_IMAGE \
       --region REGION

    Ersetzen Sie:

    • FUNCTION mit dem Namen der Funktion, die Sie bereitstellen. Sie können diesen Parameter auch weglassen, werden dann jedoch nach dem Namen gefragt.

    • FUNCTION_ENTRYPOINT durch den Einstiegspunkt zur Funktion in Ihrem Quellcode. Dies ist der Code, der von Cloud Run ausgeführt wird, wenn Ihre Funktion ausgeführt wird. Der Wert dieses Flags muss ein Funktionsname oder ein voll qualifizierter Klassenname sein, der in Ihrem Quellcode vorhanden ist.

    • BASE_IMAGE mit der Basis-Bildumgebung für Ihre Funktion, wie z. B. nodejs24, python314, go127, java25, dotnet10, ruby40 ​​oder php85. Weitere Informationen zu Basis-Images und den in den einzelnen Images enthaltenen Paketen finden Sie unter Laufzeit-Basis-Images.

    • REGION durch die Google Cloud Region, in der Sie die Funktion bereitstellen möchten. Beispiel: europe-west1

    Optional:

    • Wenn Sie eine öffentliche HTTP-Funktion erstellen, z. B. einen Webhook, geben Sie das Flag --allow-unauthenticated an. Mit diesem Flag wird der Sonderkennzeichnung allUser die Cloud Run IAM-Invoker-Rolle zugewiesen. Sie können die Einstellung mit IAM bearbeiten, nachdem Sie den Dienst erstellt haben. Wenn Sie eine ereignisgesteuerte Funktion oder einen authentifizierten Dienst erstellen, können Sie dieses Flag weglassen.

Optional können Sie Ihrer Funktion nach der Bereitstellung Eventarc-Trigger hinzufügen. Um einen Trigger hinzuzufügen, führen Sie folgenden Befehl aus:

  gcloud eventarc triggers create EVENTARC_TRIGGER_NAME \
      --location=EVENTARC_TRIGGER_LOCATION \
      --destination-run-service=FUNCTION \
      --destination-run-region=REGION \
      --event-filters="type=EVENTARC_FILTER_TYPE" \
      --event-filters="EVENTARC_EVENT_FILTER" \
      --service-account=EVENTARC_TRIGGER_SERVICE_ACCOUNT

Ersetzen Sie:

  • EVENTARC_TRIGGER_NAME mit dem Namen des Eventarc-Triggers.

  • EVENTARC_TRIGGER_LOCATION mit dem Standort für den Eventarc-Trigger. Im Allgemeinen sollte der Standort eines Eventarc-Triggers mit dem Standort des Google Cloud Ressource, die Sie auf Ereignisse überwachen möchten. In den meisten Szenarien sollten Sie Ihre Funktion auch in derselben Region bereitstellen. Weitere Informationen zu Eventarc-Triggerstandorten finden Sie unter Informationen zu Eventarc-Standorten.

  • FUNCTION durch den Namen Ihrer bereitgestellten Funktion.

  • REGION durch die Cloud Run-Region der Funktion.

  • EVENTARC_FILTER_TYPE durch die Ereignisfilter, die der Trigger überwacht. Ein Ereignis, das mit allen --event-filters-Filtern übereinstimmt, löst Aufrufe Ihrer Funktion aus. Jeder Trigger muss einen unterstützten Ereignistyp im Format --event-filters="type=EVENTARC_FILTER_TYPE" haben. Dieser Ereignistyp kann nach dem Erstellen nicht mehr geändert werden. Wenn Sie EVENT_FILTER_TYPE ändern möchten, erstellen Sie einen neuen Trigger und löschen Sie den alten. Optional können Sie das Flag --event-filters mit einem unterstützten Filter in der Form ATTRIBUTE=VALUE wiederholen, um weitere Filter hinzuzufügen.

  • EVENTARC_TRIGGER_SERVICE_ACCOUNT durch ein Dienstkonto. Eventarc-Trigger sind mit Dienstkonten verknüpft, um sie beim Aufrufen Ihrer Funktion als Identität zu verwenden. Das Dienstkonto Ihres Eventarc-Triggers muss die Berechtigung zum Aufrufen Ihrer Funktion haben. Standardmäßig verwendet Cloud Run das Compute-Standarddienstkonto.

Terraform

Wenn Sie Funktionen mit Terraform verwalten möchten, müssen Sie den Funktionscode in ein Container-Image einbinden und dann den Cloud Run-Dienst in einer Terraform-Konfiguration mit der Ressource google_cloud_run_v2_service des Google Cloud Platform-Anbieters definieren.

  1. Folgen Sie den Anweisungen zum Erstellen einer Funktion von Grund auf, um ein Container-Image zu erstellen, das mit automatischen Sicherheitsupdates kompatibel ist. Kopieren Sie den vollständigen Pfad des Container-Images für die Variable IMAGE_URL, die im nächsten Schritt verwendet wird.

  2. Erstellen Sie eine neue main.tf-Datei mit folgendem Inhalt:

    provider "google" {
  project = "PROJECT-ID"
}

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  client   = "terraform"
  template {
    containers {
      name = "SERVICE"
      image = "IMAGE_URL" # Container image built from your function in the previous step.
      base_image_uri = "BASE_IMAGE"
    }
  }
  build_config{
    function_target = "FUNCTION_TARGET"
    image_uri = "IMAGE_URL"
    base_image = "BASE_IMAGE"
    enable_automatic_updates = true
  }
}
resource "google_cloud_run_v2_service_iam_member" "noauth" {
  location = google_cloud_run_v2_service.default.location
  name     = google_cloud_run_v2_service.default.name
  role     = "roles/run.invoker"
  member   = "allUsers"
}

    Ersetzen Sie:

    • PROJECT-ID durch die Google Cloud Projekt-ID.
    • REGION mit der Google Cloud -Region. Beispiel: europe-west1.
    • SERVICE durch den Namen Ihres Cloud Run-Dienstes. Dienstnamen dürfen maximal 49 Zeichen lang sein und pro Region und Projekt nur einmal vorkommen.
    • IMAGE_URL durch einen Verweis auf das Container-Image, das nur Ihre erstellte Funktion enthält
    • BASE_IMAGE mit der Basis-Bildumgebung für Ihre Funktion, wie z. B. nodejs24, python314, go127, java25, dotnet10, ruby40 ​​oder php85. Weitere Informationen zu Basis-Images und den in den einzelnen Images enthaltenen Paketen finden Sie unter Laufzeit-Basis-Images.
    • FUNCTION_TARGET mit dem Funktionsnamen, den Sie als Einstiegspunkt verwenden möchten.

    Diese Konfiguration ermöglicht öffentlichen Zugriff (entspricht --allow-unauthenticated). Wenn Sie den Dienst privat machen möchten, entfernen Sie die google_cloud_run_v2_service_iam_member-Stanza.

  3. Initialisieren Sie Terraform:

    terraform init

  4. Wenden Sie die Terraform-Konfiguration an:

    terraform apply

    Bestätigen Sie, dass Sie die beschriebenen Aktionen anwenden möchten, indem Sie yes eingeben.

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 ist. Sie sollten dabei jedoch auch den Standort der anderen Google Cloud-Produkte berücksichtigen, die der Cloud Run-Dienst verwendet. Die gemeinsame Nutzung von Google Cloud Produkten an mehreren Standorten kann sich auf die Latenz und die Kosten Ihres Dienstes auswirken.

Cloud Run ist in diesen Regionen verfügbar:

Unterliegt Preisstufe 1

Unterliegt Preisstufe 2

Wenn Sie bereits einen Cloud Run-Dienst erstellt haben, können Sie dessen Region im Cloud Run-Dashboard der Google Cloud -Konsole aufrufen.

Ereigniswiederholungen aktivieren

Eventarc verwendet Pub/Sub als Transportschicht und hat eine Standardrichtlinie für Wiederholungsversuche, die möglicherweise nicht gut für Ihre Funktion geeignet ist.

Nachdem Sie einen Eventarc-Trigger erstellt haben, empfehlen wir Ihnen dringend, die Wiederholrichtlinie in Eventarc zu aktualisieren und ein Thema für unzustellbare Nachrichten in Pub/Sub zu konfigurieren.

Image-Repository angeben

Cloud Run-Funktionsbereitstellungen verwenden Artifact Registry, um Artefakte zu speichern und Container-Images zu verwalten. Artifact Registry erstellt automatisch das Artifact Registry-Repository REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy, falls Ihr Projekt noch keins mit diesem Namen erstellt hat.

Verwenden Sie den folgenden Befehl, um ein selbst erstelltes Artifact Registry-Repository anzugeben:

gcloud 

gcloud run deploy FUNCTION \
  --source . \
  --function FUNCTION_ENTRYPOINT \
  --base-image BASE_IMAGE \
  --region REGION \
  --image IMAGE_URL

Ersetzen Sie Folgendes:

  • FUNCTION mit dem Namen der Funktion, die Sie bereitstellen. Sie können diesen Parameter auch weglassen, werden dann jedoch nach dem Namen gefragt.

  • FUNCTION_ENTRYPOINT durch den Einstiegspunkt zur Funktion in Ihrem Quellcode. Dies ist der Code, der von Cloud Run ausgeführt wird, wenn Ihre Funktion ausgeführt wird. Der Wert dieses Flags muss ein Funktionsname oder ein voll qualifizierter Klassenname sein, der in Ihrem Quellcode vorhanden ist.

  • BASE_IMAGE mit der Basisbildumgebung für Ihre Funktion, z. B. nodejs24, python314, go127, java25, dotnet10, ruby40 oder php85. Weitere Informationen zu Basis-Images und den in den einzelnen Images enthaltenen Paketen finden Sie unter Laufzeit-Basis-Images.

  • REGION durch die Google Cloud Region, in der Sie die Funktion bereitstellen möchten. Beispiel: europe-west1

  • IMAGE_URL durch einen Verweis auf den Image-Pfad mit dem Artifact Registry-Image-Repository Ihrer Wahl, z. B. projects/PROJECT_NAME/locations/LOCATION/repositories/REPOSITORY_NAME/FUNCTION. Der Bildname muss mit dem Namen der Funktion übereinstimmen, die Sie erstellen. Wird nur der Repository-Pfad angegeben, wird das Image mit dem Funktionsnamen FUNCTION erstellt.

Bei der Angabe eines Artifact Registry-Repositorys, das sich in einem anderen Projekt oder einer anderen Region befindet, müssen Sie Folgendes beachten:

IAM-Konfigurationen:

  • Stellen Sie sicher, dass Sie die IAM-Berechtigungen zum Bereitstellen von Images aus other Google Cloud projects konfiguriert haben.
  • Das Build-Dienstkonto muss Lese- und Schreibzugriff auf REPOSITORY haben.

Netzwerkkonfigurationen:

  • Prüfen Sie, ob das Ziel REPOSITORY von der aktuellen Projektkonfiguration aus erreichbar ist.

VPC Service Controls-Konfigurationen:

  • Das Build-Dienstkonto muss das Ziel REPOSITORY innerhalb des VPC-SC-Perimeters erreichen können.

Einschränkungen für den Datenstandort:

  • Wenn Sie eine REPOSITORY in einer anderen Region angeben als der, in der sich Ihre Funktion befindet, kommt es zu einer Datenübertragung zwischen Regionen.

Vorhandene Funktion ändern

Sie können entweder die Konfiguration oder den Code Ihrer Funktion ändern:

Konfiguration ändern

Um Konfigurationsparameter wie Abrechnungsoptionen, Arbeitsspeicher und VPC-Konnektivität zu ändern, folgen Sie den Anweisungen im entsprechenden Tab:

Console

  1. Rufen Sie in der Google Cloud Console die Seite Dienste für Cloud Run auf:

    Zu Cloud Run

  2. Klicken Sie in der Übersicht auf den zu aktualisierenden Dienst, um dessen Details anzuzeigen.

  3. Ändern Sie die Konfigurationseinstellungen auf den entsprechenden Tabs.

  4. Klicken Sie auf View diff & redeploy, dann auf Deploy changes, um Ihre Änderungen bereitzustellen.

gcloud

  1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Um eine oder mehrere Dienstkonfigurationseinstellungen zu aktualisieren, verwenden Sie den Befehl gcloud run services update SERVICE mit den Befehlszeilenparametern der Konfiguration, die Sie aktualisieren möchten. Ersetzen Sie SERVICE durch den Namen des Dienstes.

Neuen Quellcode neu bereitstellen

Sie können das Basis-Image, die Laufzeit und den Quellcode Ihrer Funktion entweder über die Google Cloud Console oder die gcloud CLI ändern.

Klicken Sie auf den Tab, um eine Anleitung zum gewünschten Tool zu erhalten.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Dienste für Cloud Run auf:

    Zu Cloud Run

  2. Klicken Sie in der Liste Dienste auf die zu aktualisierende Funktion, um ihre Details anzuzeigen.

  3. Rufen Sie den Tab Quelle auf und klicken Sie auf Quelle bearbeiten.

  4. Klicken Sie neben Basis-Image auf Laufzeit- und Sicherheitsupdates bearbeiten, wählen Sie bei Bedarf eine andere Laufzeit oder Umgebung aus der Liste aus und klicken Sie auf Speichern und neu bereitstellen.

  5. Ändern Sie den Funktionseinstiegspunkt nach Bedarf.

  6. Im Abschnitt Dateien können Sie Datei hinzufügen auswählen, um eine neue Datei zu erstellen, Datei umbenennen, um eine Datei umzubenennen, oder Datei löschen, um eine Datei zu löschen.

  7. Ändern Sie im Abschnitt Code den Quellcode nach Bedarf.

  8. Klicken Sie auf Speichern und erneut bereitstellen und warten Sie, bis die Bereitstellung abgeschlossen ist.

gcloud

  1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Führen Sie den folgenden Befehl in dem Verzeichnis aus, das den Quellcode der Funktion enthält:

    gcloud run deploy FUNCTION \
       --source . \
       --function FUNCTION_ENTRYPOINT \
       --base-image BASE_IMAGE \
       --region REGION

    Ersetzen Sie:

    • FUNCTION mit dem Namen der Funktion, die Sie ändern möchten.

    • FUNCTION_ENTRYPOINT durch den Einstiegspunkt zur Funktion in Ihrem Quellcode.

    • BASE_IMAGE mit der Basis-Bildumgebung für Ihre Funktion, wie z. B. nodejs24, python314, go127, java25, dotnet10, ruby40 ​​oder php85.

      Alternativ können Sie, wenn Sie ein bestimmtes Systempaket im Stack verwenden oder die Region angeben möchten, aus der das Basisimage heruntergeladen wird, eine der folgenden Optionen angeben:

      • Der vollständige Pfad zum Basis-Image, z. B. us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/nodejs24. Mit dieser Option können Sie das Basis-Image, ein bestimmtes Systempaket im Stack und die Region angeben, aus der das Basis-Image heruntergeladen wird.
      • Der Alias des vollständigen Pfads zum Basis-Image, z. B. google-24/nodejs24 oder google-24-full/nodejs24. Mit dieser kürzeren Alias-Option können Sie das Basis-Image und ein bestimmtes Systempaket im Stack angeben.

      Weitere Informationen zu Basis-Images und den in den einzelnen Images enthaltenen Paketen finden Sie unter Laufzeit-Basis-Images.

    • REGION durch die Google Cloud Region, in der Sie die Funktion bereitstellen möchten. Beispiel: europe-west1

    Optionale Flags

    Beim Bearbeiten Ihrer Funktion können Sie die folgenden optionalen Flags konfigurieren:

    • Build-Umgebungsvariablen: Flags zum Angeben von Umgebungsvariablen während des Build-Schritts, z. B. zum Konfigurieren von build-spezifischen Zertifikaten oder Parametern.

    • Worker-Pool-Flags zum Angeben, welcher Worker-Pool in einem durch VPC Service Controls gesicherten Build-Kontext verwendet werden soll.

    • Benutzerdefinierte Build-Dienstkonten: Flags zum Angeben einer Alternative zum Standard-Build-Dienstkonto für mehr Sicherheit.

    • Das Flag Automatische Basis-Image-Updates kann verwendet werden, um automatische Updates zu deaktivieren. Standardmäßig sind automatische Sicherheitsupdates für Funktionen aktiviert.

Systemdiagnose für das Deployment deaktivieren

Standardmäßig prüft Cloud Run, ob Ihr Deployment fehlerfrei ist, indem eine Instanz gestartet und darauf gewartet wird, dass die Startprüfung erfolgreich ist. Schlägt die Gesundheitsprüfung fehl, wird die Revision als fehlerhaft markiert und der Datenverkehr wird nicht dorthin umgeleitet.

Wenn sie nicht benötigt wird oder um die Bereitstellungsgeschwindigkeit zu erhöhen, kann die Systemdiagnose für die Bereitstellung deaktiviert werden:

gcloud

Verwenden Sie das Flag --no-deploy-health-check, um die Systemdiagnose für die Bereitstellung zu deaktivieren:

gcloud run deploy --image IMAGE_URL --no-deploy-health-check

Ersetzen Sie Folgendes:

  • IMAGE_URL: ein Verweis auf das Container-Image, z. B. us-docker.pkg.dev/cloudrun/container/hello:latest Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat das Format LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.

Verwenden Sie --deploy-health-check, um die Systemdiagnose für das Deployment wieder zu aktivieren, falls sie zuvor deaktiviert wurde.

YAML

Wenn Sie die Systemdiagnose für die Bereitstellung deaktivieren möchten, fügen Sie der Datei spec.template.metadata.annotations die Annotation run.googleapis.com/health-check-disabled mit dem Wert 'true' hinzu.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/health-check-disabled: 'true'

Terraform

Wenn Sie die Systemdiagnose für die Bereitstellung deaktivieren möchten, legen Sie das health_check_disabled-Argument im template-Block auf true fest.

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  ...
  template {
    health_check_disabled = true
    ...
  }
}

Quell-Bucket

Ihr Quellcode muss für den Build-Prozess und denGoogle Cloud -Quellcode-Editor zugänglich sein. Dies wird erreicht, indem Sie Ihren Quellcode in einen Cloud Storage Bucket hochladen.

Wenn Sie die gcloud CLI oder die Google Cloud Console für die Bereitstellung verwenden, wird automatisch ein Cloud Storage-Bucket bereitgestellt und Ihr Quellcode wird für Sie hochgeladen. Standardmäßig wird Ihr Code in einem Bucket namens run-sources-PROJECT_ID-REGION gespeichert. Sie sind für die Verwaltung der Access Control Lists (ACLs) und Quellobjekte in diesem Bucket verantwortlich.

Wenn Sie einen bestimmten Bucket verwenden müssen, z. B. um vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) zu verwenden, müssen Sie Ihre lokalen Quelldateien zuerst in einem Archiv (z. B. einer ZIP-Datei) verpacken. Laden Sie dieses Archiv dann in Ihren Bucket hoch. Wenn Sie von diesem benutzerdefinierten Speicherort aus bereitstellen möchten, verwenden Sie die gcloud CLI mit dem Flag --source=gs://BUCKET_NAME/OBJECT_PATH.

Nächste Schritte

Nachdem Sie eine neue Cloud Run-Funktion bereitgestellt haben, können Sie Folgendes tun: