App Hosting został zaprojektowany tak, aby był łatwy w użyciu i nie wymagał dużej konserwacji. Ustawienia domyślne zostały zoptymalizowane pod kątem większości zastosowań. Jednocześnie App Hosting udostępnia narzędzia do zarządzania backendami i ich konfigurowania zgodnie z konkretnymi potrzebami. W tym przewodniku opisaliśmy te narzędzia i procesy.
Konfigurowanie backendu
Aby skonfigurować zaawansowane ustawienia, np. zmienne środowiskowe lub ustawienia czasu wykonywania, takie jak równoczesność, procesor i limity pamięci, musisz utworzyć i zmodyfikować plik apphosting.yaml
w katalogu głównym aplikacji. Ten plik obsługuje też odwołania do obiektów tajnych zarządzanych za pomocą usługi Cloud Secret Manager, dzięki czemu można bezpiecznie wdrożyć go w kontroli źródłowej.
Aby utworzyć apphosting.yaml
, uruchom to polecenie:
firebase init apphosting
Spowoduje to utworzenie podstawowego pliku startowego apphosting.yaml
z przykładową (zakomentowaną) konfiguracją. Po wprowadzeniu zmian typowy plik apphosting.yaml
może wyglądać tak: zawiera ustawienia usługi Cloud Run w części backendowej, niektóre zmienne środowiskowe i niektóre odwołania do tajemnic zarządzanych przez menedżera tajemnic w chmurze:
# Settings for Cloud Run
runConfig:
minInstances: 2
maxInstances: 100
concurrency: 100
cpu: 2
memoryMiB: 1024
# Environment variables and secrets
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
- variable: API_KEY
secret: myApiKeySecret
# Same as API_KEY above but with a pinned version.
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
# Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
- variable: VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID
# Same as API_KEY above but with the long form secret reference with pinned version.
- variable: PINNED_VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID/versions/5
W dalszej części tego przewodnika znajdziesz więcej informacji i kontekstu dotyczących tych przykładowych ustawień.
Konfigurowanie ustawień usługi Cloud Run
Ustawienia apphosting.yaml
umożliwiają skonfigurowanie obsługi usługi Cloud Run. Dostępne ustawienia usługi Cloud Run są podane w obiekcie runConfig
:
cpu
– liczba procesorów używanych przez każdą instancję serwera (domyślnie 0).memoryMiB
– ilość pamięci przydzielonej dla każdej instancji serwowania w MiB (domyślnie 512).maxInstances
– maksymalna liczba kontenerów, które mogą być uruchamiane jednocześnie (domyślnie 100, zarządzana przez limit)minInstances
– liczba kontenerów, które mają być zawsze aktywne (domyślnie 0).concurrency
– maksymalna liczba żądań, które może otrzymać każda instancja służąca do obsługi (domyślnie 80).
Zwróć uwagę na ważną zależność między parametrami cpu
i memoryMiB
. Pamięć może mieć dowolną wartość całkowitą z zakresu 128–32768, ale zwiększenie limitu pamięci może wymagać zwiększenia limitów procesora:
- Powyżej 4 GiB wymaga co najmniej 2 procesorów
- Ponad 8 GiB wymaga co najmniej 4 procesorów
- Powyżej 16 GiB wymaga co najmniej 6 procesorów
- Ponad 24 GiB wymaga co najmniej 8 procesorów
Podobnie wartość parametru cpu
wpływa na ustawienia równoczelności. Jeśli ustawisz wartość mniejszą niż 1 CPU, musisz ustawić współbieżność na 1, a procesor będzie przydzielany tylko podczas przetwarzania żądań.
Konfigurowanie środowiska kompilacji
Czasami w procesie kompilacji trzeba przeprowadzić dodatkową konfigurację, np. ustawić klucze interfejsu API innych firm lub dostosować ustawienia. App Hosting oferuje konfigurację środowiska apphosting.yaml
do przechowywania i pobierania tego typu danych w przypadku Twojego projektu.
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
W przypadku aplikacji Next.js pliki dotenv zawierające zmienną środowiskową będą też działać z App Hosting. Zalecamy używanie apphosting.yaml
do szczegółowej kontroli zmiennych środowiska w dowolnej strukturze.
W pliku apphosting.yaml
możesz określić, które procesy mają dostęp do zmiennej środowiskowej, za pomocą właściwości availability
. Możesz ograniczyć dostęp do zmiennej środowiskowej tak, aby była dostępna tylko w środowisku kompilacji lub tylko w środowisku wykonawczym. Domyślnie jest ona dostępna dla obu.
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
W przypadku aplikacji Next.js możesz też użyć prefiksu NEXT_PUBLIC_
w taki sam sposób jak w pliku dotenv, aby udostępnić zmienną w przeglądarce.
env:
- variable: NEXT_PUBLIC_STORAGE_BUCKET
value: mybucket.firebasestorage.app
availability:
- BUILD
- RUNTIME
Prawidłowe klucze zmiennych składają się z liter alfabetu A–Z lub znaków podkreślenia. Niektóre klucze zmiennych środowiskowych są zarezerwowane do użytku wewnętrznego. W plikach konfiguracji nie używaj tych kluczy:
- dowolna zmienna zaczynająca się od
X_FIREBASE_
PORT
K_SERVICE
K_REVISION
K_CONFIGURATION
Przechowywanie parametrów obiektów tajnych i uzyskiwanie do nich dostępu
Informacje poufne, takie jak klucze interfejsu API, powinny być przechowywane jako obiekty tajne. Aby uniknąć sprawdzania informacji poufnych w kontroli źródła, możesz odwoływać się do sekretów w apphosting.yaml
.
Parametry typu secret
to parametry ciągu znaków, których wartość jest przechowywana w usłudze Cloud Secret Manager.
Zamiast bezpośrednio uzyskiwać wartość, parametry tajne sprawdzają jej istnienie w usłudze Cloud Secret Manager i wczytują wartości podczas wdrażania.
- variable: API_KEY
secret: myApiKeySecret
Obiekty tajne w usłudze Cloud Secret Manager mogą mieć wiele wersji. Domyślnie wartość parametru tajnego dostępnego dla backendu na żywo jest przypięta do najnowszej dostępnej wersji obiektu tajnego w momencie tworzenia backendu. Jeśli masz wymagania dotyczące wersji i zarządzania cyklem życia parametrów, możesz przypiąć określone wersje za pomocą Cloud Secret Manager. Aby na przykład przypiąć wersję 5:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
Tajne klucze możesz tworzyć za pomocą polecenia wiersza poleceń firebase apphosting:secrets:set
. Pojawi się wtedy prośba o dodanie niezbędnych uprawnień. Ten proces umożliwia automatyczne dodawanie odwołania do obiektu tajnego do apphosting.yaml
.
Aby korzystać z pełnego zestawu funkcji usługi Cloud Secret Manager, możesz zamiast tego użyć konsoli Cloud Secret Manager. W takim przypadku musisz przyznać uprawnienia do backendu App Hosting za pomocą polecenia wiersza poleceń firebase
apphosting:secrets:grantaccess
.
Synchronizacja stanu Uwierzytelniania Firebase
Aplikacje korzystające z Firebase Auth powinny używać pakietu SDK Firebase Web, aby zachować synchronizację stanu uwierzytelniania między klientem a serwerem. Możesz to ułatwić, wdrażając FirebaseServerApp
za pomocą service workera. Podstawowy przepływ pracy:
- Zaimplementuj skrypt service worker, który dodaje odpowiednie nagłówki dla Twojej aplikacji w żądaniach wysyłanych do serwera.
- Pobierz nagłówki z żądania na serwerze i przekształć je w użytkownika uwierzytelnionego za pomocą
FirebaseServerApp
.
Zarządzanie backendem
Polecenia do podstawowego zarządzania backendami App Hosting są dostępne w interfejsie wiersza poleceń Firebase. Niektóre operacje są też dostępne w konsoli Firebase. W tej sekcji opisujemy niektóre z najczęstszych zadań związanych z zarządzaniem, m.in. tworzenie i usuwanie backendów.
Utworzenie backendu
App Hosting backend to zbiór zarządzanych zasobów, które App Hosting tworzy na potrzeby tworzenia i uruchamiania aplikacji internetowej. Każdy właściciel projektu może utworzyć pierwszy App Hosting backend dla projektu za pomocą konsoli Firebase lub interfejsu wiersza poleceń Firebase. Po tej wstępnej konfiguracji App Hostingadministratorzy mogą też tworzyć dodatkowe backendy i nimi zarządzać. Więcej informacji znajdziesz w sekcji Firebase App HostingUprawnienia.
Konsola Firebase: w menu Kompilacja wybierz Hosting aplikacji, a następnie Rozpocznij.
CLI: (wersja 13.15.4 lub nowsza) Aby utworzyć backend, uruchom to polecenie w katalogu głównym lokalnego katalogu projektu, podając jako argumenty projectID i preferowany region:
firebase apphosting:backends:create --project PROJECT_ID --location us-central1
Zarówno w konsoli, jak i w interfejsie wiersza poleceń postępuj zgodnie z instrukcjami wyświetlanymi na ekranie, aby nadać backendowi nazwę, skonfigurować połączenie z GitHubem i skonfigurować te podstawowe ustawienia wdrożenia:
Ustaw katalog główny aplikacji (domyślnie
/
).Zwykle jest to miejsce, w którym znajduje się plik
package.json
.
Ustaw gałąź produkcyjną.
Jest to gałąź w Twoim repozytorium GitHub, która jest wdrażana do adresu URL wersji produkcyjnej. Często jest to gałąź, do której scalane są gałęzie funkcji lub gałęzie rozwoju.
akceptować lub odrzucać automatyczne wdrażanie.
Automatyczne wdrożenia są domyślnie włączone. Po zakończeniu tworzenia backendu możesz od razu wdrożyć aplikację na App Hosting.
Usunięcie backendu
Aby całkowicie usunąć backend, najpierw użyj wiersza poleceń Firebase, a potem ręcznie usuń powiązane zasoby, zwracając szczególną uwagę, aby nie usunąć żadnych zasobów, których używają inne backendy lub inne aspekty projektu Firebase.
Aby usunąć App Hosting backend, uruchom to polecenie: Spowoduje to wyłączenie wszystkich domen w backendzie i usunięcie powiązanej usługi Cloud Run:
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
(Opcjonalnie) Na karcie konsoli Google Cloud Artifact Registry usuń obraz backendu w folderze „firebaseapphosting-images”.
W usłudze Cloud Secret Manager usuń wszystkie obiekty tajne, których nazwa zawiera ciąg „apphosting”. Zwróć szczególną uwagę, aby te obiekty tajne nie były używane przez inne backendy ani inne aspekty projektu Firebase.