Wdrażanie wielu środowisk z bazy kodu

Często z tej samej bazy kodu wdrażanych jest wiele środowisk, z których każde ma nieco inną konfigurację. Możesz na przykład przypisać mniej procesora i pamięci RAM do środowiska testowego lub zadbać o to, aby w środowisku produkcyjnym co najmniej 1 instancja była aktywna i gotowa do obsługi żądań. W zależności od środowiska i zasobów, których chcesz użyć, możesz też określić różne zmienne środowiskowe i sekrety.

Z tego przewodnika dowiesz się, jak wdrożyć środowisko produkcyjne i testowe w osobnych projektach Firebase. Postępując zgodnie z tymi samymi zasadami, możesz wdrażać aplikacje w innych rodzajach środowisk. Więcej informacji o środowiskach znajdziesz w artykułach Omówienie środowisk i Ogólne sprawdzone metody konfigurowania projektów Firebase.

Wymagania wstępne

  • Kod aplikacji jest już przechowywany w usłudze GitHub.
  • Masz już utworzony osobny projekt dla każdego środowiska, np. my-production-firebase-project i my-staging-firebase-project. Pamiętaj, aby otagować produkcyjny projekt Firebase typem środowiska „produkcyjne”.
  • W każdym projekcie utworzono App Hosting backend, a gałąź live jest ustawiona na gałąź GitHub, którą chcesz wdrożyć (np. main). Więcej informacji znajdziesz w artykule Pierwsze kroki z App Hosting.

Krok 0. Utwórz domyślną konfigurację w pliku apphosting.yaml

App Hosting obsługuje plik konfiguracyjny o nazwie apphosting.yaml, który umożliwia zarządzanie ustawieniami środowiska wykonawczego (CPU, współbieżność, limity pamięci itp.) i zmiennymi środowiskowymi aplikacji. Obsługuje też odwołania do obiektów tajnych zarządzanych za pomocą Cloud Secret Manager, dzięki czemu można go bezpiecznie przechowywać w systemie kontroli wersji. Więcej informacji znajdziesz w artykule Konfigurowanie backendu.

Na początek utwórz plik apphosting.yaml w katalogu głównym aplikacji. Jest to rezerwowy plik konfiguracji, który jest używany, gdy nie można znaleźć pliku konfiguracji specyficznego dla środowiska. Wartości przechowywane w apphosting.yaml powinny być domyślnymi wartościami, których można bezpiecznie używać we wszystkich środowiskach.

W kolejnych sekcjach wyjaśniamy, jak zastąpić wartości domyślne w apphosting.yaml w przypadku konkretnych środowisk. Ten przykładowy przepływ tworzy środowisko przejściowe.

Krok 1. Ustaw nazwę środowiska

Każde zaplecze App Hosting ma ustawienie Nazwa środowiska. To pole służy do mapowania backendu na plik konfiguracyjny specyficzny dla środowiska i można je w każdej chwili zmienić. Możesz ustawić tylko 1 nazwę środowiska na backend.

Aby ustawić nazwę środowiska backendu:

  1. W konsoli Firebase wybierz projekt przejściowy (w tym przykładzie my-staging-firebase-project).
  2. W menu po lewej stronie kliknij App Hosting.
  3. W wybranym backendzie kliknij Wyświetl panel.
  4. Na karcie Ustawienia wybierz Środowisko.
  5. W polu Nazwa środowiska wpisz nazwę środowiska. Środowisko możesz nazwać dowolnie. W tym przykładzie jest to staging.
  6. Kliknij Zapisz.

Gdy App Hosting zostanie uruchomione w przypadku Twojego backendu (w wyniku polecenia git push lub ręcznie w konsoli), App Hosting sprawdzi, czy istnieje plik apphosting.ENVIRONMENT_NAME.yaml, zanim przejdzie do apphosting.yaml.

Krok 2. Utwórz plik apphosting.yaml dla konkretnego środowiska

Aby skonfigurować środowisko, utwórz plik o nazwie apphosting.ENVIRONMENT_NAME.yaml, aby określić zastąpienia specyficzne dla środowiska. Ten plik ma taki sam format jak domyślny plik apphosting.yaml i musi znajdować się w katalogu głównym aplikacji obok pliku apphosting.yaml.

Podczas kompilacji App Hosting scala te 2 pliki, przy czym priorytet mają wartości w pliku YAML specyficznym dla środowiska, a nie w podstawowym pliku apphosting.yaml.

W tym przykładzie utworzysz plik o nazwie apphosting.staging.yaml w katalogu głównym aplikacji:


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

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

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Załóżmy, że masz już apphosting.yaml, który wygląda tak:

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.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

Ostateczne scalone dane wyjściowe, które możesz sprawdzić w logach Cloud Build, będą wyglądać tak:

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.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Pamiętaj, że niektóre wartości runConfig, takie jak CPU, zostały zastąpione, podobnie jak wszystkie nakładające się zmienne środowiskowe.

Krok 3. Wdróż bazę kodu

Po zakończeniu edytowania pliku apphosting.ENVIRONMENT_NAME.yaml specyficznego dla środowiska prześlij go do GitHuba:

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

Wszystkie back-endy oznaczone tą nazwą środowiska będą używać określonych wartości zastąpienia podanych w odpowiednim pliku YAML i wracać do wartości apphosting.yaml, gdy nie znajdą wartości. W przypadku backendów bez powiązanej nazwy środowiska możesz nadal używać pliku apphosting.yaml.

Dalsze kroki