App-Hosting-Backends konfigurieren und verwalten

App Hosting wurde für eine einfache Verwendung und geringen Wartungsaufwand entwickelt. Die Standardeinstellungen sind für die meisten Anwendungsfälle optimiert. Gleichzeitig bietet App Hosting Tools, mit denen Sie Back-Ends für Ihre spezifischen Anforderungen verwalten und konfigurieren können. In diesem Leitfaden werden diese Tools und Prozesse beschrieben.

Umgebungsvariablen und Secrets festlegen und aktualisieren

Mit App Hosting können Sie Umgebungsvariablen für nicht vertrauliche Konfigurationswerte und Secrets für vertrauliche Parameter wie API-Schlüssel, Datenbankanmeldedaten und Diensttokens verwenden.

  • Umgebungsvariablen: Werden für nicht vertrauliche Nur-Text-Konfigurationen verwendet (z. B. öffentliche API-URLs, Funktions-Flags oder Build-Ziele). Werte sind für alle Projektmitglieder sichtbar.
  • Secrets: Werden für sensible Parameter wie OAuth-Clientschlüssel, API-Tokens oder Datenbankpasswörter verwendet. Secrets werden von Cloud Secret Manager unterstützt. Secret-Werte sind geschützt und werden in der Firebase-Konsole nie als Nur-Text angezeigt. Stattdessen bietet die Konsole Deeplinks, über die Sie Secret-Werte direkt in Cloud Secret Manager ansehen und verwalten können.

Sie können Umgebungsparameter mit zwei sich ergänzenden Ansätzen definieren und verwalten:

  • Firebase-Konsole: Secrets oder Variablen können während der ersten Back-End-Erstellung oder nach der Bereitstellung in den Back-End-Einstellungen schnell hinzugefügt, bearbeitet und angehängt werden.

  • Code-First (apphosting.yaml): Deklarieren Sie Umgebungsvariablen und Secret-Referenzen in der Konfigurationsdatei Ihres Repositorys für versionskontrollierte Bereitstellungen oder verwenden Sie apphosting.<env>.yaml, um verschiedene Werte für verschiedene Umgebungen festzulegen.

Firebase-Konsole

Screenshot des Dialogfelds in der Firebase Console zum Hinzufügen von Umgebungsvariablen

apphosting.yaml 

env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
  - variable: API_KEY
    secret: myApiKeySecret

Variablen und Secrets in der Firebase-Konsole verwalten

Sie können Umgebungsvariablen und Secrets in der Firebase-Konsole konfigurieren, wenn Sie ein Backend erstellen, oder jederzeit in den Backend-Einstellungen. Änderungen, die ohne Bereitstellung gespeichert werden, werden beim nächsten Roll-out wirksam und wirken sich nicht auf den aktuellen Roll-out aus.

Variablen und Secrets während der Back-End-Erstellung einrichten

Wenn Sie ein neues App Hosting-Backend in der Firebase-Konsole erstellen, können Sie im Schritt Backend konfigurieren des Einrichtungsassistenten Standardumgebungsvariablen und Secrets konfigurieren:

  1. Rufen Sie in der Firebase-Konsole Hosting und Serverless > App Hosting auf und klicken Sie auf Backend erstellen.
  2. Führen Sie die ersten Schritte des Assistenten aus, um Ihre primäre Region und Ihr Code-Repository auszuwählen.
  3. Suchen Sie im Bereich Backend konfigurieren nach den minimierbaren Karten für Umgebungsvariablen und Secrets. Dort können Sie Standardvariablen hinzufügen und Secrets anhängen.
  4. Schließen Sie den Assistenten zum Erstellen des Backends ab und klicken Sie auf Fertigstellen und bereitstellen.

Variablen und Secrets in den Backend-Einstellungen verwalten

Sie können Umgebungsvariablen und Secrets für aktive Back-Ends im Dashboard für Back-End-Einstellungen ansehen, hinzufügen, bearbeiten oder löschen:

  1. Wählen Sie in der Firebase-Konsole Ihr App Hosting-Backend aus und öffnen Sie Einstellungen > Umgebung.
  2. Prüfen Sie die vorhandenen Konfigurationen in der Tabelle Umgebungsvariablen:
    • Standardvariablen: Werte werden als Nur-Text in kopierbaren Codeblöcken angezeigt.
    • Secrets: Wird als anklickbarer Link mit dem Secret-Namen angezeigt (wodurch Cloud Secret Manager in der Google Cloud-Konsole geöffnet wird) zusammen mit der Zielversion (z. B. latest oder eine bestimmte Versionsnummer wie 2).
  3. So fügen Sie eine Variable oder ein Secret hinzu:
    1. Klicken Sie auf Neu hinzufügen.
    2. Wählen Sie unter Schritt 1: Typ auswählen die Option Standard-Umgebungsvariable (für nicht vertrauliche Daten, die für alle Projektmitglieder sichtbar sind) oder Secret (für API-Schlüssel und vertrauliche Anmeldedaten mit eingeschränktem Zugriff) aus und klicken Sie dann auf Weiter.
    3. Geben Sie in Schritt 2: Einstellungen konfigurieren den Schlüsselnamen und entweder den Nur-Text-Wert (für Standardvariablen) ein oder wählen Sie die Secret-ID und die Version (für Secrets) aus.
    4. Speichern Sie die Änderungen mit einer der folgenden Optionen:
      • Speichern und bereitstellen: Aktualisiert die Backend-Konfiguration sofort und löst einen neuen Build und Roll-out aus.
      • Nur speichern (über den Drop-down-Pfeil neben Speichern und bereitstellen): Die Konfigurationsänderungen werden gespeichert, ohne dass sofort ein Roll-out ausgelöst wird. Die aktualisierten Einstellungen werden bei der nächsten Bereitstellung wirksam.
  4. Wenn Sie einen vorhandenen Eintrag bearbeiten oder löschen möchten, klicken Sie am Ende der Zeile auf das Menü Weitere Aktionen (...):
    • Wählen Sie Bearbeiten aus, um den Schlüssel, den Wert, die Secret-Zuordnung oder die Version zu ändern, und klicken Sie dann auf Speichern und bereitstellen oder Nur speichern.
    • Wählen Sie Löschen aus und bestätigen Sie das Entfernen im Dialogfeld.

Variablen aus dotenv-Dateien übertragen

Bei Next.js-Anwendungen funktionieren dotenv-Dateien mit Umgebungsvariablen mit App Hosting.

Wenn Sie ein Backend erstellen oder aktualisieren, können Sie Umgebungsvariablen aus Ihrer dotenv-Datei in die Firebase-Konsole übertragen. Kopieren Sie dazu den gesamten Inhalt der dotenv-Datei und fügen Sie ihn in das erste Feld Schlüssel im Formular Neu hinzufügen unter Einstellungen > Umgebung ein.

Alle so kopierten Umgebungsvariablen werden automatisch in das Formular eingefügt, ohne dass Sie jede einzeln eingeben müssen, sofern die Eingabe das Standardformat KEY=value verwendet:

KEY1=value1
KEY2=value2
KEY3=value3

Für eine komplexe oder detaillierte Steuerung von Umgebungsvariablen mit einem beliebigen Framework empfehlen wir die Verwendung von apphosting.yaml.

Variablen und Secrets in apphosting.yaml verwalten

Deklarieren Sie für Code-First-Workflows Standardumgebungsvariablen und Secret-Referenzen unter dem Schlüssel env: in der Konfigurationsdatei apphosting.yaml Ihres Projekt-Repositorys (siehe apphosting.yaml erstellen und bearbeiten).

env:
  # Standard environment variables
  - variable: PUBLIC_API_URL
    value: https://api.example.com
    availability:
      - BUILD
      - RUNTIME
  - variable: FEATURE_FLAG_NEW_UI
    value: "true"

  # Secret references backed by Cloud Secret Manager
  - variable: DATABASE_URL
    secret: projects/PROJECT_ID/secrets/db-connection-string/versions/latest
  - variable: GEMINI_API_KEY
    secret: myGeminiApiKeySecret@1

Jeder Eintrag in env: unterstützt die folgenden Felder:

  • variable: Der Name der Umgebungsvariablen, die für Ihren Anwendungsprozess verfügbar gemacht wird.
  • value: Der Nur-Text-Stringwert (für Standard-Umgebungsvariablen).
  • secret: Die Secret-Referenz von Cloud Secret Manager (für Secrets). Sie können den kurzen Secret-Namen (z. B. myGeminiApiKeySecret oder angepinntes myGeminiApiKeySecret@1) oder den vollständigen Ressourcenpfad (projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION) verwenden. Weitere Informationen finden Sie unter Secret-Parameter speichern und darauf zugreifen.
  • availability: Steuert, ob die Variable oder das Secret während der BUILD-Phase, bei RUNTIME oder beidem zugänglich ist.

Variable Verfügbarkeit festlegen

In der Firebase Console konfigurierte Umgebungsvariablen und Secrets sind sowohl zur Build- als auch zur Laufzeit verfügbar. Dies ist auch das Standardverhalten für Einträge, die in apphosting.yaml definiert sind, sofern Sie den Bereich nicht mit dem Attribut availability einschränken. In apphosting.yaml (aber nicht in der Console) können Sie eine Variable oder ein Secret auf die Build-Umgebung (BUILD) oder die Laufzeitumgebung (RUNTIME) beschränken.

Auf Variablen und Secrets im Anwendungscode zugreifen

Unabhängig davon, ob sie in der Firebase-Konsole oder in apphosting.yaml konfiguriert sind, werden Umgebungsvariablen und Secrets für Ihre Anwendungslaufzeit als Standardumgebungsvariablen (z. B. process.env in Node.js) bereitgestellt.

// Accessing a standard environment variable
const apiUrl = process.env.PUBLIC_API_URL;

// Accessing a secret
const apiKey = process.env.GEMINI_API_KEY;

export async function fetchData() {
  const response = await fetch(`${apiUrl}/data`, {
    headers: {
      'Authorization': `Bearer ${apiKey}`
    }
  });
  return response.json();
}
  • Serverseitiger Zugriff: Alle Umgebungsvariablen und Secrets sind in serverseitigen Ausführungskontexten (z. B. Next.js-Serverkomponenten, API-Routen oder Node.js-Backend-Handler) sicher zugänglich.

  • Clientseitige Offenlegung: Wenn Sie Standardumgebungsvariablen in Frameworks wie Next.js für den Browser verfügbar machen möchten, muss der Variablenschlüssel den Framework-Konventionen entsprechen (z. B. mit dem Präfix NEXT_PUBLIC_).

    env:
  - variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      - BUILD
      - RUNTIME

Variablenhierarchie

Firebase App Hosting wendet Ihre Umgebungsvariablen und Secrets in einer Rangfolge an, die auf ihrer Quelle basiert. In der Firebase-Konsole festgelegte Konfigurationen überschreiben immer Parameter, die in den Dateien apphosting.yaml und dotenv deklariert sind. Wenn eine Umgebungsvariable oder ein Secret-Schlüssel mit demselben Namen sowohl in apphosting.yaml als auch in der Firebase-Konsole vorhanden ist, hat der Konsolenwert während der Build- und Laufzeitausführung Vorrang.

Hier ist die vollständige Rangfolge:

  1. Firebase-Konsole → Variablen und Secrets, die in der Konsole festgelegt wurden
  2. apphosting.<env>.yaml: Variablen und Secrets, die in einer umgebungsspezifischen YAML-Datei wie apphosting.staging.yaml angegeben sind (siehe Mehrere Umgebungen bereitstellen)
  3. apphosting.yaml: Variablen und Secrets, die in der Datei apphosting.yaml angegeben sind
  4. Firebase-System → Variablen, die von Firebase festgelegt werden und Werte für FIREBASE_CONFIG oder FIREBASE_WEBAPP_CONFIG enthalten, sowie Umgebungsvariablen, die die Hostnamen und Ports für SSR-Apps festlegen (festgelegt durch App Hosting-Adapter in bundle.yaml)

Automatisch ausgefüllte Umgebungsvariablen

Es gibt Umgebungsvariablen, die automatisch von App Hosting ausgefüllt werden. Dazu gehören die von Google Cloud ausgefüllten Variablen sowie Firebase-spezifische Umgebungsvariablen, wenn appId während der Einrichtung im Backend festgelegt wird:

  • FIREBASE_CONFIG: (in den Build- und Laufzeitumgebungen verfügbar) Stellt die folgenden Konfigurationsinformationen für das Firebase-Projekt bereit:

    {
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "storageBucket": "PROJECT_ID.firebasestorage.app",
  "projectId": "PROJECT_ID"
}

    Diese Konfiguration wird automatisch angewendet, wenn Sie das Firebase Admin SDK ohne Argumente initialisieren.

  • FIREBASE_WEBAPP_CONFIG: (nur in der Build-Umgebung verfügbar) Stellt die folgenden Konfigurationsinformationen für das Firebase-Projekt bereit:

    {
  "apiKey": "API_KEY",
  "appId": "APP_ID",
  "authDomain": "AUTH_DOMAIN.firebaseapp.com",
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "messagingSenderId": "PROJECT_NUMBER",
  "projectId": "PROJECT_ID",
  "storageBucket": "PROJECT_ID.firebasestorage.app"
}</span>

    Das Firebase JS SDK sucht während des Builds automatisch nach dieser Umgebungsvariablen FIREBASE_WEBAPP_CONFIG in einem Postinstall-Script, sodass Sie das Client SDK auch ohne Argumente initialisieren können.

Weitere Informationen zur Verwendung dieser Umgebungsvariablen zum Initialisieren der SDKs finden Sie unter Firebase Admin SDK und Web-SDKs automatisch initialisieren.

Die Werte in Ihrer tatsächlichen Firebase-Konfiguration entsprechen den jeweiligen Ressourcen, die Sie in Ihrem Projekt bereitgestellt haben.

Variablenhierarchie

Firebase App Hosting wendet Ihre Variablen in einer Rangfolge an, die auf ihrer Quelle basiert. Beispielsweise überschreiben Werte, die in der Firebase-Konsole festgelegt wurden, immer Werte, die in apphosting.yaml- und dotenv-Dateien festgelegt wurden, oder haben Vorrang vor diesen.

Hier ist die vollständige Rangfolge:

  1. Firebase-Konsole → Variablen, die in der Konsole festgelegt werden
  2. apphosting.<env>.yaml → Variablen, die in einer umgebungsspezifischen YAML-Datei wie apphosting.staging.yaml angegeben sind (siehe Mehrere Umgebungen bereitstellen)
  3. apphosting.yaml → Variablen, die in der Datei apphosting.yaml angegeben sind
  4. Firebase-System: Variablen, die von Firebase festgelegt werden und Werte für firebase_config json oder firebase_webapp_config enthalten, sowie Umgebungsvariablen, die die Hostnamen und Ports für SSR-Apps festlegen (von App Hosting-Adaptern in bundle.yaml festgelegt)

Reservierte Namen und Einschränkungen

Die im Cloud Run-Containerlaufzeitvertrag definierten Umgebungsvariablen sind reserviert. Sie können nicht festgelegt werden.

Umgebungsvariablen, die von der Umgebung bereitgestellt werden, mit Ausnahme der automatisch festgelegten, können sich in zukünftigen Laufzeitversionen ändern. Als Best Practice empfehlen wir, dass Sie sich nicht auf Umgebungsvariablen verlassen, die Sie nicht explizit festgelegt haben, und diese auch nicht ändern. Außerdem sollten Sie allen Umgebungsvariablen einen eindeutigen Schlüssel voranstellen, um Konflikte zu vermeiden.

Einige Umgebungsvariablenschlüssel sind für die interne Verwendung reserviert. Verwenden Sie keinen dieser Schlüssel in Ihren Konfigurationsdateien:

  • Leere Strings ("")
  • Schlüssel, die „=“ enthalten
  • Schlüssel, die mit X_FIREBASE_, X_GOOGLE_ oder CLOUD_RUN_ beginnen
  • PORT
  • K_SERVICE
  • K_REVISION
  • K_CONFIGURATION
  • Doppelte Schlüssel

apphosting.yaml erstellen und bearbeiten

Für erweiterte Konfigurationen wie Secrets 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 Verweise auf Secrets, die mit Cloud Secret Manager verwaltet werden, sodass sie sicher in die Versionsverwaltung eingecheckt werden kann.

Führen Sie den folgenden Befehl aus, um apphosting.yaml zu erstellen:

firebase init apphosting

Dadurch wird eine einfache apphosting.yaml-Starterdatei mit einer Beispielkonfiguration (kommentiert) 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 Verweisen 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 weiteren Verlauf dieses Leitfadens finden Sie weitere Informationen und Kontext zu diesen Beispieleinstellungen.

Cloud Run-Diensteinstellungen konfigurieren

Mit apphosting.yaml-Einstellungen können Sie konfigurieren, wie Ihr Cloud Run-Dienst bereitgestellt wird. Die verfügbaren Einstellungen für den Dienst Cloud Run werden im Objekt runConfig bereitgestellt:

  • cpu: Anzahl der CPUs, die für jede Bereitstellungsinstanz verwendet werden (Standardwert: 1).
  • memoryMiB: Arbeitsspeicher, der jeder Bereitstellungsinstanz in MiB zugewiesen wird (Standardwert: 512).
  • maxInstances: Maximale Anzahl von Containern, die gleichzeitig ausgeführt werden können (Standardwert 100 und durch Kontingent verwaltet).
  • minInstances: Anzahl der Container, die immer aktiv bleiben sollen (Standardwert: 0).
  • concurrency: Maximale Anzahl von Anfragen, die jede Bereitstellungsinstanz empfangen kann (Standardwert: 80).
  • cpuAlwaysAllocated: Gibt an, ob die CPU immer zugewiesen wird, auch wenn keine Anfragen verarbeitet werden (Standardwert: false).

Beachten Sie, dass cpu, memoryMiB und concurrency voneinander abhängige Limits haben. Beispielsweise erfordern höhere Speicherkonfigurationen höhere Mindest-CPU-Limits und fraktionale CPUs erfordern eine Nebenläufigkeit von 1. Gültige Bereiche und erforderliche Kombinationen finden Sie in der Cloud Run-Dokumentation zu CPU-Limits und Speicherlimits.

Build- und Ausführungsskripts überschreiben

App Hosting leitet den Build- und Startbefehl Ihrer Anwendung anhand des erkannten Frameworks ab. Wenn Sie einen benutzerdefinierten Build- oder Startbefehl verwenden möchten, können Sie die Standardeinstellungen von App Hosting in apphosting.yaml überschreiben.

scripts:
  buildCommand: next build --no-lint
  runCommand: node dist/index.js

Das Überschreiben des Build-Befehls hat Vorrang vor allen anderen Build-Befehlen. Dadurch werden die Framework-Adapter für Ihre Anwendung deaktiviert und alle Framework-spezifischen Optimierungen, die App Hosting bietet, werden deaktiviert. Sie eignet sich am besten, wenn die Funktionen Ihrer App von den Adaptern nicht gut unterstützt werden. Wenn Sie den Build-Befehl ändern, aber weiterhin die bereitgestellten Adapter verwenden möchten, legen Sie stattdessen das Build-Script in package.json fest, wie unter App Hosting-Framework-Adapter beschrieben.

Verwenden Sie die Überschreibung des Ausführungsbefehls, wenn Sie einen bestimmten Befehl zum Starten Ihrer Anwendung verwenden möchten, der sich von dem von App Hosting abgeleiteten Befehl unterscheidet.

Build-Ausgabe konfigurieren

App Hosting optimiert Ihre App-Bereitstellungen standardmäßig, indem nicht verwendete Ausgabedateien gemäß den Angaben des Frameworks gelöscht werden. Wenn Sie die Bereitstellungsgröße Ihrer App weiter optimieren oder die Standardoptimierungen ignorieren möchten, können Sie dies in apphosting.yaml überschreiben.

outputFiles:
  serverApp:
    include: [dist, server.js]

Der Parameter include akzeptiert eine Liste von Verzeichnissen und Dateien relativ zum Stammverzeichnis der Anwendung, die für die Bereitstellung der Anwendung erforderlich sind. Wenn Sie sicherstellen möchten, dass alle Dateien beibehalten werden, setzen Sie „include“ auf [.]. Dann werden alle Dateien bereitgestellt.

Secret-Parameter speichern und darauf zugreifen

Vertrauliche Informationen wie API-Schlüssel sollten als Secrets gespeichert werden. Sie können Secrets in der Firebase-Konsole an Ihr Backend anhängen oder in apphosting.yaml darauf verweisen, um zu vermeiden, dass vertrauliche Informationen in die Versionsverwaltung gelangen.

Parameter vom Typ secret stellen Stringparameter dar, deren Wert in Cloud Secret Manager gespeichert ist. Anstatt den Wert direkt abzuleiten, prüfen Secret-Parameter, ob sie in Cloud Secret Manager vorhanden sind, und laden die Werte während des Roll-outs.

env:
  - 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 Ihr Live-Backend verfügbar ist, an die neueste verfügbare Version des Secrets zum Zeitpunkt der Erstellung des Backends angepinnt. Wenn Sie Anforderungen an die Versionsverwaltung und das Lebenszyklusmanagement von Parametern haben, können Sie bestimmte Versionen in der Firebase-Konsole oder in apphosting.yaml anpinnen. Beispiel für das Anpinnen an Version 5 in apphosting.yaml:

env:
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Sie können Secrets mit dem Firebase-CLI-Befehl firebase apphosting:secrets:set erstellen. Sie werden dann aufgefordert, die erforderlichen Berechtigungen hinzuzufügen. In diesem Ablauf haben Sie die Möglichkeit, den Secret-Verweis automatisch zu apphosting.yaml hinzuzufügen.

Zugriff auf Cloud Secret Manager gewähren

Damit App Hosting während Build- und Laufzeit-Rollouts Secret-Werte abrufen kann, muss das App Hosting-Backend-Dienstkonto die Berechtigung für den Zugriff auf Cloud Secret Manager haben.

Wenn Sie Secrets mit der Cloud Secret Manager-Konsole oder der gcloud-Befehlszeile anstelle von firebase apphosting:secrets:set erstellen, gewähren Sie Ihrem Backend mit der Firebase-Befehlszeile Zugriff:

firebase apphosting:secrets:grantaccess SECRET_NAME

Alternativ können Sie dem App Hosting-Dienst-Agent (service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com) oder dem Laufzeitdienstkonto Ihres Back-Ends mit der gcloud-Befehlszeile die Rolle Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) zuweisen:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

Konsolenzugriff und rollenbasierte Berechtigungen

In der Firebase-Konsole werden die Funktionen zur Umgebungs- und Secret-Verwaltung dynamisch basierend auf den IAM-Berechtigungen des Nutzers eingeschränkt:

  • Betrachterrolle: Nutzer mit Leseberechtigungen für das Projekt können vorhandene Konfigurationseinstellungen ansehen, aber keine Änderungen vornehmen.
    • Während der Back-End-Erstellung ist die Schaltfläche Back-End erstellen deaktiviert.
    • In den Backend-Einstellungen > Umgebung ist die Schaltfläche Neu hinzufügen deaktiviert und die Zeilenmenüs Weitere Aktionen (...) sind ausgeblendet.
  • Fehlende Secret Manager-Berechtigungen: Nutzer, die keine IAM-Berechtigungen für die Interaktion mit Cloud Secret Manager haben, sehen in der Console eine Warnmeldung (Bitten Sie einen Project Owner um die Berechtigung zum Hinzufügen von Secrets):
    • Während der Backend-Erstellung ist die Karte Secrets deaktiviert.
    • In den Backend-Einstellungen > Umgebung ist die Option Secret deaktiviert, wenn Sie auf Neu hinzufügen klicken. Einige der Optionen im Zeilenmenü Weitere Aktionen (...) sind bei vorhandenen Secret-Einträgen ausgeblendet.

VPC-Zugriff konfigurieren

Ihr App Hosting-Backend kann eine Verbindung zu einem VPC-Netzwerk (Virtual Private Cloud) herstellen. Weitere Informationen und ein Beispiel finden Sie unter Firebase App Hosting mit einem VPC-Netzwerk verbinden.

Verwenden Sie die Zuordnung vpcAccess in Ihrer apphosting.yaml-Datei, um den Zugriff zu konfigurieren. Verwenden Sie entweder einen vollständig qualifizierten Netzwerk-/Connector-Namen oder eine ID. Die Verwendung von IDs ermöglicht die Übertragbarkeit zwischen Staging- und Produktionsumgebungen mit unterschiedlichen Connectors/Netzwerken.

Konfiguration für ausgehenden Direct VPC-Traffic (apphosting.yaml):

runConfig:
  vpcAccess:
    egress: PRIVATE_RANGES_ONLY # Default value
    networkInterfaces:
      # Specify at least one of network and/or subnetwork
      - network: my-network-id
        subnetwork: my-subnetwork-id

Konfiguration des serverlosen Connectors (apphosting.yaml):

runConfig:
  vpcAccess:
    egress: ALL_TRAFFIC
    connector: connector-id

Back-Ends verwalten

Befehle für die grundlegende Verwaltung von App Hosting-Back-Ends werden in der Firebase-Konsole und der Firebase-Befehlszeile bereitgestellt. In diesem Abschnitt werden einige der gängigsten Verwaltungsaufgaben beschrieben, einschließlich des Erstellens und Löschens 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.

Firebase-Konsole: Gehen Sie zu Hosting und serverlos > App Hosting und klicken Sie dann auf Backend erstellen. Wenn dies das erste Backend in Ihrem Firebase-Projekt ist, klicken Sie auf Jetzt starten.

Firebase Befehlszeile: (v13.15.4 oder höher) Führen Sie den folgenden Befehl im Stammverzeichnis Ihres lokalen Projektverzeichnisses aus, um ein Backend zu erstellen. Geben Sie dabei Ihre Projekt-ID als Argument an:

firebase apphosting:backends:create --project PROJECT_ID

Folgen Sie in der Console oder der Befehlszeile den Aufforderungen, um eine Region auszuwählen, eine GitHub-Verbindung einzurichten und die folgenden grundlegenden Bereitstellungseinstellungen zu konfigurieren:

  • Legen Sie das Stammverzeichnis Ihrer App fest (Standardeinstellung ist /).

    Hier befindet sich üblicherweise die Datei package.json.

  • Live-Zweig festlegen

    Dies ist der Zweig Ihres GitHub-Repositorys, der unter Ihrer Live-URL bereitgestellt wird. Oft ist es der Zweig, in den Feature- oder Entwicklungszweige zusammengeführt werden.

  • Automatische Roll-outs akzeptieren oder ablehnen

    Automatische Roll-outs sind standardmäßig aktiviert. Nach Abschluss der Backend-Erstellung können Sie Ihre Anwendung sofort in App Hosting bereitstellen lassen.

  • Weisen Sie dem Backend einen Namen zu.

  • Wählen Sie Ihre Laufzeitumgebung aus. Standardmäßig ist die neueste empfohlene Node.js-Version für Sie vorausgewählt.

    • Automatische Basis-Image-Updates (ABIU) konfigurieren ABIU ist standardmäßig aktiviert und wendet automatisch Sicherheitspatches auf die zugrunde liegende Umgebung an. Sie können ABIU deaktivieren, indem Sie für Ihre Laufzeit „Nicht angegeben“ auswählen.

Backend löschen

Wenn Sie ein Backend vollständig entfernen möchten, löschen Sie es zuerst über die Firebase Console oder die Firebase CLI. Entfernen Sie dann manuell die zugehörigen Assets. Achten Sie dabei darauf, keine Ressourcen zu löschen, die möglicherweise von anderen Backends oder anderen Aspekten Ihres Firebase-Projekts verwendet werden.

Firebase-Konsole: Wählen Sie im Menü Einstellungen die Option Backend löschen aus.

Firebase-Befehlszeile: (v13.15.4 oder höher)

  1. Führen Sie den folgenden Befehl aus, um das Backend App Hosting 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

  2. (Optional) Löschen Sie auf dem Tab der Google Cloud-Konsole für Artifact Registry das Image für Ihr Backend in „firebaseapphosting-images“.

  3. Löschen Sie in Cloud Secret Manager alle Secrets, die „apphosting“ im Namen enthalten. Achten Sie darauf, dass diese Secrets nicht von anderen Back-Ends oder anderen Teilen Ihres Firebase-Projekts verwendet werden.