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ń. Możesz też określić różne zmienne środowiskowe i obiekty tajne w zależności od środowiska i zasobów, których chcesz użyć.

W tym przewodniku opisujemy, jak wdrożyć środowisko produkcyjne i testowe w osobnych projektach w Firebase. Postępując zgodnie z tymi samymi zasadami, możesz wdrożyć aplikację w innych środowiskach. 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 GitHubie.
  • Masz już utworzony osobny projekt dla każdego środowiska, np. my-production-firebase-project i my-staging-firebase-project. Pamiętaj, aby oznaczyć produkcyjny projekt Firebase typem środowiska „produkcyjne”.
  • W każdym projekcie utworzono App Hosting backend, a gałąź live została 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ą usługi Cloud Secret Manager, dzięki czemu można go bezpiecznie sprawdzić 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 plik konfiguracji zastępczej, 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ępować 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żda usługa backendu 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ć. Każde zaplecze może mieć tylko 1 nazwę środowiska.

Aby ustawić nazwę środowiska backendu:

  1. W konsoli Firebase wybierz projekt przejściowy (w tym przykładzie my-staging-firebase-project).
  2. Kliknij Hosting i usługi bezserwerowe > Hosting aplikacji.
  3. Kliknij Wyświetl przy wybranym backendzie.
  4. Na karcie Ustawienia wybierz Środowisko.
  5. W sekcji 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 Twoim backendzie (w wyniku polecenia git push lub ręcznie w Firebase konsoli), App Hosting sprawdzi, czy istnieje plik apphosting.ENVIRONMENT_NAME.yaml, zanim powróci do apphosting.yaml.

Krok 2. Utwórz plik apphosting.yaml dla danego ś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, np. 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 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