Wdrażanie wielu środowisk z bazy kodu

Często zdarza się, że wdrożenie obejmuje wiele środowisk opartych na tej samej bazie kodu, z różną konfiguracją. Możesz na przykład przypisać do środowiska przejściowego mniej procesora i pamięci RAM lub upewnić się, że w środowisku produkcyjnym co najmniej 1 instancja jest aktywna i gotowa 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 oddzielny projekt dla każdego ze środowisk, np. my-production-firebase-project i my-staging-firebase-project. Pamiętaj, aby oznaczyć w produkcyjnym projekcie Firebase typ środowiska „produkcyjne”.
  • 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 apphosting.yaml do zarządzania ustawieniami środowiska wykonawczego (procesor, równoczesność, limit pamięci itp.) oraz zmiennymi środowiskowymi aplikacji. Obsługuje też odwołania do obiektów tajnych zarządzanych przez Cloud Secret Manager, co umożliwia bezpieczne sprawdzanie kontroli źródła. 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. Ten przykładowy przepływ danych tworzy ś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. Kliknij Wyświetl panel w wybranym backendzie.
  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ż dokument apphosting.yaml, który wyglądał następująco:

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

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.appspot.com
    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