Watch demos on how to build & run AI-powered apps with Firebase at Demo Day '24. Watch now.

Diese Seite wurde von der Cloud Translation API übersetzt.

App-Hosting-Backends konfigurieren und verwalten

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 eine erweiterte Konfiguration wie Umgebungsvariablen oder Laufzeiteinstellungen wie Nebenläufigkeit, CPU- und Arbeitsspeicherlimits müssen Sie die Datei apphosting.yaml im Stammverzeichnis Ihrer Anwendung 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.appspot.com
    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 Einstellungen für apphosting.yaml können Sie konfigurieren, wie der Dienst Cloud Run bereitgestellt wird. 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 sollen (Standardwert 100 und über Kontingent verwaltet)
minInstances – Anzahl der Container, die immer aktiv bleiben sollen (Standard: 0).
concurrency: Maximale Anzahl von Anfragen, die jede bereitstellende Instanz empfangen kann (Standardwert 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:

Mehr als 4 GiB erfordern mindestens 2 CPUs
Mehr als 8 GiB erfordern mindestens 4 CPUs
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.appspot.com

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.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

Für Next.js-Anwendungen können Sie das Präfix NEXT_PUBLIC_ genauso verwenden wie in der Punktenv-Datei, um eine Variable im Browser zugänglich zu machen.

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

Gültige Variablenschlüssel bestehen aus A-Z-Zeichen 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 den Anfragen an den Server die richtigen Header für Ihre App hinzufügt.
Rufen Sie die Header aus der Anfrage auf dem Server ab und konvertieren Sie diese mit FirebaseServerApp in einen Authentifizierungsnutzer.

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 der verwalteten Ressourcen, die App Hosting zum Erstellen und Ausführen Ihrer Webanwendung erstellt. Sie können App Hosting-Backends mit der Firebase-Konsole oder der Firebase-Befehlszeile erstellen und auflisten.

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 (Standard: /).

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 Back-End 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.