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 pod kątem konkretnych potrzeb. 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ą (skomentowaną) 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 sekretów zarządzanych przez menedżera sekretów 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.appspot.com
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 w MiB do każdej instancji obsługującej (domyślnie 512)maxInstances– maksymalna liczba kontenerów, które mogą być uruchamiane jednocześnie (domyślnie 100 i 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 CPU
Podobnie wartość parametru cpu wpływa na ustawienia równoczelności. Jeśli ustawisz wartość mniejszą niż 1 CPU, musisz ustawić równoczesność na 1. CPU będzie przydzielany tylko podczas przetwarzania żądań.
Konfigurowanie środowiska kompilacji
Czasami w procesie kompilacji może być potrzebna dodatkowa konfiguracja, np. klucze interfejsu API innych firm lub ustawienia, które można dostosować. App Hosting oferuje konfigurację środowiska apphosting.yaml do przechowywania i pobierania tego typu danych w projekcie.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
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 narzędziu apphosting.yaml możesz użyć właściwości availability, by określić, które procesy mają dostęp do zmiennej środowiskowej. 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.appspot.com
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.appspot.com
availability:
- BUILD
- RUNTIME
Prawidłowe klucze zmiennych składają się z liter 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 żadnych z tych kluczy:
- dowolna zmienna zaczynająca się od
X_FIREBASE_ PORTK_SERVICEK_REVISIONK_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 obiektów tajnych w apphosting.yaml.
Parametry typu secret reprezentują parametry ciągu znaków, które mają wartość zapisaną w usłudze Cloud Secret Manager.
Zamiast wyprowadzać wartość bezpośrednio, 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ę 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. Jeśli to zrobisz, musisz przyznać uprawnienia backendowi App Hosting za pomocą polecenia interfejsu wiersza poleceń firebase
apphosting:secrets:grantaccess.
Synchronizowanie stanu uwierzytelniania Firebase
W przypadku aplikacji korzystających z Uwierzytelniania Firebase warto korzystać z pakietu SDK internetowego Firebase, aby synchronizować stan uwierzytelniania między klientem a serwerem. Aby to ułatwić, możesz wdrożyć FirebaseServerApp za pomocą skryptu service worker. Podstawowy przepływ pracy:
- Zaimplementuj skrypt service worker, który dodaje odpowiednie nagłówki aplikacji w żądaniach do serwera.
- Pobierz nagłówki z żądania z serwera i przekonwertuj je na użytkownika uwierzytelniania za pomocą
FirebaseServerApp.
Zarządzanie backendem
Polecenia 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ń administracyjnych, w tym tworzenie i usuwanie backendów.
Utworzenie backendu
App Hosting backend to zbiór zarządzanych zasobów, które App Hosting tworzy w celu kompilowania i uruchamiania aplikacji internetowej. Możesz tworzyć i wyświetlać App Hosting backendy za pomocą konsoli Firebase lub interfejsu wiersza poleceń Firebase.
Konsola Firebase: w menu Kompilacja wybierz Hosting aplikacji, a następnie Rozpocznij.
Interfejs wiersza poleceń: (wersja 13.15.4 lub nowsza) Aby utworzyć backend, uruchom poniższe polecenie w katalogu głównym projektu lokalnego, podając jako argument identyfikator projektu i preferowany region:
firebase apphosting:backends:create --project PROJECT_ID --location us-central1
W przypadku konsoli lub interfejsu wiersza poleceń postępuj zgodnie z instrukcjami, aby przypisać nazwę do backendu, skonfigurować połączenie z GitHub i skonfigurować te podstawowe ustawienia wdrożenia:
Ustaw katalog główny aplikacji (domyślnie
/).Zwykle znajduje się tam plik
package.json.
Ustaw gałąź na żywo.
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.
Akceptowanie lub odrzucanie wdrożeń automatycznych
Automatyczne wdrażanie jest 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. Pamiętaj, aby nie usuwać ż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 Konsola Google Cloud konsoli Artifact Registry usuń obraz backendu w komponencie „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.