Aby skonfigurować zaawansowaną konfigurację, na przykład zmienne środowiskowe lub ustawienia środowiska wykonawczego (np. limit równoczesności, procesora czy pamięci), musisz utworzyć i edytować plik apphosting.yaml
w katalogu głównym aplikacji. Ten plik obsługuje również odwołania do obiektów tajnych zarządzanych za pomocą usługi Cloud Secret Manager, co umożliwia bezpieczne sprawdzanie kontroli źródła.
Oto, jak może wyglądać typowy plik apphosting.yaml
z ustawieniami usługi Cloud Run backendu, zmiennymi środowiskowymi i odwołaniami do obiektów 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.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 na temat tych przykładowych ustawień.
Konfigurowanie ustawień usługi Cloud Run
Ustawienia apphosting.yaml
umożliwiają skonfigurowanie obsługi administracyjnej usługi Cloud Run. Dostępne ustawienia usługi Cloud Run są określone w obiekcie runConfig
:
cpu
– liczba procesorów używanych przez każdą instancję obsługującą (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ą zostać uruchomione jednocześnie (domyślnie wynosi 100 i jest zarządzanych w ramach limitu)minInstances
– liczba kontenerów, które mają zawsze być aktywne (domyślnie 0).concurrency
– maksymalna liczba żądań, które może odebrać każda instancja obsługująca (domyślnie 80).
Zwróć uwagę na ważną zależność między cpu
a memoryMiB
– pamięć można ustawić na dowolną wartość całkowitą z zakresu od 128 do 32 768, ale zwiększenie limitu pamięci może wymagać zwiększenia limitów procesora:
- Powyżej 4 GiB wymagane są co najmniej 2 CPU
- Powyżej 8 GiB wymaga co najmniej 4 CPU
- Ponad 16 GiB wymaga co najmniej 6 CPU
- Ponad 24 GiB wymaga co najmniej 8 CPU
Podobnie wartość cpu
wpływa na ustawienia równoczesnoś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 proces kompilacji wymaga dodatkowej konfiguracji, np. kluczy interfejsu API innej firmy lub ustawień z możliwością dostosowania. App Hosting oferuje konfigurację środowiska w apphosting.yaml
, która umożliwia przechowywanie i pobieranie danych tego typu na potrzeby Twojego projektu.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
W przypadku aplikacji Next.js pliki dotenv zawierające zmienne środowiskowe będą również działać z App Hosting. Zalecamy używanie interfejsu apphosting.yaml
, aby szczegółowo kontrolować zmienne środowiskowe na dowolnej platformie.
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ępność zmiennej środowiskowej tylko do środowiska kompilacji lub tylko do środowiska wykonawczego. Domyślnie ta opcja jest dostępna w obu przypadkach.
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 mogą składać się ze znaków A–Z lub podkreśleń. 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_
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 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 bezpośrednio pobierać wartość, parametry obiektu tajnego 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. Wartość parametru obiektu tajnego dostępnego dla aktywnego backendu jest domyślnie przypięta do najnowszej dostępnej wersji obiektu tajnego w momencie tworzenia backendu. Jeśli masz wymagania dotyczące obsługi wersji i zarządzania cyklem życia parametrów, możesz przypiąć je do określonych wersji za pomocą usługi Cloud Secret Manager. Na przykład w celu przypięcia wersji 5:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
Obiekty tajne możesz tworzyć za pomocą polecenia interfejsu wiersza poleceń firebase apphosting:secrets:set
. Pojawi się prośba o dodanie wymaganych uprawnień. Umożliwia to automatyczne dodanie odwołania do obiektu tajnego do apphosting.yaml
.
Aby korzystać z pełnego pakietu funkcji usługi Cloud Secret Manager, możesz używać 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 przebieg zadań
wygląda tak:
- 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
.