Wdrażanie wielu środowisk z bazy kodu

Często w tej samej bazie kodu jest wdrożonych wiele środowisk, każde z nieco inną konfiguracją. Możesz np. przypisać mniej procesora i pamięci RAM w środowisku testowym lub lepiej w Twoim środowisku produkcyjnym co najmniej 1 instancja jest aktywna i gotowa do obsługi żądań. Można także określić różne zmienne środowiskowe i tajne w zależności od środowiska i zasobów, których chcesz używać.

Z tego przewodnika dowiesz się, jak wdrożyć środowisko produkcyjne i przejściowe, a każdy z nich w osobnym projekcie Firebase. Kierując się tymi samymi zasadami, możesz wdrażać zmiany w innych rodzajach środowisk. Aby dowiedzieć się więcej o środowiskach, zapoznaj się z artykułem na stronie Przegląd środowisk i Ogólne sprawdzone metody konfigurowania Firebase projektów.

Wymagania wstępne

  • Kod Twojej aplikacji jest już zapisany na GitHubie.
  • Masz już utworzony osobny projekt dla każdego środowiska – na przykład my-production-firebase-project oraz my-staging-firebase-project Pamiętaj, aby otagować produkcyjną wersję Firebase projektu ze słowem „production” środowisko .
  • W każdym projekcie masz utworzony backend App Hosting z aktywnym środowiskiem gałąź ustawiona na gałąź GitHub, którą chcesz wdrożyć (np. main). Zobacz Aby uzyskać więcej informacji, zacznij korzystać z App Hosting i informacjami o nich.
.

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

App Hosting obsługuje do zarządzania plik konfiguracyjny o nazwie apphosting.yaml ustawienia środowiska wykonawczego (procesor, równoczesność, limity pamięci itp.) oraz środowisko zmiennych dla Twojej aplikacji. Obsługuje także odwołania do obiektów tajnych zarządzanych za pomocą Usługa Cloud Secret Manager, która umożliwia bezpieczne sprawdzanie kontroli źródła. Więcej więcej informacji znajdziesz w artykule Konfigurowanie .

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 znaleziono pliku konfiguracji konkretnego środowiska. Wartości przechowywane w Domyślne ustawienia apphosting.yaml powinny być bezpieczne we wszystkich środowiskach.

W następnych sekcjach dowiesz się, jak zastąpić wartości domyślne w funkcji apphosting.yaml w określonych środowiskach. Ten przykładowy przepływ tworzy środowisko testowe.

Krok 1. Ustaw nazwę środowiska

Każdy backend App Hosting ma ustawienie Nazwa środowiska. To pole jest służy do mapowania backendu na plik konfiguracji konkretnego środowiska. można zmienić w każdej chwili. Możesz ustawić tylko jedną 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 panelu nawigacyjnym po lewej stronie wybierz App Hosting.
  3. Kliknij Wyświetl panel w wybranym backendzie.
  4. Na karcie Ustawienia wybierz Wdrażanie.
  5. W polu Nazwa środowiska wpisz nazwę środowiska. Możesz nazwać na środowisko. W tym przykładzie jest to etap przejściowy.
  6. Kliknij Zapisz.

Po aktywowaniu wdrożenia App Hosting dla Twojego backendu (w git) lub ręcznie za pomocą konsoli), App Hosting sprawdzi apphosting.ENVIRONMENT_NAME.yaml plik przed w przypadku wersji apphosting.yaml.

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

Na potrzeby konfiguracji w danym środowisku utwórz plik o nazwie apphosting.ENVIRONMENT_NAME.yaml, aby: i określanie zastąpień dla konkretnego środowiska. Ten plik ma taki sam format jak domyślny plik apphosting.yaml i musi znajdować się w pliku w katalogu głównym aplikacji razem z katalogiem apphosting.yaml.

W momencie kompilacji App Hosting scala te 2 pliki, nadając priorytet wartości w pliku YAML odpowiedniego środowiska w podstawowym pliku apphosting.yaml .

W tym przykładzie utworzymy plik o nazwie apphosting.staging.yaml w katalog główny 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ł:

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, pozwoliłyby 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, również zostały zastąpione jak i pokrywające się zmienne środowiskowe.

Krok 3. Wdróż bazę kodu

Gdy skończysz edytowanie pliku apphosting.ENVIRONMENT_NAME.yaml konkretnego środowiska, prześlij go do GitHuba:

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

Wszystkie backendy oznaczone tą nazwą środowiska będą używać określonego zastąpienia określonych w odpowiednim pliku YAML, a następnie użyj apphosting.yaml, jeśli nie znaleziono wartości. Dla backendów bez powiązanego nazwy środowiska, możesz nadal używać pliku apphosting.yaml.

Dalsze kroki