Der Build-Prozess für App Hosting

Firebase App Hosting verwendet Cloud Build, um den Quellcode Ihrer Anwendung in ein Containerformat umzuwandeln, das für die Bereitstellung in Cloud Run geeignet ist.

Der Build-Prozess umfasst die folgenden Hauptphasen:

  1. ubuntu: Arbeitsbereich initialisieren

  2. preparer: Anwendungsquellcode und -konfiguration erfassen

  3. pre-buildpack: Buildpack-Umgebung vorbereiten

  4. build: Abhängigkeiten installieren und Anwendung erstellen

  5. publisher: ProduktionsCloud Runcontainer fertigstellen

Diese fünf Schritte entsprechen direkt den Build-Schritten, die in Cloud Build in der Google Cloud Konsole angezeigt werden:

Ein Screenshot einer Google Cloud Console-Ansicht von Cloud Build-Schritten

Arbeitsbereich initialisieren

Diese Phase entspricht dem Build-Schritt „ubuntu“. Dabei wird der Build-Arbeitsbereich initialisiert und die richtigen Dateiberechtigungen für die Verzeichnisse festgelegt, die von den nachfolgenden Build-Schritten verwendet werden.

Vorbereiter

Diese Phase ist für die Vor-Build-Logik zuständig. Dabei werden nutzerdefinierte Umgebungsvariablen gelesen, bereinigt und geschrieben. Außerdem werden alle in der Datei apphosting.yaml angegebenen Secrets dereferenziert und angepinnt.

Pre-buildpack

In diesem Schritt wird die Umgebung für den Cloud Native Buildpacks Lebenszyklus vorbereitet. Dazu wird ein Shim ausgeführt, der die in der vorherigen Phase vorbereiteten Konfigurationen und Umgebungsvariablen in das von den CNB-Tools erwartete Format übersetzt.

Build

Dies ist der Kern des Build-Prozesses. Hier werden ein ausführbares Container-Image und eine bundle.yaml-Datei generiert, in der die Build-Konfiguration definiert ist. Dabei werden die Cloud Native Buildpacks und die binäre Datei des Lebenszyklus-Erstellers verwendet, um die Anwendung effizient zu packen. Weitere Informationen zur Datei bundle.yaml finden Sie auf GitHub.

Buildpacks sind dafür zuständig, den Quellcode Ihrer Anwendung in produktionsfertige Container-Images umzuwandeln. Firebase App Hosting verknüpft mehrere Buildpacks, um den Build-Prozess abzuschließen:

  1. Runtime Buildpack: Stellt sicher, dass alle erforderlichen Komponenten zum Ausführen einer einfachen Node.js-Anwendung enthalten sind und Abhängigkeiten installiert werden.
  2. Monorepo Buildpack: Konfiguriert nachfolgende Buildpacks für verschiedene Monorepo-Szenarien.

  3. Framework Buildpack: Installiert den richtigen Framework-Adapter (z. B. Angular oder Next.js) und bereitet nachfolgende Buildpacks vor.

    Framework-Adapter sind dafür zuständig, den produktionsreifen Build Befehl auszuführen und alle relevanten frameworkspezifischen Konfigurationswerte in ein Standardformat zu konvertieren, das von App Hosting gelesen werden kann.

  4. Package Manager Buildpack: Führt die Installation von Abhängigkeiten aus und erstellt die App mit npm, yarn oder pnpm.

  5. Output Bundle Buildpack: Definiert den Ausführungsbefehl und bereitet das Ausgabebundle für die Ausführung vor.

Publisher

In dieser letzten Phase werden alle Informationen, die aus dem Quellcode der Anwendung extrahiert wurden, sowie das Build-Container-Image gepackt und an das App Hosting Back-End gesendet. Das App Hosting Back-End verwendet diese Informationen dann, um Cloud Run mit den entsprechenden Konfigurationen einzurichten.

Bereinigungsrichtlinie für Builds

Firebase App Hosting erzwingt eine automatische Richtlinie zur Aufbewahrung und Bereinigung von Builds. Gemäß dieser Richtlinie behält App Hosting Ihre erfolgreichen Builds und die zugehörigen Cloud Run Revisionen der letzten 14 Tage bei. Damit Sie immer einen Build haben, auf den Sie einen Rollback durchführen können, behält App Hosting außerdem die fünf zuletzt erfolgreichen Builds und Rollouts unabhängig von ihrem Alter bei.

App Hosting löscht oder entfernt niemals einen Build, der sich derzeit in Ihrer aktiven Traffic-Aufteilung befindet oder mit einem laufenden Rollout verknüpft ist.

Wenn ältere Builds diese Aufbewahrungslimits überschreiten, wird ihr interner Status auf EXPIRED aktualisiert. Sie können keinen sofortigen Rollback auf einen EXPIRED Build ausführen und die Option, auf diese Builds zurückzugreifen, wird aus der Firebase Console entfernt. Stattdessen müssen Sie einen neuen Build erstellen, der auf dieselbe Quelle ausgerichtet ist (entweder ein Git-Commit, ein Container in Artifact Registry oder ein Google Cloud Storage Bucket), und diesen bereitstellen.

Eine Möglichkeit, Build-Ressourcen zu sparen, besteht darin, die Häufigkeit zu steuern, mit der Sie automatische Rollouts auslösen. Weitere Informationen finden Sie unter Automatische Rollouts verwalten.

Weitere Informationen

Der gesamte App Hosting Build-Prozess ist Open Source.