Konfigurowanie backendów App Hosting i zarządzanie nimi

App Hosting został zaprojektowany z myślą o łatwości obsługi i niskich wymaganiach konserwacyjnych, a jego domyślne ustawienia są zoptymalizowane pod kątem większości przypadków użycia. Jednocześnie 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.

Ustawianie i aktualizowanie zmiennych środowiskowych i obiektów tajnych

App Hosting umożliwia używanie zmiennych środowiskowych w przypadku wartości konfiguracyjnych, które nie są poufne, oraz obiektów tajnych w przypadku parametrów poufnych, takich jak klucze interfejsu API, dane logowania do bazy danych i tokeny usługi.

  • Standardowe zmienne środowiskowe: używane do konfiguracji zwykłego tekstu, który nie zawiera danych wrażliwych (np. publicznych adresów URL interfejsu API, flag funkcji lub celów kompilacji). Wartości są widoczne dla wszystkich użytkowników projektu.
  • Obiekty tajne: używane w przypadku parametrów poufnych (takich jak tajne klucze klienta OAuth, tokeny interfejsu API lub hasła do baz danych). Obiekty tajne są obsługiwane przez Cloud Secret Manager. Wartości obiektów tajnych są chronione i nigdy nie są wyświetlane w konsoli Firebase jako zwykły tekst. Zamiast tego konsola udostępnia precyzyjne linki do wyświetlania wartości obiektów tajnych i zarządzania nimi bezpośrednio w usłudze Cloud Secret Manager.

Parametry środowiska możesz definiować i zarządzać nimi na 2 uzupełniające się sposoby:

  • Konsola Firebase: szybko dodawaj, edytuj i dołączaj obiekty tajne lub zmienne dynamicznie podczas początkowego tworzenia backendu lub po wdrożeniu w ustawieniach backendu.

  • Najpierw kod (apphosting.yaml): zadeklaruj zmienne środowiskowe i odwołania do obiektów tajnych w pliku konfiguracji repozytorium na potrzeby wdrożeń z kontrolą wersji lub użyj apphosting.<env>.yaml, aby ustawić różne wartości dla różnych środowisk.

Konsola Firebase

Zrzut ekranu okna konsoli Firebase, w którym dodaje się zmienne środowiskowe

apphosting.yaml 

env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
  - variable: API_KEY
    secret: myApiKeySecret

Zarządzanie zmiennymi i obiektami tajnymi w konsoli Firebase

Zmienne środowiskowe i obiekty tajne możesz skonfigurować w konsoli Firebase podczas tworzenia backendu lub w dowolnym momencie w ustawieniach backendu. Zmiany zapisane bez wdrażania zaczną obowiązywać przy następnym wdrożeniu i nie wpłyną na bieżące.

Konfigurowanie zmiennych i obiektów tajnych podczas tworzenia backendu

Podczas tworzenia nowego backendu App Hosting w konsoli Firebase możesz skonfigurować standardowe zmienne środowiskowe i obiekty tajne w kroku Skonfiguruj backend kreatora konfiguracji:

  1. W konsoli Firebase otwórz Hosting i bezserwerowe > App Hosting i kliknij Utwórz backend.
  2. Wykonaj początkowe kroki kreatora, aby wybrać region podstawowy i repozytorium kodu.
  3. W sekcji Skonfiguruj backend znajdź karty Zmienne środowiskowe i Obiekty tajne, które można rozwijać. Możesz na nich dodawać standardowe zmienne i dołączać obiekty tajne.
  4. Ukończ kreator tworzenia backendu i kliknij Zakończ i wdróż.

Zarządzanie zmiennymi i obiektami tajnymi w ustawieniach backendu

Zmienne środowiskowe i obiekty tajne aktywnych backendów możesz wyświetlać, dodawać, edytować i usuwać w panelu ustawień backendu:

  1. W konsoli Firebase wybierz backend App Hosting i otwórz Ustawienia > Środowisko.
  2. Sprawdź istniejące konfiguracje w tabeli Zmienne środowiskowe:
    • Zmienne standardowe: wartości są wyświetlane jako zwykły tekst w blokach kodu, które można skopiować.
    • Obiekty tajne: wyświetlane jako klikalny link z nazwą obiektu tajnego (który otwiera Cloud Secret Manager w konsoli Google Cloud) oraz jego wersją docelową (np. latest lub konkretny numer wersji, np. 2).
  3. Aby dodać zmienną lub obiekt tajny:
    1. Kliknij Dodaj domenę.
    2. W kroku 1: Wybierz typ wybierz Standardowa zmienna środowiskowa (w przypadku danych niepoufnych widocznych dla wszystkich członków projektu) lub Obiekt tajny (w przypadku kluczy interfejsu API i poufnych danych uwierzytelniających z ograniczonym dostępem), a następnie kliknij Dalej.
    3. W kroku 2: Skonfiguruj ustawienia wpisz nazwę klucza i wartość w postaci zwykłego tekstu (w przypadku zmiennych standardowych) lub wybierz identyfikator obiektu tajnego i wersję (w przypadku obiektów tajnych).
    4. Zapisz zmiany, korzystając z jednej z tych opcji:
      • Zapisz i wdróż: natychmiast aktualizuje konfigurację backendu i wyzwala nową kompilację oraz wdrożenie.
      • Tylko zapisz (kliknij strzałkę w dół obok opcji Zapisz i wdróż): zapisuje zmiany konfiguracji bez natychmiastowego wdrażania. Zaktualizowane ustawienia zaczną obowiązywać przy następnym wdrożeniu.
  4. Aby edytować lub usunąć istniejący wpis, kliknij menu czynności Więcej czynności (...) na końcu wiersza:
    • Wybierz Edytuj, aby zmodyfikować klucz, wartość, mapowanie obiektu tajnego lub wersję, a następnie kliknij Zapisz i wdróż lub Tylko zapisz.
    • Kliknij Usuń i potwierdź usunięcie w oknie dialogowym.

Przenoszenie zmiennych z dotenv plików

W przypadku aplikacji Next.js pliki dotenv zawierające zmienne środowiskowe działają z App Hosting.

Podczas tworzenia lub aktualizowania backendu możesz przenieść zmienne środowiskowe z pliku dotenv do konsoli Firebase, kopiując i wklejając całą zawartość pliku dotenv do pierwszego pola Klucz w formularzu Dodaj nowy w sekcji Ustawienia > Środowisko.

Wszystkie zmienne środowiskowe skopiowane w ten sposób są automatycznie formatowane w formularzu bez konieczności wpisywania każdej z nich osobno, o ile dane wejściowe są sformatowane w standardowy sposób KEY=value:

KEY1=value1
KEY2=value2
KEY3=value3

W przypadku złożonej lub szczegółowej kontroli zmiennych środowiskowych w dowolnej platformie zalecamy użycie apphosting.yaml.

Zarządzanie zmiennymi i obiektami tajnymi w apphosting.yaml

W przypadku przepływów pracy opartych na kodzie zadeklaruj standardowe zmienne środowiskowe i odwołania do obiektów tajnych pod kluczem env: w pliku konfiguracji apphosting.yaml repozytorium projektu (patrz Tworzenie i edytowanie pliku apphosting.yaml).

env:
  # Standard environment variables
  - variable: PUBLIC_API_URL
    value: https://api.example.com
    availability:
      - BUILD
      - RUNTIME
  - variable: FEATURE_FLAG_NEW_UI
    value: "true"

  # Secret references backed by Cloud Secret Manager
  - variable: DATABASE_URL
    secret: projects/PROJECT_ID/secrets/db-connection-string/versions/latest
  - variable: GEMINI_API_KEY
    secret: myGeminiApiKeySecret@1

Każdy wpis w env: obsługuje te pola:

  • variable: nazwa zmiennej środowiskowej udostępnionej procesowi aplikacji.
  • value: wartość ciągu znaków w postaci zwykłego tekstu (w przypadku standardowych zmiennych środowiskowych).
  • secret: odwołanie do obiektu tajnego w Cloud Secret Manager (w przypadku obiektów tajnych). Możesz użyć krótkiej nazwy obiektu tajnego (np. myGeminiApiKeySecret lub przypiętego myGeminiApiKeySecret@1) albo pełnej ścieżki zasobu (projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION). Więcej informacji znajdziesz w artykule na temat przechowywania parametrów obiektów tajnych i uzyskiwania do nich dostępu.
  • availability: określa, czy zmienna lub obiekt tajny są dostępne podczas fazy BUILD, w RUNTIME czy w obu tych przypadkach.

Ustawianie zmiennej dostępności

Zmienne środowiskowe i obiekty tajne skonfigurowane w konsoli Firebase są dostępne zarówno podczas kompilacji, jak i w czasie działania. Jest to też działanie domyślne w przypadku wpisów zdefiniowanych w parametrze apphosting.yaml, chyba że zawęzisz zakres za pomocą właściwości availability. W apphosting.yaml (ale nie w konsoli) możesz ograniczyć zmienną lub obiekt tajny tylko do środowiska kompilacji (BUILD) lub tylko do środowiska wykonawczego (RUNTIME).

Uzyskiwanie dostępu do zmiennych i obiektów tajnych w kodzie aplikacji

Niezależnie od tego, czy zmienne środowiskowe i obiekty tajne są skonfigurowane w konsoli Firebase czy w apphosting.yaml, są one udostępniane środowisku wykonawczemu aplikacji jako standardowe zmienne środowiskowe (np. process.env w Node.js).

// Accessing a standard environment variable
const apiUrl = process.env.PUBLIC_API_URL;

// Accessing a secret
const apiKey = process.env.GEMINI_API_KEY;

export async function fetchData() {
  const response = await fetch(`${apiUrl}/data`, {
    headers: {
      'Authorization': `Bearer ${apiKey}`
    }
  });
  return response.json();
}
  • Dostęp po stronie serwera: wszystkie zmienne środowiskowe i obiekty tajne są bezpiecznie dostępne w kontekstach wykonywania po stronie serwera (takich jak komponenty serwera Next.js, trasy interfejsu API czy moduły obsługi backendu Node.js).

  • Udostępnianie po stronie klienta: aby udostępnić standardowe zmienne środowiskowe przeglądarce w platformach takich jak Next.js, upewnij się, że klucz zmiennej jest zgodny z konwencjami platformy (np. ma prefiks NEXT_PUBLIC_).

    env:
  - variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      - BUILD
      - RUNTIME

Hierarchia zmiennych

Firebase App Hosting stosuje zmienne środowiskowe i obiekty tajne w kolejności pierwszeństwa na podstawie ich źródła. Konfiguracje ustawione w konsoli Firebase zawsze zastępują parametry zadeklarowane w plikach apphosting.yaml i dotenv. Jeśli zmienna środowiskowa lub klucz tajny o tej samej nazwie istnieje zarówno w apphosting.yaml, jak i w konsoli Firebase, podczas kompilacji i wykonywania w czasie działania pierwszeństwo ma wartość z konsoli.

Oto pełna kolejność pierwszeństwa:

  1. Konsola Firebase → zmienne i obiekty tajne ustawione w konsoli.
  2. apphosting.<env>.yaml – zmienne i obiekty tajne określone w pliku YAML dla konkretnego środowiska, takim jak apphosting.staging.yaml (patrz Wdrażanie wielu środowisk).
  3. apphosting.yaml → zmienne i obiekty tajne określone w pliku apphosting.yaml
  4. System Firebase – zmienne ustawione przez Firebase, które zawierają wartości dla FIREBASE_CONFIG lub FIREBASE_WEBAPP_CONFIG, a także zmienne środowiskowe, które ustawiają nazwy hostów i porty dla aplikacji SSR (ustawione przez adaptery App Hosting w bundle.yaml).

Automatycznie wypełniane zmienne środowiskowe

Istnieją zmienne środowiskowe, które są automatycznie wypełniane przez App Hosting. Obejmują one zmienne wypełniane przez Google Cloud, a także zmienne środowiskowe Firebase, gdy podczas konfiguracji w backendzie ustawiono appId:

  • FIREBASE_CONFIG: (dostępne w środowiskach kompilacji i wykonawczym) zawiera te informacje o konfiguracji projektu w Firebase:

    {
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "storageBucket": "PROJECT_ID.firebasestorage.app",
  "projectId": "PROJECT_ID"
}

    Ta konfiguracja jest stosowana automatycznie, gdy inicjujesz pakiet Admin SDK Firebase bez argumentów.

  • FIREBASE_WEBAPP_CONFIG: (dostępne tylko w środowisku kompilacji) zawiera te informacje o konfiguracji projektu w Firebase:

    {
  "apiKey": "API_KEY",
  "appId": "APP_ID",
  "authDomain": "AUTH_DOMAIN.firebaseapp.com",
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "messagingSenderId": "PROJECT_NUMBER",
  "projectId": "PROJECT_ID",
  "storageBucket": "PROJECT_ID.firebasestorage.app"
}</span>

    Pakiet SDK Firebase JS automatycznie sprawdza tę zmienną środowiskową FIREBASE_WEBAPP_CONFIG w skrypcie postinstall podczas kompilacji, co pozwala zainicjować pakiet SDK klienta bez żadnych argumentów.

Więcej informacji o tym, jak używać tych zmiennych środowiskowych do inicjowania pakietów SDK, znajdziesz w artykule Automatyczne inicjowanie pakietu Firebase Admin SDK i pakietów SDK do aplikacji internetowych.

Pamiętaj, że wartości w rzeczywistej konfiguracji Firebase będą odpowiadać konkretnym zasobom udostępnionym w projekcie.

Hierarchia zmiennych

Firebase App Hosting stosuje zmienne w kolejności pierwszeństwa na podstawie ich źródła. Na przykład wartości ustawione w konsoli Firebase zawsze zastępują wartości ustawione w plikach apphosting.yaml i dotenv, czyli mają nad nimi pierwszeństwo.

Oto pełna kolejność pierwszeństwa:

  1. Konsola Firebase → zmienne ustawione w konsoli.
  2. apphosting.<env>.yaml – zmienne określone w pliku YAML dla konkretnego środowiska, np. apphosting.staging.yaml (patrz Wdrażanie wielu środowisk).
  3. apphosting.yaml → zmienne określone w pliku apphosting.yaml
  4. System Firebase – zmienne ustawione przez Firebase, które zawierają wartości dla firebase_config json lub firebase_webapp_config, a także zmienne środowiskowe, które ustawiają nazwy hostów i porty dla aplikacji SSR (ustawiane przez adaptery App Hosting w bundle.yaml)

Zarezerwowane nazwy i ograniczenia

Zmienne środowiskowe zdefiniowane w Cloud Runumowie dotyczącej środowiska wykonawczego kontenera są zarezerwowane i nie można ich ustawić.

Zmienne środowiskowe udostępniane przez środowisko, inne niż te, które są ustawiane automatycznie, mogą ulec zmianie w przyszłych wersjach środowiska wykonawczego. Zalecamy, aby nie polegać na zmiennych środowiskowych, które nie zostały ustawione bezpośrednio, ani ich nie modyfikować. Aby uniknąć konfliktów, warto rozważyć dodanie do wszystkich zmiennych środowiskowych unikalnego klucza.

Niektóre klucze zmiennych środowiskowych są zarezerwowane do użytku wewnętrznego. Nie używaj w plikach konfiguracji żadnego z tych kluczy:

  • puste ciągi znaków (""),
  • Klucze zawierające znak „=”
  • Klucze zaczynające się od X_FIREBASE_, X_GOOGLE_ lub CLOUD_RUN_
  • PORT
  • K_SERVICE
  • K_REVISION
  • K_CONFIGURATION
  • Zduplikowane klucze

Tworzenie i edytowanie: apphosting.yaml

Aby skonfigurować zaawansowane ustawienia, takie jak obiekty tajne lub ustawienia środowiska wykonawczego, np. równoczesność, procesor i limity pamięci, musisz utworzyć i edytować plik apphosting.yaml w katalogu głównym aplikacji. Ten plik obsługuje odwołania do obiektów tajnych zarządzanych za pomocą Cloud Secret Managera, 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 apphosting.yaml z przykładową (skomentowaną) konfiguracją. Po wprowadzeniu zmian typowy plik apphosting.yaml może wyglądać tak jak poniżej, z ustawieniami usługi Cloud Run backendu, niektórymi zmiennymi środowiskowymi i niektórymi 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.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 sposobu udostępniania usługi Cloud Run. Dostępne ustawienia usługi Cloud Run są podane w obiekcie runConfig:

Pamiętaj, że cpu, memoryMiB i concurrency mają współzależne limity (na przykład konfiguracje z większą ilością pamięci wymagają wyższych minimalnych limitów procesora, a procesory ułamkowe wymagają równoczesności na poziomie 1). Zapoznaj się z dokumentacją Cloud Run dotyczącą limitów procesora i limitów pamięci, aby poznać prawidłowe zakresy i wymagane kombinacje.

Zastępowanie skryptów kompilacji i uruchamiania

App Hosting określa polecenie kompilacji i uruchomienia aplikacji na podstawie wykrytej platformy. 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 i powoduje, że aplikacja nie korzysta z adapterów platformy i wyłącza wszelkie optymalizacje specyficzne dla platformy, które zapewnia App Hosting. Najlepiej używać go, gdy funkcje aplikacji nie są dobrze obsługiwane przez adaptery. Jeśli chcesz zmienić polecenie kompilacji, ale nadal używać dostarczonych adapterów, ustaw skrypt kompilacji w pliku package.json zgodnie z opisem w sekcji Adaptery platformy App Hosting.

Użyj zastąpienia polecenia uruchamiania, gdy chcesz użyć konkretnego polecenia do uruchomienia aplikacji, które różni się od polecenia wywnioskowanego przez App Hosting.

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 dodatkowo zoptymalizować rozmiar wdrożenia aplikacji lub zignorować domyślne optymalizacje, możesz to zmienić w pliku 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 jej wdrożenia. Jeśli chcesz mieć pewność, że wszystkie pliki zostaną zachowane, ustaw parametr 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. Możesz dołączyć obiekty tajne do backendu w konsoli Firebase lub odwołać się do nich w apphosting.yaml, aby uniknąć sprawdzania informacji poufnych w systemie kontroli źródeł.

Parametry typu secret reprezentują parametry tekstowe, których wartość jest przechowywana w Cloud Secret Manager. Zamiast uzyskiwać wartość bezpośrednio, parametry obiektów tajnych sprawdzają, czy istnieją w usłudze Cloud Secret Manager, i wczytują wartości podczas wdrażania.

env:
  - variable: API_KEY
    secret: myApiKeySecret

Obiekty tajne w usłudze Cloud Secret Manager mogą mieć wiele wersji. Domyślnie wartość parametru obiektu tajnego dostępnego dla aktywnego backendu jest przypięta do najnowszej dostępnej wersji obiektu tajnego w momencie utworzenia backendu. Jeśli masz wymagania dotyczące obsługi wersji i zarządzania cyklem życia parametrów, możesz przypiąć konkretne wersje w konsoli Firebase lub w apphosting.yaml. Aby na przykład przypiąć wersję 5 w apphosting.yaml:

env:
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Możesz utworzyć obiekty tajne za pomocą polecenia Firebase interfejsu wiersza poleceń firebase apphosting:secrets:set. Pojawi się prośba o dodanie niezbędnych uprawnień. Ten proces umożliwia automatyczne dodanie odwołania do obiektu tajnego do apphosting.yaml.

Przyznawanie dostępu do Cloud Secret Managera

Aby usługa App Hosting mogła pobierać wartości obiektów tajnych podczas kompilacji i wdrażania środowiska wykonawczego, konto usługi backendu App Hosting musi mieć uprawnienia dostępu do usługi Cloud Secret Manager.

Jeśli tworzysz obiekty tajne za pomocą konsoli Cloud Secret Manager lub interfejsu wiersza poleceń gcloud zamiast firebase apphosting:secrets:set, przyznaj dostęp do backendu za pomocą interfejsu wiersza poleceń Firebase:

firebase apphosting:secrets:grantaccess SECRET_NAME

Możesz też przypisać rolę uzyskującego dostęp do obiektów tajnych w usłudze Secret Manager (roles/secretmanager.secretAccessor) agentowi usługi App Hosting (service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com) lub wykonawczemu kontu usługi backendu za pomocą interfejsu wiersza poleceń gcloud:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

Dostęp do konsoli i uprawnienia oparte na rolach

Konsola Firebase dynamicznie ogranicza funkcje zarządzania środowiskiem i Secret Managerem na podstawie uprawnień użytkownika IAM:

  • Rola Przeglądający: użytkownicy z uprawnieniami tylko do odczytu mogą wyświetlać istniejące ustawienia konfiguracji, ale nie mogą wprowadzać zmian.
    • Podczas tworzenia backendu przycisk Utwórz backend jest wyłączony.
    • W sekcji Ustawienia > Środowisko w backendzie przycisk Dodaj nowy jest wyłączony, a menu wierszy Więcej działań (...) są ukryte.
  • Brak uprawnień do Secret Managera: użytkownicy, którzy nie mają uprawnień do interakcji z Cloud Secret Managerem, zobaczą w konsoli komunikat ostrzegawczy (Poproś właściciela projektu o uprawnienia do dodawania obiektów tajnych):
    • Podczas tworzenia backendu karta Obiekty tajne jest wyłączona.
    • W sekcji Ustawienia > Środowisko w backendzie opcja Obiekt tajny jest wyłączona po kliknięciu Dodaj nowy, a niektóre opcje w menu wiersza Więcej działań (...) są ukryte w przypadku istniejących wpisów obiektów tajnych.

Konfigurowanie dostępu do VPC

Backend App Hosting może łączyć się z siecią prywatnego środowiska wirtualnego w chmurze (VPC). Więcej informacji i przykład znajdziesz w artykule o łączeniu 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/oprogramowania sprzęgającego lub identyfikatora. Używanie identyfikatorów umożliwia przenoszenie danych między środowiskami testowymi i środowiskami produkcyjnymi z różnymi oprogramowaniami sprzęgającymi i sieciami.

Konfiguracja bezpośredniego połączenia VPC dla ruchu wychodzącego (apphosting.yaml):

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

Konfiguracja bezserwerowego oprogramowania sprzęgającego (apphosting.yaml):

runConfig:
  vpcAccess:
    egress: ALL_TRAFFIC
    connector: connector-id

Zarządzanie backendami

Polecenia do podstawowego zarządzania backendami App Hosting są dostępne w konsoli Firebase i interfejsie wiersza poleceń Firebase. W tej sekcji opisano niektóre z częstszych zadań związanych z zarządzaniem, w tym tworzenie i usuwanie backendów.

Utworzenie backendu

Backend App Hosting to zbiór zasobów zarządzanych, które App Hosting tworzy, aby utworzyć i uruchomić aplikację internetową.

Konsola Firebase: otwórz Hosting i bezserwerowość > App Hosting, a następnie kliknij Utwórz backend (jeśli jest to pierwszy backend w projekcie Firebase, kliknij Rozpocznij).

Firebase CLI: (wersja 13.15.4 lub nowsza) Aby utworzyć backend, uruchom to polecenie w katalogu głównym lokalnego projektu, podając identyfikator projektu jako argument:

firebase apphosting:backends:create --project PROJECT_ID

W konsoli lub interfejsie wiersza poleceń postępuj zgodnie z instrukcjami, aby wybrać region, skonfigurować połączenie z GitHubem i skonfigurować te podstawowe ustawienia wdrażania:

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

    Zwykle jest to miejsce, w którym znajduje się plik package.json.

  • Ustawianie gałęzi aktywnej

    Jest to gałąź repozytorium GitHub, która jest wdrażana pod adresem URL wersji opublikowanej. Często jest to gałąź, z którą scalane są gałęzie funkcji lub gałęzie programistyczne.

  • akceptować lub odrzucać automatyczne wdrażanie,

    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.

  • Wybierz środowisko wykonawcze. Domyślnie wstępnie wybrana jest najnowsza zalecana wersja Node.js.

    • Skonfiguruj automatyczne aktualizacje obrazu podstawowego (ABIU). Funkcja ABIU jest domyślnie włączona i automatycznie stosuje poprawki zabezpieczeń w środowisku bazowym. Możesz zrezygnować z ABIU, wybierając „Nie określono” dla środowiska wykonawczego.

Usunięcie backendu

Aby całkowicie usunąć backend, najpierw usuń go za pomocą konsoli Firebase lub interfejsu wiersza poleceń Firebase, a następnie ręcznie usuń 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 projektu w Firebase.

Konsola Firebase: w menu Ustawienia wybierz Usuń backend.

Firebase CLI: (wersja 13.15.4 lub nowsza)

  1. Aby usunąć backend App Hosting, 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

  2. (Opcjonalnie) Na karcie konsoli Google Cloud dla Artifact Registry usuń obraz backendu w sekcji „firebaseapphosting-images”.

  3. W usłudze Cloud Secret Manager usuń wszystkie obiekty tajne, które mają w nazwie „apphosting”. Upewnij się, że te obiekty tajne nie są używane przez inne backendy ani inne aspekty projektu w Firebase.