Übersicht: Build-Prozess

Wenn Sie den Quellcode Ihrer Funktion in Cloud Functions bereitstellen, wird diese Quelle in einem Cloud Storage-Bucket gespeichert. Cloud Build hinterlegt den Code anschließend automatisch in einem Container-Image und überträgt dieses per Push in eine Image-Registry. Cloud Functions greift auf dieses Image zu, wenn es zum Ausführen der Funktion den Container ausführen muss.

Hinweis: Container Registry wurde verworfen und wird eingestellt. Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden standardmäßig neue gcr.io-Repositories in Artifact Registry gehostet. Nach 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 direkt in Ihrem Projekt verwendet und das Quellcodeverzeichnis für Ihre Funktionen wird in einem Bucket in Ihrem Projekt gespeichert. Wichtige Hinweise:

  • Wenn Sie die Standardverschlüsselung verwenden, heißt dieser Bucket gcf-sources-PROJECT_NUMBER-REGION.
  • Wenn Sie Ihre Daten mit CMEK schützen, heißt der Bucket gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.
  • Für den Bucket gibt es keine Aufbewahrungsdauer.

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ü und folgen Sie den Anweisungen, 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. Zum Aufrufen der Logs, die über Cloud Logging verfügbar sind, können Sie entweder die gcloud CLI oder die Google Cloud Console verwenden.

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

1. Klicken Sie im Fenster Cloud Functions – Übersicht auf den Namen der Funktion, die Sie prüfen möchten.
2. Klicken Sie auf den Tab Details.
3. Klicken Sie im Bereich Allgemeine Informationen auf den Link Container-Build-Log, um den Bereich Log-Explorer zu öffnen.
4. Klicken Sie auf eine Zeile, um die Details dieses Build-Logeintrags aufzurufen. Wenn es sich um einen Fehlereintrag handelt, der mit einer Datei verknüpft ist, enthalten diese Details den Namen, die Zeile und die Spalte der Datei.

Image-Registry

Cloud Functions (2nd gen) verwendet ausschließlich Artifact Registry zum Speichern der aus Ihrem Funktionsquellcode erstellten Images. Bilder werden in einem Repository mit dem Namen REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts gespeichert.

Cloud Functions (1. Generation) verwendet standardmäßig Artifact Registry. Container Registry wird verworfen.

Ihre Artifact Registry muss sich im selben Projekt wie Ihre Funktion befinden. Sie können eine Artifact Registry-basierte Funktion erstellen oder aktualisieren:

gcloud

Führen Sie für Vom Kunden verwaltete Artifact Registry den folgenden Befehl aus:

gcloud functions deploy FUNCTION \
--docker-repository=REPOSITORY
[FLAGS...]

Dabei gilt:

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

Verwenden Sie für von Google verwaltete Artifact Registry Folgendes:

gcloud functions deploy FUNCTION \
--docker-registry=artifact-registry
[FLAGS...]

Google Cloud Console

1. Rufen Sie die Seite "Cloud Functions" in der Google Cloud Console auf:
   Zur Seite "Cloud Functions"

2. Klicken Sie auf den Namen der Funktion, für die Sie Artifact Registry verwenden möchten.

3. Klicken Sie auf Bearbeiten.

4. Klicken Sie auf Laufzeit, Build..., um die erweiterten Konfigurationsoptionen zu maximieren.

5. Klicken Sie in der Menüleiste auf Sicherheit und Image-Repository, um den Tab „Sicherheit“ zu öffnen.

6. Wählen Sie unter Image-Repository eine der folgenden Optionen aus, je nachdem, welchen Typ von Artifact Registry Sie verwenden:

   • Vom Kunden verwaltete Artifact Registry. Verwenden Sie diese Option, wenn Sie ein eigenes Docker-Repository einrichten.
   • Von Google verwaltete Artifact Registry Verwenden Sie diese Option, wenn Sie ein von Google verwaltetes Docker-Repository verwenden möchten, anstatt ein eigenes einzurichten.

7. Verwenden Sie für die vom Kunden verwaltete Artifact Registry das Artifact Registry-Drop-down, um das gewünschte Artifact Registry-Repository auszuwählen, oder folgen Sie den Eingabeaufforderungen und erstellen Sie ein neues.

8. Klicken Sie auf Next (Weiter).

9. Klicken Sie auf Bereitstellen.

Ausführliche Preisinformationen finden Sie unter Cloud 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 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.

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

gcloud

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.

Google Cloud Console

1. Wählen Sie auf der Cloud Functions – Übersicht die Option Funktion erstellen.

2. Klicken Sie im Abschnit Laufzeit, Build... auf den Tab Build und geben Sie den vollständigen Ressourcennamen Ihres privaten Pools in das Textfeld Worker-Pools erstellen ein.

Weitere Informationen finden Sie unter Builds in einem privaten Pool ausführen.