Déployer plusieurs environnements à partir d'un codebase

Il est courant de déployer plusieurs environnements à partir du même codebase, chacun avec une configuration légèrement différente. Par exemple, vous pouvez attribuer moins de processeur et de RAM à votre environnement de préproduction, ou vous assurer que votre environnement de production conserve au moins une instance active et prête à traiter les requêtes. Vous pouvez également spécifier différentes variables d'environnement et différents secrets en fonction de l'environnement et des ressources que vous souhaitez utiliser.

Ce guide explique comment déployer un environnement de production et de préproduction, chacun dans un projet Firebase distinct. En suivant les mêmes principes, vous pouvez déployer des composants dans d'autres types d'environnements. Pour en savoir plus sur les environnements, consultez Présentation des environnements et Bonnes pratiques générales pour configurer des projets Firebase.

Prérequis

  • Le code de votre application est déjà stocké dans GitHub.
  • Vous avez déjà créé un projet distinct pour chacun de vos environnements (par exemple, my-production-firebase-project et my-staging-firebase-project). Veillez à taguer votre projet Firebase de production avec le type d'environnement "production".
  • Dans chaque projet, vous avez créé un backend App Hosting, avec la branche "live" définie sur la branche GitHub que vous souhaitez déployer (par exemple, main). Pour en savoir plus, consultez Premiers pas avec App Hosting.

Étape 0 : Créez une configuration par défaut dans apphosting.yaml

App Hosting est compatible avec un fichier de configuration appelé apphosting.yaml pour gérer les paramètres d'exécution (CPU, simultanéité, limites de mémoire, etc.) et les variables d'environnement de votre application. Il est également compatible avec les références aux secrets gérés avec Cloud Secret Manager, ce qui permet de les inclure dans le système de gestion des versions en toute sécurité. Pour en savoir plus, consultez Configurer un backend.

Pour commencer, créez un fichier apphosting.yaml dans le répertoire racine de votre application. Il s'agit du fichier de configuration de secours utilisé lorsqu'aucun fichier de configuration spécifique à l'environnement n'est trouvé. Les valeurs stockées dans apphosting.yaml doivent être des valeurs par défaut qui peuvent être utilisées en toute sécurité pour tous les environnements.

Les sections suivantes expliquent comment remplacer les valeurs par défaut dans apphosting.yaml pour des environnements spécifiques. Cet exemple de flux crée un environnement de préproduction.

Étape 1 : Définissez le nom de l'environnement

Chaque backend App Hosting dispose d'un paramètre Nom de l'environnement. Ce champ permet d'associer votre backend à un fichier de configuration spécifique à un environnement. Vous pouvez le modifier à tout moment. Vous ne pouvez définir qu'un seul nom d'environnement par backend.

Pour définir le nom de l'environnement de votre backend :

  1. Dans la console Firebase, sélectionnez votre projet de préproduction (dans cet exemple, my-staging-firebase-project).
  2. Sélectionnez App Hosting dans le panneau de navigation de gauche.
  3. Cliquez sur Afficher le tableau de bord sur le backend de votre choix.
  4. Dans l'onglet Paramètres, sélectionnez Environnement.
  5. Sous Nom de l'environnement,saisissez le nom de votre environnement. Vous pouvez nommer l'environnement comme vous le souhaitez. Dans cet exemple, il s'agit de staging.
  6. Cliquez sur Enregistrer.

Lorsqu'un déploiement App Hosting est déclenché pour votre backend (soit sur git push, soit manuellement via la console), App Hosting recherche un fichier apphosting.ENVIRONMENT_NAME.yaml avant de revenir à apphosting.yaml.

Étape 2 : Créez votre fichier apphosting.yaml spécifique à l'environnement

Pour votre configuration spécifique à l'environnement, créez un fichier nommé apphosting.ENVIRONMENT_NAME.yaml afin de spécifier les remplacements spécifiques à l'environnement. Ce fichier a le même format que le fichier apphosting.yaml par défaut et doit se trouver dans le répertoire racine de votre application, à côté de apphosting.yaml.

Au moment de la compilation, App Hosting fusionne ces deux fichiers, en accordant la priorité aux valeurs du fichier YAML spécifique à l'environnement par rapport au fichier apphosting.yaml de base.

Dans cet exemple, vous allez créer un fichier nommé apphosting.staging.yaml dans le répertoire racine de l'application :


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Supposons que vous disposiez déjà d'un apphosting.yaml qui se présente comme suit :

runConfig:
  cpu: 3
  memoryMiB: 1024
  maxInstances: 4
  minInstances: 0
  concurrency: 100

env:
-   variable: API_URL
    value: api.service.com
    availability:
      -   BUILD
      -   RUNTIME

-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

La sortie fusionnée finale, que vous pouvez inspecter dans vos journaux Cloud Build, se présente comme suit :

runConfig:
  cpu: 1
  memoryMiB: 512
  maxInstances: 4
  minInstances: 0
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

Notez que certaines valeurs runConfig, telles que le processeur, ont également été écrasées, ainsi que toutes les variables d'environnement qui se chevauchent.

Étape 3 : Déployez votre code

Une fois que vous avez terminé de modifier votre fichier apphosting.ENVIRONMENT_NAME.yaml spécifique à l'environnement, transférez-le vers GitHub :

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

Tous les backends tagués avec ce nom d'environnement utiliseront les valeurs de remplacement spécifiques que vous avez spécifiées dans le fichier YAML correspondant et reviendront à apphosting.yaml lorsqu'une valeur n'est pas trouvée. Pour les backends sans nom d'environnement associé, vous pouvez continuer à utiliser apphosting.yaml.

Étapes suivantes