Mehrere Umgebungen aus einer Codebasis bereitstellen

Es ist üblich, dass mehrere Umgebungen aus derselben Codebasis bereitgestellt werden, jede mit einer etwas anderen Konfiguration. Beispielsweise können Sie Ihrer Staging-Umgebung weniger CPU und RAM zuweisen oder dafür sorgen, dass in Ihrer Produktionsumgebung mindestens eine Instanz aktiv ist und Anfragen bearbeiten kann. Je nach Umgebung und Ressourcen, die Sie verwenden möchten, können Sie auch unterschiedliche Umgebungsvariablen und Secrets angeben.

In dieser Anleitung wird beschrieben, wie Sie eine Produktions- und eine Staging-Umgebung jeweils in einem separaten Firebase-Projekt bereitstellen. Nach denselben Prinzipien können Sie auch in anderen Umgebungen bereitstellen. Weitere Informationen zu Umgebungen finden Sie unter Umgebungen und Allgemeine Best Practices zum Einrichten von Firebase-Projekten.

Vorbereitung

  • Ihr Anwendungscode ist bereits in GitHub gespeichert.
  • Sie haben bereits ein separates Projekt für jede Ihrer Umgebungen erstellt, z. B. my-production-firebase-project und my-staging-firebase-project. Taggen Sie Ihr Produktions-Firebase-Projekt mit dem Umgebungstyp „production“.
  • In jedem Projekt haben Sie ein App Hosting-Backend erstellt, wobei der Live-Branch auf den GitHub-Branch festgelegt ist, den Sie bereitstellen möchten (z. B. main). Weitere Informationen finden Sie unter Erste Schritte mit App Hosting.

Schritt 0: Standardkonfiguration in apphosting.yaml erstellen

App Hosting unterstützt die Konfigurationsdatei apphosting.yaml, mit der Sie Laufzeiteinstellungen (CPU, Gleichzeitigkeit, Arbeitsspeicherlimits usw.) und Umgebungsvariablen für Ihre Anwendung verwalten können. Sie unterstützt auch Verweise auf Secrets, die mit Cloud Secret Manager verwaltet werden. So können Sie sicher in die Versionsverwaltung einchecken. Weitere Informationen finden Sie unter Backend konfigurieren.

Erstellen Sie zuerst eine apphosting.yaml-Datei im Stammverzeichnis Ihrer App. Dies ist die Fallback-Konfigurationsdatei, die verwendet wird, wenn keine umgebungsspezifische Konfigurationsdatei gefunden wird. Die in apphosting.yaml gespeicherten Werte sollten Standardwerte sein, die für alle Umgebungen sicher verwendet werden können.

In den folgenden Abschnitten wird erläutert, wie Sie Standardwerte in apphosting.yaml für bestimmte Umgebungen überschreiben. In diesem Beispiel wird eine Staging-Umgebung erstellt.

Schritt 1: Namen der Umgebung festlegen

Jedes App Hosting-Backend hat die Einstellung Umgebungsname. Mit diesem Feld wird das Back-End einer umgebungsspezifischen Konfigurationsdatei zugeordnet. Es kann jederzeit geändert werden. Sie können nur einen Umgebungsnamen pro Back-End festlegen.

Um den Umgebungsnamen Ihres Back-Ends festzulegen,

  1. Wählen Sie in der Firebase Console Ihr Staging-Projekt aus (in diesem Beispiel „my-staging-firebase-project“).
  2. Wählen Sie in der linken Navigationsleiste App Hosting aus.
  3. Klicken Sie im ausgewählten Backend auf Dashboard ansehen.
  4. Wählen Sie auf dem Tab Einstellungen die Option Bereitstellung aus.
  5. Geben Sie unter Environment name (Umgebungsname) den Namen Ihrer Umgebung ein. Sie können der Umgebung einen beliebigen Namen geben. In diesem Beispiel ist das staging.
  6. Klicken Sie auf Speichern.

Wenn ein App Hosting-Roll-out für Ihr Backend ausgelöst wird (entweder bei einem Git-Push oder manuell über die Konsole), sucht App Hosting nach einer apphosting.ENVIRONMENT_NAME.yaml-Datei, bevor es zu apphosting.yaml zurückkehrt.

Schritt 2: Umgebungsspezifische apphosting.yaml-Datei erstellen

Erstellen Sie für Ihre umgebungsspezifische Konfiguration eine Datei mit dem Namen apphosting.ENVIRONMENT_NAME.yaml, um umgebungsspezifische Überschreibungen anzugeben. Diese Datei hat dasselbe Format wie die Standarddatei apphosting.yaml und muss sich neben apphosting.yaml im Stammverzeichnis Ihrer Anwendung befinden.

Beim Build werden diese beiden Dateien von App Hosting zusammengeführt. Dabei haben Werte in der umgebungsspezifischen YAML-Datei Vorrang vor der Basisdatei apphosting.yaml.

In diesem Beispiel erstellen Sie im Stammverzeichnis der App eine Datei mit dem Namen apphosting.staging.yaml:


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

env:
  -   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

  -   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Angenommen, Sie hatten bereits eine apphosting.yaml, die so aussah:

runConfig:
  cpu: 3
  memoryMiB: 1024
  maxInstances: 4
  minInstances: 0
  concurrency: 100

env:
  -   variable: API_URL
    value: api.service.com
    availability:
      -   BUILD
      -   RUNTIME

  -   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

Die endgültige zusammengeführte Ausgabe, die Sie in Ihren Cloud Build-Logs prüfen können, würde so aussehen:

runConfig:
  cpu: 1
  memoryMiB: 512
  maxInstances: 4
  minInstances: 0
  concurrency: 5

env:
  -   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

  -   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

  -   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Beachten Sie, dass bestimmte runConfig-Werte wie CPU sowie alle sich überschneidenden Umgebungsvariablen überschrieben wurden.

Schritt 3: Codebasis bereitstellen

Wenn Sie mit der Bearbeitung der umgebungsspezifischen Datei apphosting.ENVIRONMENT_NAME.yaml fertig sind, übertragen Sie die Datei per Push an GitHub:

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

Alle mit diesem Umgebungsnamen getaggten Backends verwenden die spezifischen Überschreibungswerte, die Sie in der entsprechenden YAML-Datei angegeben haben, und wechseln zu apphosting.yaml, wenn kein Wert gefunden wird. Für Back-Ends ohne zugewiesenen Umgebungsnamen können Sie weiterhin apphosting.yaml verwenden.

Nächste Schritte