Übersicht: Build-Prozess

In diesem Leitfaden finden Sie eine Übersicht über den Buildprozess für Funktionen, die mit dem Befehl gcloud functions bereitgestellt wurden. Weitere Informationen zum Buildprozess für Funktionen, die mit dem Befehl gcloud run bereitgestellt werden, finden Sie unter:

• Cloud Run in Containern erstellen
• Build-Dienstkonto festlegen
• Build-Worker-Pools festlegen

Wenn Sie den Quellcode Ihrer Funktion mit dem Befehl gcloud functions deploy 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.

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 erstellen, wird ein Upload-Bucket erstellt, in dem Ihr Quellcode gespeichert wird. Dieser Upload-Bucket heißt gcf-v2-uploads-PROJECT_NUMBER-REGION.cloudfunctions.appspot.com.
  • 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.

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.

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

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.

Image-Registry

Artifact Registry wird verwendet, 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-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.

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:

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

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.

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

1. Erstellen Sie Ihren privaten Worker-Pool. Weitere Informationen finden Sie unter 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 Functions-Dienst-Agent-Dienstkonto (service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com) 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:service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
       --role roles/cloudbuild.workerPoolUser

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

4. 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...]

   Ersetzen Sie FUNCTION_NAME durch den Namen der Funktion, RUNTIME durch die von Ihnen verwendete Laufzeit und PRIVATE_POOL_NAME durch den Namen 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...]

Ersetzen Sie FUNCTION_NAME durch den Namen der Funktion und RUNTIME durch die von Ihnen verwendete Laufzeit.

Build mit einem benutzerdefinierten Dienstkonto sichern

Der Quellcode Ihrer Funktion wird zur Containerisierung an Cloud Build gesendet. Die containerisierte Funktion wird in Artifact Registry gespeichert und als Dienst in Cloud Run bereitgestellt. Cloud Run-Funktionen nutzen Cloud Build beim Erstellen und Bereitstellen Ihrer Cloud Run-Funktion. Standardmäßig verwendet Cloud Run-Funktionen das Cloud Build-Standarddienstkonto beim Ausführen des Builds als Hauptkonto. Seit Juli 2024 hat Cloud Build das Standardverhalten für die Verwendung von Dienstkonten durch Cloud Build in neuen Projekten geändert. Aufgrund dieser Änderung verwenden neue Projekte, die Funktionen zum ersten Mal bereitstellen, möglicherweise ein Cloud Build-Standarddienstkonto mit unzureichenden Berechtigungen zum Erstellen einer Funktion.

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:

• Verhindern, dass das alte Cloud Build-Dienstkonto für den Build verwendet wird
• Verhindern, dass das Standard-Compute-Dienstkonto für den Build verwendet wird
• Konfigurieren Sie ein neues Dienstkonto mit Berechtigungen für den Build.

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

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:

PROJECT_NUMBER@cloudbuild.gserviceaccount.com.

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

Das Standard-Compute-Dienstkonto hat das Format PROJECT_NUMBER-compute@developer.gserviceaccount.com. 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, müssen Sie ein Build-Dienstkonto angeben, um eine Funktion bereitzustellen, wie in diesem Abschnitt beschrieben.

Wenn Sie von den unter Änderung des Cloud Build-Dienstkontos beschriebenen Änderungen betroffen sind, haben Sie folgende Möglichkeiten:

• Lesen Sie die Cloud Build-Anleitung zu Änderungen am Standarddienstkonto und deaktivieren Sie diese Änderungen.

• Fügen Sie dem Compute Engine-Standarddienstkonto die Rolle "Cloud Build-Konto" (roles/cloudbuild.builds.builder) hinzu.

• Erstellen Sie ein benutzerdefiniertes Cloud Build-Dienstkonto für Funktionsbereitstellungen.

Im Folgenden finden Sie einige Szenarien, in denen Sie möglicherweise ein anderes Dienstkonto angeben möchten, das beim Erstellen Ihrer Funktion von Cloud Build verwendet werden soll:

• Sie möchten mehr Kontrolle darüber haben, welche Dienstkonten Ihrem VPC-SC-Perimeter hinzugefügt werden sollen.

• Sie möchten, dass Cloud Build mit anderen Berechtigungen als dem Standarddienstkonto ausgeführt wird, ohne jede Berechtigung einzeln widerrufen zu müssen.

• Sie möchten detaillierte Cloud Build-Berechtigungen speziell für Ihre Funktionen festlegen und kein Cloud Build-Dienstkonto freigeben, das für andere Zwecke optimiert ist.

• Ihre Organisation hat die Verwendung des Standarddienstkontos deaktiviert.

In den folgenden Abschnitten erfahren Sie, wie Sie ein benutzerdefiniertes Cloud Build-Dienstkonto für Funktionsbereitstellungen erstellen.

Dienstkonto erstellen

Erstellen Sie ein neues Dienstkonto, wie unter Dienstkonto erstellen beschrieben.

Berechtigungen gewähren

Das von Ihnen verwendete Dienstkonto benötigt die folgenden Rollen:

• roles/logging.logWriter— Erforderlich zum Erstellen von Build-Logs in Cloud Logging
• roles/artifactregistry.writer— Erforderlich zum Speichern von Build-Images in Artifact Registry. Für das Standardverhalten benötigt das Dienstkonto Zugriff auf die Repositories „gcf-artifacts“ und „cloud-run-source-deploy“. Der Zugriff auf die Repositories kann in der IAM-Richtlinie des Repositories festgelegt werden. Alternativ können Sie Ihr eigenes Artefakt-Repository über das Feld dockerRepository angeben.
• roles/storage.objectViewer— Erforderlich zum Abrufen der Funktionsquelle aus dem Cloud Storage-Bucket und zum Speichern von Build-Images in Container Registry. Für das Standardverhalten benötigt das Dienstkonto Zugriff auf die Bucket „run-sources-*“, „gcf-v2-sources-*“ und „gcf-v2-uploads-*“. Dazu können Sie der Rollengewährung eine IAM-Bedingung hinzufügen, z. B.: (resource.type == "storage.googleapis.com/Object" && (resource.name.startsWith("projects/_/buckets/gcf-v2-sources-") || resource.name.startsWith("projects/_/buckets/gcf-v2-uploads-") || resource.name.startsWith("projects/_/buckets/run-sources-")))

Gewähren Sie die folgenden Rollen mithilfe der Google Cloud CLI oder verwenden Sie die Google Cloud Console.

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
    --role=roles/logging.logWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
--role=roles/artifactregistry.writer

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
--role=roles/storage.objectViewer

Ersetzen Sie Folgendes:

• PROJECT_ID: Ihre Google Cloud Projekt-ID.
• SA_EMAIL: Die E-Mail-Adresse Ihres Dienstkontos.

Hinweise zu VPC Service Controls

Wenn Sie einen VPC Service Controls-Perimeter haben, der sowohl Ihr Projekt als auch die Cloud Run Functions API schützt, und das Compute Engine-Standarddienstkonto als Cloud Build-Dienstkonto für Cloud Run Functions verwenden, müssen Sie die folgenden Ingress-Regeln erstellen:

• Gewähren Sie dem Compute Engine-Standarddienstkonto Zugriff auf alle Methoden der Cloud Storage API und der Cloud Logging API.
• Gewähren Sie dem Dienstkonto service-[PROJECT_NUMBER]@gcf-admin-robot.iam.gserviceaccount.com den Zugriff auf alle Methoden der Cloud Storage API und der Cloud Logging API.

Funktion mit einem benutzerdefinierten Dienstkonto bereitstellen

Wenn Sie ein vom Nutzer erstelltes Dienstkonto übergeben möchten, das von Cloud Build beim Bereitstellen Ihrer Funktion verwendet werden soll, führen Sie den folgenden gcloud-Befehl aus:

• Das Flag --build-service-account gibt ein IAM-Dienstkonto an, dessen Anmeldedaten für den Build-Schritt verwendet werden. Wenn kein benutzerdefiniertes Dienstkonto angegeben ist, verwendet die Funktion das Standarddienstkonto des Projekts für Cloud Build.
• Optional können Sie einen privaten Pool verwenden, den Sie mit dem Flag --build-worker-pool angeben.

gcloud functions deploy FUNCTION_NAME \
   --gen2 \
   --region=REGION \
   --project=PROJECT_ID \
   --runtime=RUNTIME \
   --entry-point=CODE_ENTRYPOINT \
   --build-service-account=projects/PROJECT_ID/serviceAccounts/SA_EMAIL \
   --memory=256Mi \
   --trigger-http \
   --source=.

Ersetzen Sie dabei Folgendes:

• FUNCTION_NAME: Der Name, unter dem Sie die Funktion bereitgestellt haben.
• REGION: Der Name der Google Cloud -Region, in der Sie die Funktion bereitstellen möchten (z. B. us-west1).
• PROJECT_ID: Ihre Google Cloud Projekt-ID.
• RUNTIME: Die Laufzeit-ID einer unterstützten Laufzeitversion, um Ihre Funktion auszuführen, z. B. nodejs18.
• CODE_ENTRYPOINT: Der Einstiegspunkt zur Funktion in Ihrem Quellcode. Dies ist der Code, der beim Ausführen der Funktion ausgeführt wird.
• SA_EMAIL: Die E-Mail-Adresse Ihres Dienstkontos.

Dem Cloud Build-Dienstkonto Zugriff auf den Perimeter der VPC Service Controls gewähren

Cloud Run Functions verwendet Cloud Build, um Ihren Quellcode in einem ausführbaren Container zu erstellen. Wenn Sie Cloud Run Functions mit VPC Service Controls verwenden möchten, müssen Sie Ihr Cloud Build-Dienstkonto (Standard- oder benutzerdefiniertes) so konfigurieren, dass es Zugriff auf Ihren Dienstperimeter hat.

Nach dem Namen des Dienstkontos suchen

Wenn Sie das standardmäßige Cloud Build-Dienstkonto verwenden, können Sie den Namen so ermitteln:

1. Verwenden Sie die IAM-Seite in der Google Cloud Console, um das Cloud Build-Dienstkonto zu finden.

   OpenIAM

2. Prüfen Sie, ob im Drop-down-Menü des Projekts das richtige Projekt ausgewählt ist.

3. Suchen Sie nach cloudbuild.gserviceaccount.com. Die E-Mail-Adresse im Format PROJECT_NUMBER@cloudbuild.gserviceaccount.com ist der Name des Dienstkontos.

Wenn Sie ein benutzerdefiniertes Cloud Build-Dienstkonto haben, verwenden Sie stattdessen diesen Namen.

Dienstkonto Zugriff auf den Dienstperimeter gewähren

Sobald Sie den Namen des Dienstkontos haben, folgen Sie der Anleitung unter Zugriff nach Nutzern oder Dienstkonten beschränken, um eine Zugriffsebene für das Dienstkonto zu erstellen. Folgen Sie dann der Anleitung unter Zugriffsebene zu einem vorhandenen Perimeter hinzufügen, um Ihrem Dienstperimeter eine Zugriffsebene hinzuzufügen.