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.

Compatibilité avec les frameworks

App Hosting fournit une prise en charge de la compilation et du déploiement sans configuration 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 pour 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.

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) afin de comprendre le comportement configuré de votre application.
  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.

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 accordez à Developer Connect le rôle Administrateur 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 d'afficher l'état de votre déploiement dans GitHub et de déboguer le processus de déploiement en cas d'erreur.

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éliorez les performances et réduisez la latence en rapprochant géographiquement les données de vos utilisateurs.
  • Une défaillance catastrophique de App Hosting dans une région n'aurait pas d'incidence sur les applications Web déployées dans les 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 par défaut dans Cloud Run, 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.
  • Les SKU App Hosting ne peuvent pas être affichés 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 du 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.