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 Twoimi potrzebami. W tym przewodniku opisaliśmy te narzędzia i procesy.
Tworzenie i edytowanie apphosting.yaml
Aby skonfigurować zaawansowane ustawienia, takie jak zmienne środowiskowe czy ustawienia czasu wykonywania, np. dotyczące współbieżności, procesora i limitów 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, zmienne środowiskowe i odniesienia 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 być ustawiana na dowolną wartość całkowitą z zakresu od 128 do 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ównoległości. Jeśli ustawisz wartość mniejszą niż 1 procesor, musisz ustawić współbieżność na 1, a procesor będzie przydzielany tylko podczas przetwarzania żądań.
Konfigurowanie środowiska
Czasami w procesie kompilacji może być potrzebna dodatkowa konfiguracja, np. klucze interfejsu API innych firm lub ustawienia do dostosowania. App Hosting oferuje konfigurację środowiska apphosting.yaml do przechowywania i pobierania tego typu danych w projekcie.
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_ PORTK_SERVICEK_REVISIONK_CONFIGURATION
Zastępowanie skryptów kompilacji i uruchamiania
App Hosting wywnioskowuje polecenie kompilacji i uruchomienia aplikacji na podstawie wykrytego frameworka. Jeśli chcesz użyć niestandardowego polecenia kompilacji lub uruchomienia, możesz zastąpić domyślne ustawienia App Hosting w apphosting.yaml.
scripts:
buildCommand: next build --no-lint
runCommand: node dist/index.js
Zastąpienie polecenia kompilacji ma pierwszeństwo przed innymi poleceniami kompilacji. Umożliwia to wyłączenie w aplikacji adapterów frameworka i wszystkich optymalizacji frameworka, które zapewnia App Hosting. Najlepiej sprawdza się, gdy funkcje aplikacji nie są dobrze obsługiwane przez adaptery. Jeśli chcesz zmienić polecenie kompilacji, ale nadal chcesz używać naszych adapterów, ustaw skrypt kompilacji w package.json zgodnie z opisem w sekcji App Hosting adaptery frameworka.
Użyj zastąpienia polecenia wykonania, jeśli chcesz użyć określonego polecenia do uruchomienia aplikacji, które jest inne niż polecenie wywnioskowane (App Hosting).
Konfigurowanie danych wyjściowych kompilacji
App Hosting domyślnie optymalizuje wdrożenia aplikacji, usuwając nieużywane pliki wyjściowe zgodnie z wytycznymi platformy. Jeśli chcesz jeszcze bardziej zoptymalizować rozmiar aplikacji lub zignorować domyślne optymalizacje, możesz to zrobić w sekcji apphosting.yaml.
outputFiles:
serverApp:
include: [dist, server.js]
Parametr include przyjmuje listę katalogów i plików w relacji do katalogu głównego aplikacji, które są niezbędne do wdrożenia aplikacji. Jeśli chcesz mieć pewność, że wszystkie pliki zostaną zachowane, ustaw wartość parametru include na [.], a wszystkie pliki zostaną wdrożone.
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 tajemnic 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ą usługi 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 daje Ci możliwość automatycznego dodawania 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.
Konfigurowanie dostępu do VPC
Twój backend App Hosting może łączyć się z siecią prywatnego środowiska wirtualnego w chmurze (VPC). Więcej informacji i przykład znajdziesz w artykule Łączenie Firebase App Hosting z siecią VPC.
Aby skonfigurować dostęp, użyj mapowania vpcAccess w pliku apphosting.yaml.
Użyj pełnej nazwy sieci lub identyfikatora. Korzystanie z identyfikatorów umożliwia przenoszenie danych między środowiskiem testowym a produkcyjnym z różnymi złączami/sieciami.
runConfig:
vpcAccess:
egress: PRIVATE_RANGES_ONLY # Default value
networkInterfaces:
# Specify at least one of network and/or subnetwork
- network: my-network-id
subnetwork: my-subnetwork-id
Zarządzanie backendem
Polecenia do podstawowego zarządzania backendami App Hosting są dostępne w interfejsie wiersza poleceń Firebase i konsoli Firebase. W tej sekcji opisaliśmy 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 tworzenia i uruchamiania aplikacji internetowej.
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 lokalnej lokalizacji 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 CLI postępuj zgodnie z instrukcjami, aby wybrać region, skonfigurować połączenie z GitHubem i skonfigurować te podstawowe ustawienia wdrożenia:
Ustaw katalog główny aplikacji (domyślnie
/).Zwykle znajduje się tam plik
package.json.
Ustaw gałąź produkcyjną.
To jest gałąź w Twoim repozytorium GitHub, która jest wdrażana do adresu URL witryny. Często jest to gałąź, do której scalane są gałęzie funkcji lub gałęzie rozwoju.
Akceptowanie lub odrzucanie wdrożeń automatycznych
Automatyczne wdrożenia są domyślnie włączone. Po zakończeniu tworzenia backendu możesz od razu wdrożyć aplikację na App Hosting.
Nazwij backend.
Usunięcie backendu
Aby całkowicie usunąć backend, najpierw użyj interfejsu wiersza poleceń Firebase lub konsoli Firebase, aby go usunąć, a potem ręcznie usuń powiązane zasoby, zwracając szczególną uwagę, aby nie usunąć żadnych zasobów, których mogą używać inne backendy lub inne aspekty projektu Firebase.
Konsola Firebase: w menu Ustawienia kliknij Usuń backend.
Interfejs wiersza poleceń: (wersja 13.15.4 lub nowsza)
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) W konsoli Google Cloud na karcie Artifact Registry usuń obraz backendu w katalogu „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.