Dowiedz się, jak działa App Hosting i jak działa.

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.

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, w której brakuje pliku blokady, App Hosting nie będzie mogła skompilować 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:

1. 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.
2. 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 jest obsługiwane przez Developer Connect, platformę 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:

1. przyznasz usłudze Developer Connect rolę Administratora Secret Managera. Dzięki temu system może bezpiecznie przechowywać dane logowania jako „obiekty tajne” w usłudze Cloud Secret Manager.
2. Autoryzujesz aplikację Firebase na GitHubie do dostępu do repozytorium GitHub.
3. 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 Hosting w Firebase.

Jeśli aplikacja musi wchodzić w interakcje z dodatkowymi usługami Google w czasie kompilacji lub z bieżącego 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 Twoim 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

Wersja App Hosting ma pewne znane ograniczenia:

• W niektórych przypadkach backend App Hosting może zwracać wiadomości Intermittent connection error pod adresem URL aplikacji. Naprawimy to w kolejnej 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.
• Optymalizacja obrazów jest domyślnie 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.
• Niebuforowane pliki statyczne są dostarczane z urządzenia Cloud Run. W późniejszej wersji będą przechowywane i dostarczane z urządzenia App Hosting, co zapewni lepszą wydajność.
• App Hosting SKU mogą nie być wyświetlane na stronie korzystania z backendu 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.
• Obecnie wszystkie backendy w tym samym projekcie korzystają z organizacji/konta GitHub. Można je połączyć z różnymi repozytoriami w ramach tej organizacji lub 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.