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: Produktions-Cloud Run Container 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. Sie liest, bereinigt und schreibt benutzerdefinierte Umgebungsvariablen. 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 mit der Build-Konfiguration generiert. Dabei werden die Cloud Native Buildpacks und die Binärdatei 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 die 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 führen den produktionsreifen Build Befehl aus und ordnen alle relevanten frameworkspezifischen Konfigurationswerte einem Standardformat zu, 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 aus dem Anwendungs quellcode extrahierten Informationen 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 für 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.