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 bedienen 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 für die Einrichtung 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 eine Konfigurationsdatei namens apphosting.yaml, mit der Laufzeiteinstellungen (CPU, Parallelität, Arbeitsspeicherlimits usw.) und Umgebungsvariablen für Ihre App verwaltet werden. Außerdem werden Verweise auf mit Cloud Secret Manager verwaltete Secrets unterstützt, sodass eine sichere Versionskontrolle möglich ist. 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 eine umgebungsspezifische Konfigurationsdatei nicht 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 Ihr Backend einer umgebungsspezifischen Konfigurationsdatei zugeordnet. Es kann jederzeit geändert werden. Sie können nur einen Umgebungsnamen pro Back-End festlegen.

So legen Sie den Umgebungsnamen Ihres Backends fest:

  1. Wählen Sie in der Firebase Console Ihr Staging-Projekt aus (in diesem Beispiel „my-staging-firebase-project“).
  2. Wählen Sie im linken Navigationsbereich 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 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 auf apphosting.yaml zurückgegriffen wird.

Schritt 2: Umgebungsspezifische apphosting.yaml-Datei erstellen

Erstellen Sie für die 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 zusammen mit apphosting.yaml im Stammverzeichnis Ihrer App 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

Bestimmte runConfig-Werte wie „CPU“ wurden überschrieben, ebenso wie überlappende Umgebungsvariablen.

Schritt 3: Codebasis bereitstellen

Wenn Sie die benutzerdefinierte apphosting.ENVIRONMENT_NAME.yaml-Datei für Ihre Umgebung fertig bearbeitet haben, können Sie sie auf GitHub hochladen:

$ 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