Übersicht: Build-Prozess

Wenn Sie den Quellcode Ihrer Funktion in Cloud Run Functions bereitstellen, wird diese Quelle in einem Cloud Storage-Bucket gespeichert. Cloud Build erstellt dann automatisch Ihren Code in einem Container-Image und überträgt dieses Image per Push in eine Image-Registry. Cloud Run Functions greift auf dieses Image zu, wenn es zum Ausführen der Funktion den Container ausführen muss. Wenn für Ihre Funktion noch Container Registry verwendet wird, sollten Sie so schnell wie möglich zu Artifact Registry wechseln.

Wichtig: Container Registry wurde verworfen und wird demnächst eingestellt. In Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden neue gcr.io-Repositories standardmäßig in Artifact Registry gehostet. Ab dem 15. Mai 2024 unterstützen Google Cloud -Projekte ohne vorherige Verwendung von Container Registry nur das Hosting und die Verwaltung von Images für die Domain gcr.io in Artifact Registry.

Container Registry soll am 18. März 2025 eingestellt werden. Weitere Informationen zur Einstellung finden Sie unter Einstellung von Container Registry.

Das Erstellen des Images erfolgt komplett automatisch und erfordert keine direkte Eingabe von Ihnen. Alle im Build-Prozess verwendeten Ressourcen werden in Ihrem eigenen Nutzerprojekt ausgeführt.

Wenn Sie den Build-Prozess in Ihrem Projekt ausführen, hat das diese Folgen:

• Sie haben direkten Zugriff auf alle Build-Logs.

• Es gibt kein voreingestelltes Kontingent für die Build-Dauer, obwohl Cloud Build über ein eigenes Standardkontingent für Gleichzeitigkeit verfügt.

• Sie können sich das aktuelle Container-Image und das zuvor bereitgestellte Container-Image ansehen. Beide sind in Artifact Registry gespeichert.

• Cloud Storage wird in Ihrem Projekt verwendet, um das Quellcodeverzeichnis für Ihre Funktionen zu speichern. Wichtige Hinweise:

  • Wenn Sie eine Funktion mit der Google Cloud CLI oder der Google Cloud Console erstellen, wird ein Upload-Bucket erstellt, in dem Ihr Quellcode gespeichert wird. Dieser Upload-Bucket könnte den Namen gcf-v2-uploads-PROJECT_NUMBER-REGION.cloudfunctions.appspot.com haben.
  • Nach dem Upload wird der Funktionscode in einem separaten Quell-Bucket gespeichert:
    • Wenn Sie die Standardverschlüsselung verwenden, heißt dieser Bucket gcf-v2-sources-PROJECT_NUMBER-REGION.
    • Wenn Sie Ihre Daten mit CMEK schützen, heißt der Bucket gcf-v2-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.
  • Sowohl für Quell- als auch für Upload-Buckets ist keine Aufbewahrungsdauer festgelegt.

Hinweis: Wenn Sie versehentlich eine Cloud Run Function löschen, können Sie sie mithilfe der Quelldateien aus dem Bucket gcf-sources wiederherstellen. Laden Sie dazu die ZIP-Datei herunter und stellen Sie sie wieder bereit. Hinweis: Mit gcf-sources bucket werden nur die letzten beiden Versionen des Quellcodes beibehalten. Wenn Sie die Funktion löschen und die Cloud Run Functions API deaktivieren, wird der Bucket gcf-sources nicht automatisch gelöscht. Wenn Sie alle mit Cloud Run Functions verknüpften Ressourcen vollständig entfernen möchten, müssen Sie den Bucket gcf-sources manuell löschen.

Merkmale des Build-Prozesses

Der Build-Prozess hat die folgenden Eigenschaften:

• Die Cloud Build API muss für Ihr Projekt aktiviert sein.

  Klicken Sie zum manuellen Aktivieren der API auf den obigen Link, wählen Sie Ihr Projekt aus dem Drop-down-Menü aus und folgen Sie der Anleitung, um die Benutzeroberfläche zu aktivieren.

• Da der gesamte Build-Prozess im Kontext Ihres Projekts erfolgt, fallen für das Projekt die Preise für die enthaltenen Ressourcen an:

  • Preise für Cloud Build finden Sie auf der Preisseite. Für diesen Prozess wird die Standardinstanzgröße von Cloud Build verwendet, da diese Instanzen vorbereitet und schneller verfügbar sind. Cloud Build bietet eine kostenlose Stufe: Weitere Informationen finden Sie im Dokument mit der Preisübersicht.

  • Preise für Cloud Storage finden Sie auf der Preisseite. Cloud Storage bietet eine kostenlose Stufe: Weitere Informationen finden Sie im Dokument mit der Preisübersicht.

  • Preise für Artifact Registry finden Sie auf der Preisseite.

  • Preise für Container Registry (eingestellt) finden Sie auf der Preisseite.

• Da der Build-Prozess kostenpflichtig ist, muss Ihrem Projekt ein Cloud-Rechnungskonto zugeordnet sein.

Hinweis: Wenn Sie gcp.resourceLocations in den Einschränkungen Ihrer Organisationsrichtlinie verwenden, sollten Sie den entsprechenden Standort mit mehreren Regionen angeben. Wenn Sie beispielsweise Bereitstellungen in einer der us-Regionen vornehmen, sollten Sie us-locations verwenden. Dadurch kann Cloud Build auf den Artifact Registry-Storage-Bucket zugreifen.

Build-Image-Logs aufrufen

Ein wichtiger Vorteil beim Verschieben des Build-Image-Prozesses in Ihr Nutzerprojekt ist der Zugriff auf Build-Logs. Sie können die gcloud CLI oder die Google Cloud Console verwenden, um auf die Logs zuzugreifen, die über Cloud Logging verfügbar sind.

gcloud

1. Stellen Sie die Funktion mit dem Befehl gcloud functions deploy bereit.

2. Die URL der Logs wird als Teil der Antwort im Terminalfenster angezeigt. Beispiel:

   Deploying function (may take a while - up to 2 minutes)...⠹
   **For Cloud Build Stackdriver Logs**, visit:
   https://console.cloud.google.com/logs/viewer?project=&advancedFilter=resource.type%
   3Dbuild%0Aresource.labels.build_id%3D38d5b662-2315-45dd-8aa2-
   380d50d4f5e8%0AlogName%3Dprojects%2F%
   2Flogs%2Fcloudbuild
   Deploying function (may take a while - up to 2 minutes)...done.

Google Cloud Console

So rufen Sie Funktionslogs auf der Cloud Run-Seite auf:

1. Zu Cloud Run

2. Klicken Sie in der angezeigten Liste auf die gewünschte Funktion.

3. Klicken Sie auf den Tab LOGS, um die Anfrage- und Containerlogs für alle Überarbeitungen dieser Funktion abzurufen. Sie können nach Logschweregrad filtern.

Image-Registry

Cloud Run Functions verwendet Artifact Registry, um die aus dem Quellcode Ihrer Funktion erstellten Images zu speichern. Bilder werden in einem Repository mit dem Namen REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts im selben Projekt gespeichert, in dem Ihre Funktion erstellt wird.

Führen Sie den folgenden Befehl aus, um ein selbst verwaltetes Artifact Registry-Repository anzugeben:

gcloud functions deploy FUNCTION_NAME \
   --docker-registry=artifact-registry \
   --docker-repository=REPOSITORY \
   [FLAGS...]

Ersetzen Sie Folgendes:

• FUNCTION_NAME: Der Name der Funktion.
• REPOSITORY: Der voll qualifizierte Artifact Registry-Repository-Name im folgenden Format: projects/PROJECT_NAME/locations/LOCATION/repositories/REPOSITORY.

Preview — Cloud Run functions cross project repository

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Wenn Sie ein Artifact Registry-Repository in einem anderen Projekt oder einer anderen Region angeben, müssen Sie möglicherweise zusätzliche Konfigurationen berücksichtigen:

IAM-Konfigurationen:

• 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.

Funktionen identifizieren, die Container Registry verwenden

Funktionen, für die Container Registry verwendet wird, haben den Schlüssel buildConfig.dockerRegistry in ihren Funktionsbeschreibungen. So rufen Sie die Funktionsbeschreibung ab:

gcloud functions describe FUNCTION_NAME --no-gen2

Ersetzen Sie FUNCTION_NAME durch den Namen Ihrer Funktion.

gcloud asset list \
   --content-type=resource \
   --asset-types=cloudfunctions.googleapis.com/Function \
   --organization=ORGANIZATION_ID \
   --filter "resource.data.buildConfig.dockerRegistry='CONTAINER_REGISTRY'"

Ersetzen Sie ORGANIZATION_ID durch die Ressourcen-ID Ihrer Organisation.

Auf Artifact Registry umstellen

Wichtig :Ab dem 18. Februar 2025 werden Bereitstellungen von Cloud Run Functions (1. Generation) unabhängig von der vorherigen Auswahl auf Artifact Registry umgestellt. So können Sie die Einstellung von Container Registry bewältigen, ohne dass Funktionen der 1. Generation, die noch auf Container Registry verweisen, beeinträchtigt werden. Aktivieren Sie die Artifact Registry API, um Unterbrechungen zu vermeiden.

Sie können festlegen, dass Funktionen Images in Artifact Registry veröffentlichen. Ändern Sie dazu die Repository-Einstellungen:

gcloud functions deploy FUNCTION_NAME \
   --docker-registry=artifact-registry \
   --no-gen2 \
   [FLAGS...]

Ausführliche Preisinformationen finden Sie unter Cloud Run Functions-Preise.

Build mit privaten Pools sichern

Damit Ihre Funktionen Abhängigkeiten verwenden können (z. B. npm-Pakete), hat Cloud Build standardmäßig uneingeschränkten Internetzugriff während des Build-Prozesses. Wenn Sie einen VPC Service Controls-Perimeter (VPC SC) eingerichtet haben und den Zugriff des Builds auf Abhängigkeiten beschränken möchten, die im Perimeter gespeichert sind, können Sie die privaten Worker-Pools von Cloud Build verwenden verwenden.

Gehen Sie im Allgemeinen so vor, um einen privaten Pool einzurichten:

1. Erstellen Sie Ihren privaten Worker-Pool. Siehe Private Pools erstellen und verwalten.

2. Konfigurieren Sie den VPC Service Controls-Perimeter. Siehe VPC Service Controls verwenden.

3. Wenn sich Ihr privater Worker-Pool in einem anderen Projekt als Ihre Funktion befindet, müssen Sie dem Cloud Run Functions-Dienst-Agent-Dienstkonto ([e-mail]) die cloudbuild.workerPoolUser, damit der Cloud Build-Dienst auf den Worker-Pool zugreifen kann.

   gcloud projects add-iam-policy-binding PRIVATE_POOL_PROJECT_ID \
       --member serviceAccount:[e-mail]
       --role roles/cloudbuild.workerPoolUser

   Dabei ist FUNCTION_PROJECT_NUMBER die Nummer des Projekts, in dem die Funktion ausgeführt wird, und PRIVATE_POOL_PROJECT_ID die ID des Projekts, in dem sich der Worker-Pool befindet. Weitere Informationen finden Sie unter Builds in einem privaten Pool ausführen.

Stellen Sie die Funktion zum Erstellen mit einem privaten Pool bereit:

gcloud functions deploy FUNCTION_NAME \
   --runtime RUNTIME \
   --build-worker-pool PRIVATE_POOL_NAME
   [FLAGS...]

Dabei ist FUNCTION_NAME der Name der Funktion, RUNTIME die von Ihnen verwendete Laufzeit und PRIVATE_POOL_NAME der Name Ihres Pools.

Wenn Sie einen bestimmten privaten Pool nicht mehr verwenden und stattdessen den standardmäßigen Cloud Build-Pool verwenden möchten, verwenden Sie das Flag --clear-build-worker-pool bei der erneuten Bereitstellung.

gcloud functions deploy FUNCTION_NAME \
   --runtime RUNTIME \
   --clear-build-worker-pool
   [FLAGS...]

Dabei ist FUNCTION_NAME der Name der Funktion und RUNTIME die von Ihnen verwendete Laufzeit.

Build mit einem benutzerdefinierten Dienstkonto sichern

Cloud Run Functions übernehmen Ihren Quellcode und senden ihn zur Containerisierung an Cloud Build. Die containerisierte Funktion wird in Artifact Registry gespeichert und als Dienst in Cloud Run bereitgestellt. Standardmäßig weist Cloud Build ein Dienstkonto zu, das beim Ausführen des Builds als Hauptkonto fungiert. Seit Juli 2024 wird in neuen Projekten in einer Organisation das Compute Engine-Standarddienstkonto als Hauptberechtigter für die Ausführung eines Builds verwendet. Weitere Informationen finden Sie unter Änderung des Cloud Build-Standarddienstkontos. Aus Sicherheitsgründen hat das Compute Engine-Standarddienstkonto nicht genügend Berechtigungen, um den Build auszuführen.

Für Google Cloud Projekte, die vor Juli 2024 erstellt wurden, verwendet Cloud Build das bisherige Cloud Build-Dienstkonto. Dieses Dienstkonto wurde entwickelt, um Nutzern die Ausführung einer Vielzahl von Anwendungsfällen zu ermöglichen, die für die Anforderungen Ihres Projekts möglicherweise zu weit gefasst sind. Wenn Sie Ihre vorhandenen Projekte aus diesem Dienstkonto verschieben möchten, können Sie die folgenden Schritte ausführen, um Ihre Build-Umgebung für Funktionen weiter zu schützen:

1. Verhindert, dass das Cloud Build-Legacy-Dienstkonto für den Build verwendet wird
2. Verhindert, dass das Standard-Compute-Dienstkonto für den Build verwendet wird
3. Konfigurieren Sie ein neues Dienstkonto mit Berechtigungen für den Build.
4. Verwenden Sie das konfigurierte Dienstkonto für den Build.

Verhindert, dass das alte Cloud Build-Dienstkonto für Builds verwendet wird

Warnung: Dadurch werden alle Bereitstellungen vorübergehend unterbrochen, bis Sie ein neues Dienstkonto zuweisen.

Sie können prüfen, ob für Ihr Projekt das alte Cloud Build-Dienstkonto verwendet wird, indem Sie sich die Details des Builds Ihrer Funktion ansehen. Das Standarddienstkonto für die Builds hat das folgende Format:

[e-mail].

Sie können die Verwendung dieses Dienstkontos erzwingen, indem Sie die Einschränkung der Organisationsrichtlinie cloudbuild.useBuildServiceAccount auf Not Enforced setzen. Alternativ können Sie alle Rollen gewähren, um den Zugriff auf Google Cloud-Ressourcen einzuschränken.

Verhindert, dass das Standarddienstkonto von Compute für den Build verwendet wird

Warnung: Dadurch werden alle Bereitstellungen vorübergehend unterbrochen, bis Sie ein neues Dienstkonto zuweisen.

Das Standard-Compute-Dienstkonto hat das Format [e-mail]. Sie können festlegen, dass sie nicht als Standard für den Build verwendet wird, indem Sie die Organisationsrichtlinie cloudbuild.useComputeServiceAccount auf Not Enforced setzen. Alternativ können Sie dieses Dienstkonto deaktivieren, damit es nicht zum Zugriff auf Google Cloud -Ressourcen verwendet wird.

Dienstkonto für das Erstellen von Funktionen angeben

Im Rahmen der Konfiguration einer Funktion kann bei der Bereitstellung der Funktion ein Build-Dienstkonto angegeben werden. Wenn die Verwendung des alten Cloud Build-Dienstkontos und des Standard-Compute-Dienstkontos für den Build verhindert wird, muss ein Build-Dienstkonto angegeben werden, um eine Funktion bereitzustellen.

Informationen zum Konfigurieren und Verwenden eines Build-Dienstkontos für Ihre Funktion finden Sie unter Benutzerdefiniertes Dienstkonto für Cloud Build.