Konfigurowanie backendów App Hosting i zarządzanie nimi

Urządzenie App Hosting zostało zaprojektowane z myślą o łatwej obsłudze i łatwym utrzymaniu. z ustawieniami domyślnymi zoptymalizowanymi pod kątem większości przypadków użycia. Jednocześnie App Hosting udostępnia narzędzia do zarządzania backendami i ich konfigurowania dostosowane do Twoich potrzeb. W tym przewodniku opisano te narzędzia i procesy.

Konfigurowanie backendu

Konfiguracja zaawansowana, np. zmienne środowiskowe lub ustawienia środowiska wykonawczego takich jak równoczesność, CPU i limity pamięci, musisz utworzyć i edytować apphosting.yaml w katalogu głównym aplikacji. Ten plik także obsługuje odwołania do zarządzanych obiektów tajnych z Cloud Secret Manager, co zapewnia bezpieczne sprawdzanie kontroli źródła.

Tak może wyglądać typowy plik apphosting.yaml z ustawieniami dla usługi Cloud Run backendu, niektóre zmienne środowiskowe i niektóre odwołania 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 ten temat. ustawieniach.

Skonfiguruj ustawienia usługi Cloud Run

Za pomocą ustawień apphosting.yaml możesz określić, jak Cloud Run jest dostępna jest obsługiwane. Dostępne ustawienia Usługa Cloud Run jest dostępna w obiekcie runConfig:

  • cpu – liczba procesorów używanych przez każdą instancję obsługującą (domyślnie 0).
  • memoryMiB – ilość pamięci przydzielonej do każdej instancji obsługującej, wyrażona w MiB. (domyślnie 512)
  • maxInstances – maksymalna liczba kontenerów, które mają zostać uruchomione jednocześnie (domyślnie) ze 100 i zarządzane w ramach limitu)
  • minInstances – liczba kontenerów, które mają zawsze być aktywne (domyślnie 0).
  • concurrency – maksymalna liczba żądań, które może obsłużyć każda instancja obsługująca odbieranie (domyślnie 80).

Zwróć uwagę na ważną relację między cpu a memoryMiB. można ustawić pamięć do dowolnej wartości całkowitej z zakresu od 128 do 32 768, ale zwiększenie limitu pamięci może wymagają 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ść mniej niż 1 CPU, musisz ustawić równoczesność na 1, aby procesor został przydzielony tylko podczas przetwarzania żądań.

Konfigurowanie środowiska kompilacji

Czasami proces kompilacji wymaga dodatkowej konfiguracji, takiej jak kluczy interfejsu API firmy zewnętrznej i ustawień z możliwością dostosowania. Środowisko ofert (App Hosting) konfigurację w apphosting.yaml, aby ją zapisać i pobrać. odpowiedni typ danych.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com

W przypadku aplikacji Next.js pliki dotenv zawierające zmiennych środowiskowych również współpracy z App Hosting. Zalecamy użycie apphosting.yaml, aby uzyskać bardziej szczegółowe informacje lub za pomocą dowolnej platformy.

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ć ze zmienną środowiskową, tak aby była dostępna tylko dla środowiska kompilacji lub dostępna tylko w środowisku wykonawczym. 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, 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. Nie używaj żadnej z tych opcji w plikach konfiguracyjnych:

  • 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. Dostępne opcje odwołuj się do obiektów tajnych w apphosting.yaml, aby uniknąć sprawdzania informacji poufnych w kontrolę źródła.

Parametry typu secret reprezentują parametry ciągu znaków, które mają wartość przechowywane w usłudze Cloud Secret Manager. Zamiast bezpośrednie pobieranie wartości, sprawdzanie parametrów obiektów tajnych pod kątem obecności w Cloud Secret Manager i wczytać wartości podczas wdrażania.

  -   variable: API_KEY
      secret: myApiKeySecret

Obiekty tajne w usłudze Cloud Secret Manager mogą mieć wiele wersji. Domyślnie atrybut wartość tajnego parametru dostępnego dla aktywnego backendu jest przypięta do najnowszą dostępną wersję obiektu tajnego w momencie tworzenia backendu. Jeśli mają wymagania dotyczące obsługi wersji i zarządzania cyklem życia parametrów, do określonych wersji za pomocą usługi Cloud Secret Manager. Na przykład, aby przypiąć wersja 5:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Obiekty tajne możesz tworzyć za pomocą polecenia interfejsu wiersza poleceń firebase apphosting:secrets:set. i pojawi się prośba o przyznanie wymaganych uprawnień. Ten proces daje Ci automatycznego dodawania odwołania do obiektu tajnego do apphosting.yaml.

Aby korzystać z pełnego pakietu funkcji Cloud Secret Manager, możesz zamiast tego używać w konsoli Cloud Secret Manager. Aby to zrobić, musisz przyznać do backendu 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 rozważyć użycie pakietu SDK Firebase, aby zachować jest synchronizowany między klientem a serwerem. Może to być ułatwione dzięki wdrożeniu FirebaseServerApp za pomocą skryptu service worker. Podstawowe przepływ zadań jest:

  1. Wdrażanie skryptu service worker który dodaje odpowiednie nagłówki aplikacji w żądaniach wysyłanych do serwera.
  2. Pobierz nagłówki z żądania na serwer i przekonwertuj je na uwierzytelnianie użytkownik z domeną FirebaseServerApp.

Zarządzaj backendami

Polecenia podstawowego zarządzania backendami App Hosting są podany w interfejsie wiersza poleceń Firebase. Niektóre Operacje są też dostępne w konsoli Firebase. Ta sekcja będzie: opisują niektóre z najczęstszych zadań związanych z zarządzaniem, w tym tworzenie przez usuwanie backendów.

Utworzenie backendu

Backend App Hosting to zbiór zarządzanych zasobów, które App Hosting tworzy i uruchamia Twoją aplikację internetową. Możesz tworzyć i wyświetlać listy App Hosting backendów za pomocą konsoli Firebase lub Interfejs wiersza poleceń Firebase.

Konsola Firebase: w menu Tworzenie wybierz App Hosting (Hosting aplikacji), a następnie Rozpocznij

Interfejs wiersza poleceń: (wersja 3.9 lub nowsza) Aby utworzyć backend, uruchom to polecenie z katalogu głównego projektu lokalnego, dodając identyfikator projektu jako argument (w przypadku podglądu obsługiwany jest tylko region us-central1):

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, aby skonfiguruj połączenie z GitHubem, i skonfigurować te podstawowe ustawienia wdrożenia:

  • Ustaw katalog główny aplikacji (domyślnie /).

    Zwykle w tym miejscu znajduje się plik package.json.

  • Ustaw aktywną gałąź.

    To gałąź repozytorium GitHub, które jest wdrażane w adresu URL wersji opublikowanej. Często jest to gałąź, w której występują gałęzie lub zabudowy, gałęzie są scalone.

  • Akceptowanie lub odrzucanie wdrożeń automatycznych

    Wdrażanie automatyczne jest domyślnie włączone. Po utworzeniu backendu możesz wybrać opcję natychmiastowego wdrożenia aplikacji w App Hosting.

Usunięcie backendu

Aby całkowicie usunąć backend, najpierw użyj interfejsu wiersza poleceń Firebase, a potem ręcznie powiązane zasoby. Zachowaj szczególną ostrożność, aby nie usunąć żadnych zasobów, które mogą być używane przez inne backendy lub inne aspekty Twojego projektu Firebase.

  1. Uruchom poniższe polecenie, aby usunąć backend App Hosting. Spowoduje to wyłączenie wszystkich domen w backendzie i usunięcie powiązanych Usługa Cloud Run:

    firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1

  2. (Opcjonalnie) W polu Karta Google Cloud Console dla domeny Artifact Registry. usuń obraz backendu w kolumnie „firebaseapphosting-images”.

  3. W usłudze Cloud Secret Manager usuń wszystkie obiekty tajne z „apphostingiem” w tajnej nazwie, nadając specjalnym dbaj o to, aby te obiekty tajne nie były używane przez inne backendy inne aspekty projektu Firebase.