App Hosting wurde für eine einfache Bedienung und geringe Wartung entwickelt. Die Standardeinstellungen sind für die meisten Anwendungsfälle optimiert. Gleichzeitig bietet App Hosting Tools, mit denen Sie Backends für Ihre spezifischen Anforderungen verwalten und konfigurieren können. In diesem Leitfaden werden diese Tools und Prozesse beschrieben.
Backend konfigurieren
Für erweiterte Konfigurationen wie Umgebungsvariablen oder Laufzeiteinstellungen wie Gleichzeitigkeit, CPU- und Speicherlimits müssen Sie die Datei apphosting.yaml
im Stammverzeichnis Ihrer App erstellen und bearbeiten. Diese Datei unterstützt auch Verweise auf Secrets, die mit Cloud Secret Manager verwaltet werden. Dadurch kann sie sicher in die Versionskontrolle eingecheckt werden.
Führen Sie den folgenden Befehl aus, um apphosting.yaml
zu erstellen:
firebase init apphosting
Dadurch wird eine einfache apphosting.yaml
-Startdatei mit einer Beispielkonfiguration (mit Kommentaren) erstellt. Nach der Bearbeitung könnte eine typische apphosting.yaml
-Datei so aussehen, mit Einstellungen für den Cloud Run-Dienst des Backends, einigen Umgebungsvariablen und einigen Verweis auf Secrets, die von Cloud Secret Manager verwaltet werden:
# Settings for Cloud Run
runConfig:
minInstances: 2
maxInstances: 100
concurrency: 100
cpu: 2
memoryMiB: 1024
# Environment variables and secrets
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
- variable: API_KEY
secret: myApiKeySecret
# Same as API_KEY above but with a pinned version.
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
# Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
- variable: VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID
# Same as API_KEY above but with the long form secret reference with pinned version.
- variable: PINNED_VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID/versions/5
Im Rest dieses Leitfadens finden Sie weitere Informationen und Kontext zu diesen Beispieleinstellungen.
Cloud Run-Diensteinstellungen konfigurieren
Mit den apphosting.yaml
-Einstellungen können Sie die Bereitstellung Ihres Cloud Run-Dienstes konfigurieren. Die verfügbaren Einstellungen für den Cloud Run-Dienst finden Sie im runConfig
-Objekt:
cpu
– Anzahl der CPUs, die für jede Bereitstellungs-Instanz verwendet werden (Standardwert: 0).memoryMiB
– Arbeitsspeicher, der jeder Auslieferungsinstanz zugewiesen wird, in MiB (Standard: 512)maxInstances
– Maximale Anzahl von Containern, die gleichzeitig ausgeführt werden können (Standardwert 100, wird durch Kontingent verwaltet)minInstances
– Anzahl der Container, die immer aktiv bleiben sollen (Standard: 0).concurrency
– Maximale Anzahl von Anfragen, die jede Serving-Instanz empfangen kann (Standard: 80).
Beachten Sie die wichtige Beziehung zwischen cpu
und memoryMiB
. Der Arbeitsspeicher kann auf einen beliebigen Ganzzahlwert zwischen 128 und 32.768 festgelegt werden. Wenn Sie das Arbeitsspeicherlimit erhöhen, müssen Sie möglicherweise auch die CPU-Limits erhöhen:
- Bei mehr als 4 GiB sind mindestens 2 CPUs erforderlich
- Bei mehr als 8 GiB sind mindestens 4 CPUs erforderlich.
- Bei mehr als 16 GiB sind mindestens 6 CPUs erforderlich.
- Bei mehr als 24 GiB sind mindestens 8 CPUs erforderlich.
Der Wert von cpu
wirkt sich auch auf die Einstellungen für die Parallelität aus. Wenn Sie einen Wert unter 1 CPU festlegen, müssen Sie die Gleichzeitigkeit auf 1 festlegen. Die CPU wird dann nur während der Anfrageverarbeitung zugewiesen.
Build-Umgebung konfigurieren
Manchmal ist für den Buildprozess eine zusätzliche Konfiguration erforderlich, z. B. API-Schlüssel von Drittanbietern oder anpassbare Einstellungen. App Hosting bietet eine Umgebungskonfiguration in apphosting.yaml
, um diese Art von Daten für Ihr Projekt zu speichern und abzurufen.
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
Bei Next.js-Anwendungen können auch dotenv-Dateien mit Umgebungsvariablen mit App Hosting verwendet werden. Wir empfehlen die Verwendung von apphosting.yaml
für eine detaillierte Umgebungsvariablensteuerung mit jedem Framework.
In apphosting.yaml
können Sie mithilfe der Property availability
angeben, welche Prozesse Zugriff auf Ihre Umgebungsvariable haben. Sie können eine Umgebungsvariable so einschränken, dass sie nur für die Build-Umgebung oder nur für die Laufzeitumgebung verfügbar ist. Standardmäßig ist sie für beide verfügbar.
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
Bei Next.js-Anwendungen können Sie das Präfix NEXT_PUBLIC_
genauso wie in Ihrer dotenv-Datei verwenden, um eine Variable im Browser zugänglich zu machen.
env:
- variable: NEXT_PUBLIC_STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
Gültige Variablenschlüssel bestehen aus Buchstaben (A–Z) oder Unterstrichen. Einige Schlüssel für Umgebungsvariablen sind für die interne Verwendung reserviert. Verwenden Sie in Ihren Konfigurationsdateien keine der folgenden Schlüssel:
- Alle Variablen, die mit
X_FIREBASE_
beginnen PORT
K_SERVICE
K_REVISION
K_CONFIGURATION
Geheime Parameter speichern und darauf zugreifen
Vertrauliche Informationen wie API-Schlüssel sollten als Secrets gespeichert werden. Sie können auf Secrets in apphosting.yaml
verweisen, um zu vermeiden, dass vertrauliche Informationen in die Versionskontrolle eingecheckt werden.
Parameter vom Typ secret
sind Stringparameter, deren Wert im Cloud Secret Manager gespeichert ist.
Anstatt den Wert direkt abzuleiten, wird bei geheimen Parametern geprüft, ob sie in Cloud Secret Manager vorhanden sind, und die Werte werden während des Roll-outs geladen.
- variable: API_KEY
secret: myApiKeySecret
Secrets in Cloud Secret Manager können mehrere Versionen haben. Standardmäßig ist der Wert eines geheimen Parameters, der für dein Live-Backend verfügbar ist, an die neueste verfügbare Version des Geheimnisses angepinnt, die zum Zeitpunkt der Erstellung des Backends verfügbar war. Wenn Sie Anforderungen an die Versions- und Lebenszyklusverwaltung von Parametern haben, können Sie sie mit Cloud Secret Manager an bestimmte Versionen anpinnen. So heften Sie beispielsweise Version 5 an:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
Sie können Secrets mit dem Befehl firebase apphosting:secrets:set
in der Befehlszeile erstellen. Sie werden dann aufgefordert, die erforderlichen Berechtigungen hinzuzufügen. Bei diesem Ablauf haben Sie die Möglichkeit, die Secret-Referenz automatisch zu apphosting.yaml
hinzuzufügen.
Wenn Sie die gesamte Cloud Secret Manager-Funktionspalette nutzen möchten, können Sie stattdessen die Cloud Secret Manager-Konsole verwenden. In diesem Fall müssen Sie Ihrem App Hosting-Backend mit dem Befehl firebase
apphosting:secrets:grantaccess
Berechtigungen gewähren.
Firebase Auth-Status synchronisieren
Für Apps, die Firebase Auth verwenden, empfiehlt es sich, das Firebase Web SDK zu verwenden, um den Authentifizierungsstatus zwischen Client und Server zu synchronisieren. Dies kann durch die Implementierung von FirebaseServerApp
mit einem Service Worker vereinfacht werden. Der grundlegende Ablauf ist:
- Implementieren Sie einen Service Worker, der bei Anfragen an den Server die richtigen Header für Ihre App hinzufügt.
- Rufe die Header aus der Anfrage auf dem Server ab und konvertiere sie mit
FirebaseServerApp
in einen authentifizierten Nutzer.
Back-Ends verwalten
Befehle zur grundlegenden Verwaltung von App Hosting-Backends finden Sie in der Firebase-Befehlszeile. Einige Vorgänge sind auch in der Firebase-Konsole verfügbar. In diesem Abschnitt werden einige der gängigen Verwaltungsaufgaben beschrieben, z. B. das Erstellen und Löschen von Back-Ends.
Backend erstellen
Ein App Hosting-Backend ist die Sammlung verwalteter Ressourcen, die App Hosting zum Erstellen und Ausführen Ihrer Webanwendung erstellt. Jeder Projektinhaber kann das erste App Hosting-Backend für ein Projekt mit der Firebase Console oder der Firebase CLI erstellen. Nach dieser Ersteinrichtung können App Hosting-Administratoren auch zusätzliche Backends erstellen und verwalten. Weitere Informationen finden Sie unter Firebase App Hosting IAM-Rollen.
Firebase Console: Wählen Sie im Menü Build die Option App-Hosting und dann Jetzt starten aus.
Befehlszeile: (Version 13.15.4 oder höher) Führen Sie zum Erstellen eines Backends den folgenden Befehl im Stammverzeichnis Ihres lokalen Projektverzeichnisses aus und geben Sie als Argumente die projectID und die bevorzugte Region an:
firebase apphosting:backends:create --project PROJECT_ID --location us-central1
Folgen Sie sowohl in der Console als auch in der Befehlszeile der Anleitung, um Ihrem Backend einen Namen zuzuweisen, eine GitHub-Verbindung einzurichten und die folgenden grundlegenden Bereitstellungseinstellungen zu konfigurieren:
Legen Sie das Stammverzeichnis Ihrer App fest (standardmäßig
/
).Hier befindet sich normalerweise die Datei
package.json
.
Live-Zweig festlegen
Dies ist der Branch Ihres GitHub-Repositories, der auf Ihrer Live-URL bereitgestellt wird. Häufig ist es der Branch, in den Feature-Branches oder Entwicklungs-Branches zusammengeführt werden.
Automatische Roll-outs akzeptieren oder ablehnen
Automatische Roll-outs sind standardmäßig aktiviert. Nach Abschluss der Backend-Erstellung können Sie festlegen, dass Ihre App sofort auf App Hosting bereitgestellt wird.
Backend löschen
Wenn Sie ein Backend vollständig entfernen möchten, verwenden Sie zuerst die Firebase-Befehlszeile und entfernen Sie dann manuell die zugehörigen Assets. Achten Sie dabei darauf, keine Ressourcen zu löschen, die von anderen Backends oder anderen Aspekten Ihres Firebase-Projekts verwendet werden könnten.
Führen Sie den folgenden Befehl aus, um das App Hosting-Backend zu löschen: Dadurch werden alle Domains für Ihr Backend deaktiviert und der zugehörige Cloud Run-Dienst gelöscht:
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
Optional: Löschen Sie auf dem Tab „Google Cloud Console“ für Artifact Registry das Image für Ihr Backend unter „firebaseapphosting-images“.
Löschen Sie in Cloud Secret Manager alle Secrets, deren Name „apphosting“ enthält. Achten Sie dabei darauf, dass diese Secrets nicht von anderen Backends oder anderen Aspekten Ihres Firebase-Projekts verwendet werden.