App Hosting und seine Funktionsweise

App Hosting verarbeitet eine komplexe Reihe von Hintergrundaufgaben, um die Bereitstellung Ihrer App zu vereinfachen. Auf dieser Seite werden die wichtigsten Teile dieses Aufgabenflusses beschrieben. Außerdem finden Sie Informationen zu Punkten, an denen Sie den Ablauf je nach den Anforderungen Ihrer App anpassen können.

Wichtige Begriffe und Definitionen

Um die Details des App Hosting-Workflows zu verstehen, ist es hilfreich, einige Begriffe genau zu definieren. Hier sind die wichtigsten Begriffe:

  • Backend: Die Sammlung verwalteter Ressourcen, die App Hosting zum Erstellen und Ausführen Ihrer Webanwendung erstellt.
  • Build: Eine bestimmte Version Ihrer App, die in der Regel mit einem Git-Commit verknüpft ist. Der Prozess zum Erstellen eines Builds umfasst zahlreiche Teilprozesse, insbesondere das Erstellen Ihrer App in Cloud Build und das Bereitstellen einer Version (zunächst wird 0% des Traffics gesendet, bis die Version eingeführt wird) in Cloud Run.
  • Roll-out: Ein Build wird so konfiguriert, dass Traffic aktiv ausgeliefert wird. Wenn das automatische Triggern durch einen Git-Commit erfolgt, erstellt App Hosting zuerst einen Build mit Ihrem Live-Branch und dann ein Roll-out, um Live-Traffic darauf zu leiten.
  • Live-Branch: Der Branch Ihres GitHub-Repositories, der auf Ihre Live-URL bereitgestellt wird. Häufig ist es der Branch, in den Feature- oder Entwicklungszweige zusammengeführt werden.

Google Cloud und App Hosting-Architektur

App Hosting orchestriert eine Reihe von Google Cloud-Produkten, damit Sie Ihre Webanwendung bereitstellen, ausführen und überwachen können. Apps werden mit Cloud Build erstellt, auf Cloud Run bereitgestellt und in Cloud CDN im Cache gespeichert. Integrierte Dienste wie Cloud Secret Manager sorgen für die Sicherheit Ihrer API-Schlüssel.

Ein Diagramm der auf dieser Seite beschriebenen Architektur.

  1. Wenn ein Commit an Ihren Live-Branch gepusht wird, sendet Google Cloud Developer Connect ein Ereignis an Firebase App Hosting.
  2. Als Reaktion auf dieses Ereignis erstellt Firebase App Hosting einen neuen Build für das mit dem Repository verbundene Backend.
    1. Zuerst erstellt Firebase App Hosting einen neuen Cloud Build-Build für Ihren Commit. Bei dieser Aufgabe wird anhand von Google Cloud Buildpacks ermittelt, welches Framework in Ihrer Anwendung verwendet wird, um einen Container und eine Konfiguration zu erstellen, die zu Ihrer Anwendung passt (einschließlich Umgebungsvariablen, Geheimnisse, Mindest- oder Maximalinstanzen, Speicher für Parallelität, CPU und VPC-Konfiguration). Weitere Informationen finden Sie im App Hosting-Buildprozess.
    2. Wenn der Cloud Build-Job abgeschlossen ist, wird Ihr Container in einem Artifact Registry-Repository für Firebase App Hosting gespeichert. Firebase App Hosting fügt dann einem Cloud Run-Dienst mithilfe Ihres Images und Ihrer Konfiguration eine neue Cloud Run-Version hinzu.
  3. Sobald die Cloud Run-Version fertig ist und als fehlerfrei bestätigt wurde, ändert Firebase App Hosting die Traffickonfiguration so, dass alle neuen Anfragen an die neue Cloud Run-Version weitergeleitet werden. An diesem Punkt ist das Roll-out abgeschlossen.
  4. Wenn eine Anfrage an eine Website gesendet wird, die auf Firebase App Hosting gehostet wird, wird die Anfrage vom Google Cloud Load Balancer mit aktiviertem Cloud CDN verarbeitet. Nicht im Cache gespeicherte Anfragen werden an Ihren Cloud Run-Dienst gesendet. Eine Anleitung zur Leistungsoptimierung mit Cloud CDN finden Sie unter App-Inhalte im Cache speichern.

Framework-Integration

App Hosting bietet vorkonfigurierte Unterstützung für das Erstellen und Bereitstellen von Webanwendungen, die in den folgenden Frameworks entwickelt wurden:

  • Next.js 13.5.x und höher
  • Angular 18.2.x und höher

Weitere Informationen zu bestimmten Versionen und Supportstufen finden Sie in den Supportzeitplänen.

Neben Next.js und Angular unterstützt App Hosting auch jedes Web-Framework, das eine Build-Ausgabe bereitstellen kann, die unserer Ausgabe-Bundle-Spezifikation entspricht. Weitere Informationen zu Frameworks, Framework-Adaptern und zugehörigen Tools, die von App Hosting unterstützt werden, finden Sie unter Frameworks und Tools für App Hosting.

So funktioniert die App Hosting-Repository-Integration

Die wichtige Verbindung zwischen Ihrem GitHub-Repository und dem App Hosting-Backend wird von Developer Connect verwaltet, der Konnektivitätsplattform von Google Cloud für externe DevOps-Tools. Beim Erstellen eines App Hosting-Backends werden Sie durch den UI-Workflow von Developer Connect durch die Installation der Firebase-GitHub-App geführt. Die wichtigsten Schritte in diesem Prozess sind:

  1. Sie gewähren Developer Connect die Rolle Secret Manager Admin. So können Anmeldedaten sicher als „Secrets“ im Cloud Secret Manager gespeichert werden.
  2. Sie autorisieren die Firebase GitHub-App, auf Ihr GitHub-Repository zuzugreifen. Möglicherweise benötigen Sie zusätzliche GitHub-Berechtigungen, um auf das richtige Repository zuzugreifen.
  3. Developer Connect speichert ein spezielles GitHub-Autorisierungstoken im Secret Manager-Repository Ihres Projekts. Ändern oder löschen Sie dieses Token nicht.

Außerdem ist App Hosting in die GitHub Checks API eingebunden, um eine Prüfung für Roll-outs bereitzustellen. So können Sie den Status Ihres Roll-outs in GitHub prüfen und bei Fehlern den Bereitstellungsprozess debuggen.

Einbindung in Firebase und andere Google-Dienste

Mit App Hosting werden sowohl Ihre Build- als auch Ihre Laufzeitumgebung eingerichtet, damit Sie das Firebase Admin SDK mit Standardanmeldedaten für Google-Anwendungen initialisieren können. So kann Ihr Backend sowohl während der Build- als auch der Laufzeit mit anderen Firebase-Produkten kommunizieren. Weitere Informationen zum Initialisieren Ihrer App und zu anderen Firebase SDK-bezogenen Themen finden Sie unter Firebase SDKs in Ihre Webanwendung einbinden.

App Hosting Standorte

App Hosting erstellt Ihre Back-End-Ressourcen an einem bestimmten Standort, der als primäre Region bezeichnet wird. App Hosting wird zwar für eine schnelle Bereitstellung in ein globales CDN eingebunden, aber nicht im Cache gespeicherte Inhalte werden aus der primären Region Ihrer App bereitgestellt. Diese Flexibilität beim Speicherort Ihrer Webanwendung bietet wichtige Vorteile:

  • Verbesserte Leistung und geringere Latenz, da die Daten geografisch näher an den Nutzern liegen.
  • Ein schwerwiegender Ausfall von App Hosting in einer Region hat keine Auswirkungen auf Web-Apps, die in anderen Regionen bereitgestellt werden.

Sie können eine dieser Regionen auswählen, wenn Sie ein App Hosting-Backend über die Console oder die Firebase-Befehlszeile erstellen:

  • us-central1 (Iowa)
  • asia-east1 (Taiwan)
  • europe-west4 (Niederlande)

Das App Hosting-Backend-Dienstkonto

Während des Builds und zur Laufzeit authentifiziert sich Ihr App Hosting-Backend mit einem Dienstkonto bei anderen Google-Diensten. Ein Standarddienstkonto für diese Zwecke wird erstellt, wenn Sie App Hosting zum ersten Mal in einem Firebase-Projekt aktivieren:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

Dieses Dienstkonto gilt standardmäßig für alle Backends und hat eine minimale Anzahl von Berechtigungen, mit denen Sie Ihre App erstellen, ausführen und überwachen können. Außerdem ist es berechtigt, das Admin SDK mit Standardanmeldedaten für Anwendungen zu authentifizieren, um Vorgänge wie das Laden von Daten aus Cloud Firestore auszuführen. Weitere Informationen finden Sie unter Firebase-App HostingRollen.

Wenn Ihre App entweder beim Build oder über ein laufendes Backend mit zusätzlichen Google-Diensten interagieren muss, können Sie das Standarddienstkonto anpassen, indem Sie Rollen hinzufügen. Wenn Ihre App beispielsweise Berechtigungen für Vertex AI benötigt, müssen Sie möglicherweise roles/aiplatform.user oder eine ähnliche Rolle hinzufügen.