Cloud Functions-Images erstellen

Übersicht

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 an Container Registry. Cloud Functions greift auf dieses Image zu, wenn es zum Ausführen der Funktion den Container ausführen muss.

Das Erstellen des Images erfolgt komplett automatisch und erfordert keine direkte Eingabe von Ihnen. Es gibt jedoch einen geringfügigen Unterschied zwischen dem Build-Prozess für die älteren Node 8- und Go 1.11-Laufzeiten und dem aktuellen Build-Prozess für die Java 11-, Python 3.7-, Python 3.8-, Node.js 10- und Go 1.13-Laufzeiten.

Node.js 8- und Go 1.11-Laufzeiten

Bei älteren Laufzeiten findet der Build-Prozess nicht in Ihrem Nutzerprojekt statt, sondern in einem zugehörigen Projekt, das als Mandantenprojekt bezeichnet wird. Durch das Ausführen des Builds in einem Mandantenprojekt wurden einige Probleme gelöst, die mit diesen Laufzeiten verbunden sind. Es haben sich aber auch neue Probleme ergeben:

  • Da der Build nicht in Ihrem Projekt erfolgt, haben Sie keinen Zugriff auf die Build-Logs, um alle Build-Probleme durchzugehen, die möglicherweise auftreten.

  • Dieser Prozess erfordert ein internes tägliches Kontingent für die Build-Dauer, das unter bestimmten, häufig auftretenden Umständen aufgebraucht werden kann. Dadurch wird möglicherweise Ihre Fähigkeit beeinträchtigt, neuen Quellcode bereitzustellen, bis das Kontingent erneuert wird.

  • Sie haben keinen Zugriff auf die Container Registry, in der das Container-Image der Funktion gespeichert ist. Sie können also die verfügbaren Images nicht sehen.

Neuere Laufzeiten

Für neuere Laufzeiten wie Java 11 und höher, Python 3.7 und höher, Node.js 10 und höher sowie Go 1.13 und höher werden nun alle im Build-Prozess verwendeten Ressourcen in Ihrem eigenen Nutzerprojekt ausgeführt, nicht im Mandantenprojekt. Das ist jetzt der Standardprozess.

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 Container Registry gespeichert.

  • Da Cloud Storage direkt in Ihrem Projekt verwendet wird, ist das Quellcodeverzeichnis für Ihre Funktionen in einem Bucket mit dem Namen gcf-sources-<PROJECT_NUMBER>-<REGION> sichtbar.

Eigenschaften des Standardprozesses

Aufgrund dieser Änderung haben alle Laufzeiten, die den Standardprozess nutzen, diese Eigenschaften:

  • Die Cloud Build API muss für Ihr Projekt aktiviert sein. Bei allen Projekten, die nach dem 17. August 2020 erstellt wurden, wird dies automatisch eingerichtet. Bei anderen Projekten muss die API allerdings manuell aktiviert werden.

    Klicken Sie auf den obigen Link, wählen Sie Ihr Projekt aus dem Drop-down-Menü aus und klicken auf Weiter, um die API 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 Container Registry finden Sie auf der Preisseite.

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

Auf Build-Image-Logs zugreifen

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-Befehlszeile oder die 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.
    

Cloud Console

  1. Klicken Sie im Bildschirm Funktionen auf den Namen der Funktion, an der Sie interessiert sind. Die Seite Funktionsdetails wird geöffnet.

  2. Scrollen Sie nach unten, bis Sie den Abschnitt Container-Build erreichen. Wenn der Build fehlerfrei verlaufen ist, wird ein Link angezeigt, über den Sie das Build-Log aufrufen können. Wenn Ihr Build wie unten gezeigt Fehler aufweist, werden sie im Abschnitt Container-Build inline angezeigt. Klicken Sie auf Weitere Informationen, um direkt das Build-Log aufzurufen.

    Screenshot mit der Ausgabe für den Bereich Container-Build

  3. Der Bildschirm Logbetrachter wird geöffnet. Klicken Sie auf den Eintrag, der Sie interessiert.

  4. Der vollständige Build-Logeintrag wird geöffnet. Darin sehen Sie die betroffene Datei, eine Beschreibung des Fehlers – in diesem Fall eine fehlende Klammer in pom.xml – sowie die Zeile und die Spalte des Fehlers.

    Screenshot mit Build-Logeintrag