App Hosting obsługuje złożoną serię zadań w tle, aby uprościć wdrażanie aplikacji. Ta strona opisuje kluczowe części tego procesu, podając informacje o miejscach, w których warto go dostosować do potrzeb aplikacji.
Architektura Google Cloud i App Hosting
App Hosting steruje zestawem usług Google Cloud, aby umożliwić Ci wdrażanie, obsługę i monitorowanie aplikacji internetowej. Aplikacje są tworzone za pomocą Cloud Build, obsługiwane przez Cloud Run i przechowywane w pamięci podręcznej w Cloud CDN. Zintegrowane usługi, takie jak Cloud Secret Manager, zapewniają bezpieczeństwo kluczy interfejsu API.
- Gdy zatwierdzone zmiany zostaną przesłane do gałęzi produkcyjnej, Google Cloud Developer Connect wyśle zdarzenie do Firebase App Hosting.
- W odpowiedzi na to zdarzenie Firebase App Hosting rozpoczyna nowe wdrożenie dla każdego backendu połączonego z repozytorium.
- Firebase App Hosting tworzy nową wersję Cloud Build dla Twojego commita. W tym zadaniu pakiety kompilacji Google Cloud określają, której platformy używa Twoja aplikacja, aby utworzyć kontener i konfigurację (w tym zmienne środowiskowe, sekrety, minimalne lub maksymalne instancje, pamięć współbieżną, procesor i konfigurację VPC) odpowiednią dla Twojej aplikacji.
- Po zakończeniu zadania Cloud Build kontener jest przechowywany w repozytorium Artifact Registry przeznaczonym do Firebase App Hosting. Firebase App Hosting dodaje nową wersję Cloud Run do usługi Cloud Run, używając Twojego obrazu i konfiguracji. Gdy sprawdzisz, że wersja Cloud Run jest zdrowa, usługa Firebase App Hosting zmodyfikuje konfigurację ruchu, aby kierować wszystkie nowe żądania do nowej wersji Cloud Run. W tej chwili udostępnienie jest zakończone.
- Gdy żądanie jest wysyłane do witryny hostowanej w Firebase App Hosting, jest ono obsługiwane przez system równoważenia obciążenia Google Cloud z włączoną usługą Cloud CDN. Żądania nieprzechowywane w pamięci podręcznej są wysyłane do usługi Cloud Run.
Integracja z ramówką
App Hosting zapewnia wstępnie skonfigurowaną obsługę kompilacji i wdrażania aplikacji internetowych opracowanych w ramach tych frameworków:
- Next.js 13 i nowsze
- Angular 17.2 lub nowszy
App Hosting określa, której platformy używasz, przez sprawdzenie pliku package-lock.json lub innego pliku blokady w repozytorium. Jeśli spróbujesz wdrożyć aplikację Node.js, której brakuje pliku blokady, App Hosting nie będzie mogła utworzyć ani uruchomić aplikacji. Możesz utworzyć App Hosting, uruchamiając npm
install w katalogu głównym.package-lock.json
Adaptery framework
App Hostingadaptery frameworka pełnią 2 kluczowe role:
- Analizują kod źródłowy i pliki konfiguracji związane z danym frameworkiem (np.
next.config.js) i generują pakiet wyjściowy, który może być przetwarzany przez pozostałą infrastrukturę hostingu aplikacji. - Wykonują one polecenie kompilacji aplikacji, aby wygenerować zasoby statyczne i utworzyć zoptymalizowaną wersję produkcyjną aplikacji.
Adaptery platformy kompilują aplikację Node.js za pomocą npm run build, najlepiej współpracując z domyślnymi skryptami kompilacji dla każdej platformy: next build w przypadku Next.js i ng build w przypadku Angular. App Hosting spróbuje utworzyć wersje za pomocą niestandardowych poleceń, ale nie możemy zagwarantować powodzenia.
Źródło adapterów Next.js i Angular jest dostępne w pakiecie firebase-framework-tools.
Inne platformy
Oprócz Next.js i Angular hosting aplikacji obsługuje też dowolny framework internetowy, który może wygenerować dane wyjściowe zgodne z naszą specyfikacją pakietu danych wyjściowych. Autorzy frameworków mogą skorzystać ze specyfikacji pakietu wyjściowego, aby mieć pewność, że ich framework jest obsługiwany przez usługę hostingu aplikacji.
Jeśli chcesz, aby obsługiwane były dodatkowe platformy, możesz utworzyć adapter lub skontaktować się z ich administratorami, aby przekonwertować dane kompilacji na format hostingu aplikacji. Adaptery Next.js i Angular są dobrymi przykładami dla wszystkich, którzy tworzą adaptery.
Obsługiwane platformy znajdziesz na stronie Firebase Open Source.
Jak działa integracja z repozitorium App Hosting
Ważne połączenie między repozytorium GitHub a backendem App Hosting obsługuje Developer Connect, czyli platforma Google Cloud do łączenia zewnętrznych narzędzi DevOps. Podczas tworzenia backendu App Hosting w interfejsie użytkownika Developer Connect przeprowadzi Cię przez proces instalacji aplikacji Firebase GitHub. Najważniejsze kroki w tym procesie to:
- przyznasz usłudze Developer Connect rolę Administratora usługi Secret Manager. Dzięki temu system może bezpiecznie przechowywać dane logowania jako „obiekty tajne” w usłudze Cloud Secret Manager.
- Autoryzujesz aplikację Firebase na GitHubie do dostępu do repozytorium GitHub.
- Usługa Developer Connect przechowuje w repozytorium usługi Secret Manager dedykowany token autoryzacji GitHub. Nie modyfikuj ani nie usuwaj tego tokena.
Dodatkowo App Hosting integruje się z interfejsem GitHub checks API, aby zapewnić sprawdzanie wdrożeń. Dzięki temu możesz wyświetlić stan wdrażania w GitHub i debugować proces wdrażania w przypadku wystąpienia błędów.
Integracja z Firebase i innymi usługami Google
App Hosting konfiguruje środowisko kompilacji i środowisko uruchomieniowe, aby umożliwić inicjowanie pakietu SDK Firebase Admin za pomocą domyślnych danych logowania do aplikacji Google. Dzięki temu backend może się komunikować z innymi usługami Firebase zarówno podczas kompilacji, jak i wdrażania.
App Hosting lokalizacji
App Hosting wdrażanie tworzy zasoby backendu w określonej lokalizacji. Ta elastyczność w lokalizacji aplikacji internetowej ma kilka kluczowych zalet:
- Zwiększona wydajność i zmniejszony czas oczekiwania dzięki umieszczeniu danych bliżej użytkowników.
- Katastrofalny błąd w usłudze App Hosting w jednym regionie nie wpłynie na aplikacje internetowe wdrożone w innych regionach.
Podczas tworzenia App Hosting backendu w konsoli lub w interfejsie wiersza poleceń Firebase możesz wybrać dowolny z tych regionów:
us-central1(Iowa)asia-east1(Tajwan)europe-west4(Holandia)
App Hosting konto usługi w części backendowej,
Podczas kompilacji i w czasie działania backend App Hosting uwierzytelnia się w innych usługach Google za pomocą konta usługi. Domyślne konto usługi do tych celów jest tworzone przy pierwszym włączeniu funkcji App Hosting w projekcie Firebase:
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
To konto usługi domyślnie dotyczy wszystkich backendów i ma minimalny zestaw uprawnień, aby umożliwić kompilowanie, uruchamianie i monitorowanie aplikacji. Ma też uprawnienia do uwierzytelniania pakietu Admin SDK za pomocą domyślnych danych logowania aplikacji, aby wykonywać operacje takie jak wczytywanie danych z Cloud Firestore. Zapoznaj się z rolami App HostingFirebase.
Jeśli aplikacja musi wchodzić w interakcje z dodatkowymi usługami Google w czasie kompilacji lub z uruchomionego backendu, możesz dostosować domyślne konto usługi, dodając role. Jeśli na przykład Twoja aplikacja wymaga uprawnień Vertex AI, konieczne może być dodanie roli roles/aiplatform.user lub innej powiązanej roli.
Najważniejsze terminy i definicje
- Backend: zbiór zarządzanych zasobów, które App Hostingtworzy do tworzenia i uruchamiania aplikacji internetowej.
- Wdrażanie: konkretna wersja aplikacji, która jest połączona z commitem w Git.
- Gałąź produkcyjna: gałąź w repozytorium GitHub, która jest wdrażana do adresu URL wersji produkcyjnej. Często jest to gałąź, do której scalane są gałęzie funkcji lub gałęzie rozwoju.
Znane problemy i ograniczenia
Podgląd App Hosting ma pewne znane ograniczenia:
- W niektórych przypadkach backend App Hosting może zwracać wiadomości
Intermittent connection errorpod adresem URL aplikacji. Naprawimy to w nadchodzącej wersji. - Nagłówki Cache-Control zostały zmodyfikowane, aby ograniczyć pamięć podręczną CDN do 60 sekund. W przyszłości, gdy App Hosting będzie mieć możliwość szybkiego wyczyszczenia pamięci podręcznej po wdrożeniu, ten limit zostanie zniesiony.
- Domyślnie optymalizacja obrazów jest wykonywana w trybie Cloud Run, a zoptymalizowane obrazy nie są przechowywane. Zalecamy wyłączenie optymalizacji obrazów lub ręczne określenie ładowarki, dopóki nie będzie dostępne lepsze rozwiązanie.
- Ścieżki adresów URL zawierające znaki zakodowane za pomocą procentów są dekodowane przez funkcję Cloud Run. Może to powodować problemy z funkcjami, które wymagają tylko zakodowanych ścieżek adresów URL, np. z przekierowaniem równoległym Next.js.
- Niezapisane pliki statyczne są dostarczane z adresu Cloud Run. W późniejszej wersji będą przechowywane i dostarczane z adresu App Hosting, co zapewni lepszą wydajność.
- App Hosting Identyfikatory SKU mogą nie być wyświetlane na stronie użycia w backendzie w konsoli Firebase. Będą one dostępne w nadchodzącej wersji.
- Konsola Firebase może sporadycznie wyświetlać błąd „Nie znaleziono wersji i jest ona nieprawidłowa” podczas tworzenia backendu.
- Wszystkie backendy w tym samym projekcie korzystają z organizacji/konta GitHub. Mogą być one połączone z różnymi repozytoriami w ramach tej organizacji lub tego konta. Aby utworzyć backendy połączone z różnymi kontami GitHub, umieść je w osobnych projektach.
- Oprogramowanie pośredniczące, przekierowania i przepisania Next.js są wykonywane w Cloud Run, za CDN. Ponieważ nie chronią one odpowiedzi z pamięci podręcznej, pamiętaj o ustawieniu odpowiednich dyrektyw kontroli dla renderowanych treści.