App Hosting został zaprojektowany z myślą o łatwości obsługi i niskich kosztach utrzymania, a ustawienia domyślne są zoptymalizowane pod kątem większości zastosowań. Jednocześnie usługa App Hosting udostępnia narzędzia do zarządzania backendami i konfigurowania ich pod kątem konkretnych potrzeb. W tym przewodniku opisujemy te narzędzia i procesy.
Tworzenie i edytowanie apphosting.yaml
W przypadku zaawansowanej konfiguracji, takiej jak zmienne środowiskowe lub ustawienia środowiska wykonawczego, np. współbieżność, limity procesora i pamięci, musisz utworzyć i edytować 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 go bezpiecznie sprawdzić w systemie kontroli wersji.
Aby utworzyć apphosting.yaml, uruchom to polecenie:
firebase init apphosting
Spowoduje to utworzenie podstawowego pliku początkowego apphosting.yaml z przykładową (zakomentowaną) konfiguracją. Po edycji typowy plik apphosting.yaml może wyglądać tak jak poniżej. Zawiera on ustawienia usługi backendu Cloud Run, niektóre zmienne środowiskowe i odwołania do kluczy tajnych zarządzanych przez Cloud Secret Manager:
# 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 kontekst dotyczący tych przykładowych ustawień.
Konfigurowanie ustawień usługi Cloud Run
Ustawienia apphosting.yaml umożliwiają skonfigurowanie sposobu udostępniania usługi Cloud Run. Dostępne ustawienia usługi Cloud Run są podane w obiekcie runConfig:
cpu– liczba procesorów używanych w każdej instancji obsługującej (domyślnie 0).memoryMiB– ilość pamięci przydzielonej dla każdej instancji obsługującej w MiB (domyślnie 512)maxInstances– maksymalna liczba kontenerów, które mogą być uruchomione w danym momencie (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 obsługująca (domyślnie 80).
Zwróć uwagę na ważną zależność między wartościami cpu i memoryMiB. Pamięć można ustawić na dowolną liczbę całkowitą z zakresu od 128 do 32 768, ale zwiększenie limitu pamięci może wymagać zwiększenia limitów procesora:
- Ponad 4 GiB wymaga co najmniej 2 procesorów
- Ponad 8 GiB wymaga co najmniej 4 procesorów
- Ponad 16 GiB wymaga co najmniej 6 procesorów
- Ponad 24 GiB wymaga co najmniej 8 procesorów
Podobnie wartość cpu wpływa na ustawienia współbieżnoś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
Czasami proces kompilacji wymaga dodatkowej konfiguracji, np. kluczy interfejsu API innych firm lub ustawień, które można dostosować. App Hosting oferuje konfigurację środowiska w apphosting.yaml, która umożliwia przechowywanie i pobieranie tego typu danych na potrzeby projektu.
env:
- variable: STORAGE_BUCKET
value: mybucket.firebasestorage.app
W przypadku aplikacji Next.js pliki dotenv zawierające zmienne środowiskowe będą również działać z App Hosting. Zalecamy używanie apphosting.yaml do szczegółowego sterowania zmiennymi środowiskowymi w dowolnej platformie.
W 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ępność zmiennej środowiskowej tylko do środowiska kompilacji lub tylko do środowiska wykonawczego. Domyślnie jest on dostępny dla obu tych typów.
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 zmienna była dostępna 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 A–Z lub podkreśleń. Niektóre klucze zmiennych środowiskowych są zarezerwowane do użytku wewnętrznego. W plikach konfiguracji nie używaj tych kluczy:
- Każda zmienna zaczynająca się od
X_FIREBASE_ PORTK_SERVICEK_REVISIONK_CONFIGURATION
Zastępowanie skryptów kompilacji i uruchamiania
App Hosting określa polecenie kompilacji i uruchomienia aplikacji na podstawie wykrytego frameworka. Jeśli chcesz użyć niestandardowej kompilacji lub polecenia uruchamiania, 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 i wyłącza aplikację z adapterów platformy oraz wyłącza wszelkie optymalizacje specyficzne dla platformy, które zapewnia App Hosting. Najlepiej używać jej, gdy funkcje aplikacji nie są dobrze obsługiwane przez adaptery. Jeśli chcesz zmienić polecenie kompilacji, ale nadal używać dostarczonych przez nas adapterów, ustaw skrypt kompilacji w package.json, zgodnie z opisem w sekcji App Hosting adaptery platformy.
Zastąp polecenie uruchamiania, jeśli chcesz użyć konkretnego polecenia do uruchomienia aplikacji, które różni się od App Hostingpolecenia wywnioskowanego.
Konfigurowanie danych wyjściowych kompilacji
App Hosting domyślnie optymalizuje wdrażanie aplikacji, usuwając nieużywane pliki wyjściowe wskazane przez platformę. Jeśli chcesz jeszcze bardziej zoptymalizować rozmiar wdrożenia aplikacji lub zignorować optymalizacje domyślne, możesz zastąpić to ustawienie w apphosting.yaml.
outputFiles:
serverApp:
include: [dist, server.js]
Parametr include przyjmuje listę katalogów i plików względem katalogu głównego aplikacji, które są niezbędne do wdrożenia aplikacji. Jeśli chcesz mieć pewność, że wszystkie pliki zostaną zachowane, ustaw include na [.], a wszystkie pliki zostaną wdrożone.
Przechowywanie parametrów tajnych i uzyskiwanie do nich dostępu
Informacje poufne, takie jak klucze interfejsu API, powinny być przechowywane jako obiekty tajne. Możesz odwoływać się do wpisów tajnych w apphosting.yaml, aby uniknąć sprawdzania informacji poufnych w systemie kontroli wersji.
Parametry typu secret to parametry ciągu tekstowego, których wartość jest przechowywana w Cloud Secret Manager.
Zamiast bezpośrednio uzyskiwać wartość, parametry tajne sprawdzają, czy istnieją 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 przypisana do najnowszej dostępnej wersji obiektu tajnego w momencie tworzenia backendu. Jeśli masz wymagania dotyczące wersjonowania parametrów i zarządzania ich cyklem życia, możesz przypinać je do konkretnych wersji za pomocą usługi Cloud Secret Manager. Na przykład, aby przypiąć wersję 5:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
Możesz tworzyć tajne klucze za pomocą polecenia interfejsu wiersza poleceń firebase apphosting:secrets:set. Zostanie wyświetlony monit o dodanie niezbędnych uprawnień. Ten proces umożliwia automatyczne dodanie odwołania do obiektu tajnego w apphosting.yaml.
Aby korzystać z pełnego zestawu funkcji Cloud Secret Manager, możesz użyć konsoli Cloud Secret Manager. W takim przypadku musisz przyznać uprawnienia backendowi App Hosting za pomocą polecenia CLI 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 i jednoznacznej nazwy sieci lub identyfikatora. Używanie identyfikatorów umożliwia przenoszenie danych między środowiskami testowym i produkcyjnym z różnymi łącznikami lub 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 backendami
Polecenia do podstawowego zarządzania backendami App Hosting są dostępne w interfejsie wiersza poleceń Firebase i konsoli Firebase. W tej sekcji opisujemy niektóre z najczęstszych zadań związanych z zarządzaniem, w tym tworzenie i usuwanie backendów.
Utworzenie backendu
App HostingBackend to zbiór zarządzanych zasobów, które App Hosting tworzy na potrzeby budowania i uruchamiania aplikacji internetowej.
Konsola Firebase: w menu Kompilacja wybierz Hosting aplikacji, a potem kliknij Rozpocznij.
Interfejs wiersza poleceń: (wersja 13.15.4 lub nowsza) Aby utworzyć backend, uruchom to polecenie w katalogu głównym lokalnego projektu, podając projectID jako argument:
firebase apphosting:backends:create --project PROJECT_ID
W przypadku konsoli lub interfejsu CLI postępuj zgodnie z instrukcjami, aby wybrać region, skonfigurować połączenie z GitHubem i skonfigurować te podstawowe ustawienia wdrażania:
Ustaw główny katalog aplikacji (domyślnie
/).Zazwyczaj w tym miejscu znajduje się plik
package.json.
Ustaw gałąź na żywo.
Jest to gałąź repozytorium GitHub, która jest wdrażana pod adresem URL na żywo. Często jest to gałąź, do której są scalane gałęzie funkcji lub gałęzie deweloperskie.
Akceptowanie i odrzucanie automatycznych wdrożeń
Automatyczne wdrażanie jest domyślnie włączone. Po zakończeniu tworzenia backendu możesz od razu wdrożyć aplikację w App Hosting.
Przypisz nazwę do backendu.
Usuwanie backendu
Aby całkowicie usunąć backend, najpierw użyj interfejsu Firebase CLI lub Firebase konsoli, a potem ręcznie usuń powiązane zasoby. Uważaj, aby nie usunąć zasobów, które mogą być używane przez inne backendy lub inne aspekty projektu Firebase.
Konsola Firebase: w menu Ustawienia wybierz 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 backendu i usunięcie powiązanej usługi Cloud Run:
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID(Opcjonalnie) Na karcie konsoli Google Cloud dla Artifact Registry usuń obraz backendu w sekcji „firebaseapphosting-images”.
W Cloud Secret Manager usuń wszystkie obiekty tajne, których nazwa zawiera „apphosting”. Zwróć szczególną uwagę na to, aby te obiekty tajne nie były używane przez inne backendy ani inne aspekty projektu Firebase.