Wdrażanie wielu środowisk z bazy kodu

Często zdarza się, że z tej samej bazy kodu wdraża się wiele środowisk o nieco odmiennej konfiguracji. Możesz na przykład przydzielić środowisku pośredniemu mniej procesora i pamięci RAM lub zadbać o to, aby środowisko produkcyjne miało co najmniej 1 aktywną instancję gotową do obsługi żądań. Możesz też określić różne zmienne środowiskowe i sekrety w zależności od środowiska i zasobów, których chcesz użyć.

W tym przewodniku opisano, jak wdrożyć środowisko produkcyjne i środowisko przejściowe w osobnych projektach Firebase. Stosując te same zasady, możesz wdrażać aplikacje w różnych ś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 usłudze GitHub.
  • Masz już utworzony osobny projekt dla każdego ze środowisk, np. my-production-firebase-project i my-staging-firebase-project. Pamiętaj, aby otagować produkcyjny projekt Firebase typu środowiska „production”.
  • W każdym projekcie utworzysz backend App Hosting, a aktywna gałąź w GitHub zostanie 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 konfiguracji o nazwie apphosting.yaml, który służy do zarządzania ustawieniami czasu wykonywania (procesora, współbieżności, limitów pamięci itp.) i zmiennymi środowiska aplikacji. Obsługuje też odwołania do obiektów tajnych zarządzanych za pomocą usługi Cloud Secret Manager, dzięki czemu można bezpiecznie je sprawdzić w kontroli źródłowej. 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 zapasowej, który jest używany, gdy nie można znaleźć pliku konfiguracji dla danego środowiska. Wartości przechowywane w  powinny być wartościami domyślnymi, które można bezpiecznie używać we wszystkich środowiskach.apphosting.yaml

W kolejnych sekcjach opisujemy, jak zastąpić wartości domyślne w pliku apphosting.yaml w przypadku określonych środowisk. W tym przykładzie tworzymy środowisko testowe.

Krok 1. Ustaw nazwę środowiska

Każdy backend App Hosting ma ustawienie Nazwa środowiska. To pole służy do mapowania backendu na plik konfiguracji dla danego środowiska i może zostać zmienione w dowolnym momencie. Możesz ustawić tylko jedną nazwę środowiska na backend.

Aby ustawić nazwę środowiska backendu:

  1. W konsoli Firebase wybierz projekt testowy (w tym przykładzie my-staging-firebase-project).
  2. W menu nawigacyjnym po lewej stronie wybierz App Hosting.
  3. W wybranym backendzie kliknij Wyświetl panel.
  4. Na karcie Ustawienia wybierz Wdrożenie.
  5. W polu Nazwa środowiska wpisz nazwę środowiska. Środowisku możesz nadać dowolną nazwę. W tym przykładzie jest to wersja testowa.
  6. Kliknij Zapisz.

Gdy w przypadku backendu zostanie uruchomione App Hosting (poprzez git push lub ręcznie w konsoli), App Hosting sprawdzi plik apphosting.ENVIRONMENT_NAME.yaml, a potem użyje apphosting.yaml.

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

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

W momencie kompilacji App Hosting scala te 2 pliki, przy czym wartości w pliku YAML dla konkretnego środowiska mają wyższy priorytet niż wartości w pliku bazowym 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

Ostateczny scalony wynik, który możesz sprawdzić w logach Cloud Build, będzie 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óż kod źródłowy

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

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

Wszystkie zaplecze otagowane tą nazwą środowiska będzie używać określonych wartości zastąpienia określonych w odpowiednim pliku YAML i stosować wartości domyślne apphosting.yaml, gdy nie znajdzie się żadna wartość. W przypadku zaplecza bez powiązanej nazwy środowiska możesz nadal używać pliku apphosting.yaml.

Dalsze kroki