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
orazmy-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,
- W konsoli Firebase wybierz projekt przejściowy (w tym przykładzie my-staging-firebase-project).
- W panelu nawigacyjnym po lewej stronie wybierz App Hosting.
- Kliknij Wyświetl panel w wybranym backendzie.
- Na karcie Ustawienia wybierz Wdrażanie.
- W polu Nazwa środowiska wpisz nazwę środowiska. Możesz nazwać na środowisko. W tym przykładzie jest to etap przejściowy.
- 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
- Dowiedz się więcej: wykonaj ćwiczenia z programowania Firebase, które integrują hostowaną aplikację Funkcje Uwierzytelnianie Firebase i AI od Google: Next.js | Angular
- Połącz domenę niestandardową
- Skonfiguruj backend
- Monitorowanie wdrożeń, wykorzystania witryny i logów.