Der Build-Prozess für App Hosting

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

Der Build-Prozess umfasst die folgenden wichtigen Phasen:

  1. ubuntu: Workspace-Initialisierung.

  2. preparer: Erfasst den Quellcode und die Konfiguration Ihrer Anwendung.

  3. pre-buildpack: Bereitet die Buildpack-Umgebung vor.

  4. build: Installiert Abhängigkeiten und erstellt Ihre Anwendung.

  5. Publisher: Schließt die Produktion des Cloud Run-Containers ab.

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 Ubuntu-Build-Schritt. Damit wird der Build-Arbeitsbereich initialisiert und dafür gesorgt, dass die richtigen Dateiberechtigungen für die Verzeichnisse festgelegt werden, die von den nachfolgenden Build-Schritten verwendet werden.

Vorbereiter

In dieser Phase wird die Logik vor dem Build ausgeführt. 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 muss ein Shim ausgeführt werden, der die im vorherigen Schritt vorbereiteten Konfigurationen und Umgebungsvariablen in das von den CNB-Tools erwartete Format übersetzt.

Entwicklung

Dies ist der Kern des Build-Prozesses. Er ist für die Generierung eines ausführbaren Container-Images und einer bundle.yaml-Datei zuständig, in der Ihre Build-Konfiguration definiert ist. Dabei werden die Cloud Native Buildpacks und die Binärdatei lifecycle creator verwendet, um die Anwendung effizient zu verpacken. Weitere Informationen zur Datei bundle.yaml finden Sie auf GitHub.

Buildpacks sind dafür verantwortlich, 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: Sorgt dafür, 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 die Verarbeitung verschiedener 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 übertragen, 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 Anwendungsquellcode extrahiert wurden, sowie das Build-Container-Image verpackt und an das App Hosting-Backend gesendet. Das App Hosting-Backend verwendet diese Informationen dann, um Cloud Run mit den richtigen Konfigurationen einzurichten.

Bereinigungsrichtlinie für Builds

Firebase App Hosting erzwingt eine Richtlinie für die automatische 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, werden in App Hosting außerdem die fünf zuletzt erfolgreichen Builds und Roll-outs unabhängig von ihrem Alter beibehalten.

App Hosting löscht oder entfernt niemals einen Build, der derzeit in Ihrem aktiven Traffic-Split enthalten ist oder mit einem laufenden Roll-out verknüpft ist.

Wenn ältere Builds diese Aufbewahrungslimits überschreiten, wird ihr interner Status auf EXPIRED aktualisiert. Ein sofortiges Rollback ist für EXPIRED-Builds nicht möglich. Die Option, ein Rollback auf diese Builds durchzuführen, wird aus der Firebase-Konsole 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 automatische Rollouts ausgelöst werden. Automatische Roll-outs verwalten

Weitere Informationen

Der gesamte App Hosting-Build-Prozess ist Open Source.