Comprendre App Hosting et son fonctionnement

App Hosting gère une série complexe de tâches en arrière-plan pour simplifier le déploiement de votre application. Cette page décrit les éléments clés de ce flux de tâches, en fournissant des informations sur les points où vous pouvez personnaliser le flux en fonction des besoins de votre application.

Intégration de framework

App Hosting fournit une prise en charge préconfigurée de la compilation et du déploiement pour les applications Web développées dans les frameworks suivants:

  • Next.js 13 ou version ultérieure
  • Angular 17.2 ou version ultérieure

App Hosting identifie le framework que vous utilisez en inspectant le fichier package-lock.json ou un autre fichier de verrouillage de votre dépôt. Si vous essayez de déployer une application Node.js à laquelle il manque un fichier de verrouillage, App Hosting ne pourra pas compiler ni exécuter votre application. Vous pouvez créer package-lock.json en exécutant npm install dans votre répertoire racine.

Adaptateurs de framework

Les adaptateurs de framework App Hosting ont deux rôles clés:

  1. Ils analysent votre code source et tous les fichiers de configuration spécifiques au framework (tels que next.config.js) et génèrent un bundle de sortie pouvant être traité par le reste de l'infrastructure d'hébergement d'applications.
  2. Ils exécutent la commande de compilation de votre application pour générer des éléments statiques et créer une version optimisée de votre application pour la production.

Les adaptateurs de framework compilent votre application Node.js avec npm run build, qui fonctionne mieux avec les scripts de compilation par défaut de chaque framework: next build pour Next.js et ng build pour Angular. App Hosting tentera de compiler avec des commandes de compilation personnalisées, mais ne peut pas garantir le succès de manière fiable.

Le code source des adaptateurs Next.js et Angular est disponible dans firebase-framework-tools.

Autres frameworks

En plus de Nextjs et d'Angular, App Hosting est également compatible avec tous les frameworks Web capables de fournir une sortie de compilation correspondant à nos spécifications de bundle de sortie. Les auteurs de frameworks peuvent tirer parti de la spécification du bundle de sortie pour s'assurer que leur framework est compatible avec l'hébergement d'applications.

Si vous souhaitez que d'autres frameworks soient compatibles, vous pouvez créer un adaptateur ou contacter les responsables du framework pour convertir les sorties de compilation au format d'hébergement d'applications. Les adaptateurs Nextjs et Angular sont de bons exemples de référence pour toute personne qui crée un adaptateur.

Vous trouverez les frameworks compatibles sur Firebase Open Source.

Fonctionnement de l'intégration du dépôt App Hosting

La connexion importante entre votre dépôt GitHub et le backend App Hosting est gérée par Developer Connect, la plate-forme de connectivité de Google Cloud pour les outils DevOps externes. Lors de la création d'un backend App Hosting, le workflow de l'UI de Developer Connect vous guide tout au long de l'installation de l'application GitHub Firebase. Les étapes clés de ce processus sont les suivantes:

  1. Vous attribuez à Developer Connect le rôle Administrateur de Secret Manager. Cela permet au système de stocker les identifiants de manière sécurisée en tant que "secrets" dans Cloud Secret Manager.
  2. Vous autorisez l'application GitHub Firebase à accéder à votre dépôt GitHub.
  3. Developer Connect stocke un jeton d'autorisation GitHub dédié dans le dépôt Secret Manager de votre projet. Ne modifiez ni ne supprimez ce jeton.

De plus, App Hosting s'intègre à l'API GitHub Checks pour effectuer une vérification des déploiements. Cette vérification vous permet de consulter l'état de votre déploiement dans GitHub et de déboguer le processus de déploiement en cas d'erreurs.

Intégration à Firebase et à d'autres services Google

App Hosting configure vos environnements de compilation et d'exécution afin que vous puissiez initialiser le SDK Admin Firebase avec les identifiants par défaut de l'application Google. De cette façon, votre backend peut communiquer avec d'autres produits Firebase lors de la compilation et du déploiement.

App Hosting emplacements

Le déploiement App Hosting crée vos ressources backend à un emplacement spécifique. Cette flexibilité dans l'emplacement de votre application Web présente des avantages clés:

  • Amélioration des performances et réduction de la latence en rapprochant géographiquement les données de vos utilisateurs.
  • Une défaillance catastrophique pour App Hosting dans une région n'affecterait pas les applications Web déployées dans d'autres régions.

Vous pouvez choisir l'une de ces régions lorsque vous créez un backend App Hosting à partir de la console ou de la CLI Firebase:

  • us-central1 (Iowa)
  • asia-east1 (Taïwan)
  • europe-west4 (Pays-Bas)

Compte de service de backend App Hosting

Lors de la compilation et de l'exécution, votre backend App Hosting s'authentifie auprès d'autres services Google avec un compte de service. Un compte de service par défaut à ces fins est créé la première fois que vous activez App Hosting dans un projet Firebase:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

Ce compte de service s'applique par défaut à tous les backends et dispose d'un ensemble minimal d'autorisations pour vous permettre de créer, d'exécuter et de surveiller votre application. Il est également autorisé à authentifier le SDK Admin avec les identifiants par défaut de l'application pour effectuer des opérations telles que le chargement de données à partir de Cloud Firestore. Consultez la section Rôles App Hosting Firebase.

Si votre application doit interagir avec d'autres services Google au moment de la compilation ou à partir d'un backend en cours d'exécution, vous pouvez personnaliser le compte de service par défaut en ajoutant des rôles. Par exemple, si votre application nécessite des autorisations pour Vertex AI, vous devrez peut-être ajouter roles/aiplatform.user ou un rôle associé.

Termes clés et définitions

  • Backend: ensemble de ressources gérées créées par App Hosting pour créer et exécuter votre application Web.
  • Déploiement: version spécifique de votre application en ligne, associée à un commit Git.
  • Branche active: branche de votre dépôt GitHub qui est déployée sur votre URL active. Il s'agit souvent de la branche dans laquelle les branches de fonctionnalités ou de développement sont fusionnées.

Limites et problèmes connus

L'aperçu de App Hosting présente certaines limites connues:

  • Dans certains cas, un backend App Hosting peut renvoyer des messages Intermittent connection error à l'URL de votre application. Un correctif sera disponible dans une prochaine version.
  • Les en-têtes Cache-Control sont modifiés pour limiter les caches CDN à 60 secondes. À l'avenir, lorsque App Hosting pourra purger rapidement le cache lors du déploiement, cette limite sera levée.
  • L'optimisation des images est effectuée dans Cloud Run par défaut, et les images optimisées ne sont pas conservées. Nous vous recommandons de désactiver l'optimisation des images ou de spécifier manuellement un chargeur jusqu'à ce qu'une meilleure solution soit disponible.
  • Les fichiers statiques non mis en cache sont diffusés à partir de Cloud Run. Dans une version ultérieure, ils seront stockés et diffusés à partir de l'origine App Hosting pour de meilleures performances.
  • Il est possible que les codes SKU App Hosting ne s'affichent pas sur la page d'utilisation du backend de la console Firebase. Ils seront disponibles dans une prochaine version.
  • La console Firebase peut afficher de manière intermittente une erreur "Build not found and is invalid" (Build introuvable et non valide) lors de la création du backend.
  • Actuellement, tous les backends d'un même projet partagent une organisation/un compte GitHub. Ils peuvent être connectés à différents dépôts de cette organisation/compte. Pour créer des backends connectés à différents comptes GitHub, placez-les dans des projets distincts.
  • Le middleware, les réécritures et les redirections Next.js sont exécutés dans Cloud Run, derrière le CDN. Comme ces éléments ne protègent pas les réponses mises en cache, veillez à définir des directives de contrôle appropriées pour le contenu que vous affichez.