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 CPU et de RAM à votre environnement de préproduction, ou vous pouvez vous assurer que votre environnement de production conserve au moins une instance active et prête à répondre aux requêtes. Vous pouvez également spécifier différentes variables d'environnement et 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 effectuer des déploiements dans d'autres types d'environnements. Pour en savoir plus sur les environnements, consultez la section Présentation des environnements et les bonnes pratiques générales pour configurer des projets Firebase.

Prérequis

  • Votre code d'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 en ligne 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 prend également en charge les références aux secrets gérés avec Cloud Secret Manager, ce qui permet de les intégrer de manière sécurisée dans le contrôle des versions. 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 remplacement utilisé lorsqu'un fichier de configuration spécifique à l'environnement n'est pas trouvé. Les valeurs stockées dans apphosting.yaml doivent être des valeurs par défaut pouvant être utilisées sans risque 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 de mapper votre backend à un fichier de configuration spécifique à l'environnement. Il peut être modifié à 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 menu de navigation de gauche.
  3. Cliquez sur Afficher le tableau de bord dans le backend de votre choix.
  4. Dans l'onglet Settings (Paramètres), sélectionnez Deployment (Déploiement).
  5. Sous Environment name (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 (via git push ou 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 forçages 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 donnant 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 ayez déjà un apphosting.yaml ressemblant à ceci:

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.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

La sortie finale fusionnée, 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.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

  -   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

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

Étape 3: Déployer votre codebase

Une fois que vous avez terminé de modifier le fichier apphosting.ENVIRONMENT_NAME.yaml spécifique à votre 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 utilisent les valeurs de remplacement spécifiques que vous avez spécifiées dans le fichier YAML correspondant et utilisent apphosting.yaml lorsqu'une valeur est introuvable. Pour les backends sans nom d'environnement associé, vous pouvez continuer à utiliser apphosting.yaml.

Étapes suivantes