Je trouve la pratique de créer un nœud séparé.fichiers de configuration js pour gérer les variables de configuration pour différents environnements (développement, test, staging et production) encombrants.
Je me suis donc retrouvé avec une solution qui gère les variables de configuration pour tous les environnements avec un seul nœud.fichier de configuration js.
Tout d’abord, créons la configuration.json dans le dossier root / config comme ci-dessous. L’idée est que le développement est l’environnement par défaut et contient toutes les variables de configuration. Vous ne répétez les variables de configuration dans d’autres environnements que si vous souhaitez remplacer les valeurs de variable de configuration par défaut trouvées dans l’environnement de développement par défaut.
Comme vous pouvez le voir, les environnements de test, de mise en scène et de production remplacent tous les variables config_id et database config. Et les environnements de mise en scène et de production remplacent également la variable de configuration node_port.
Ensuite, écrivons du code pour implémenter la logique réelle. Créer une configuration.js dans le dossier root / config comme ci-dessous. Ce code:
- Lit le JSON trouvé dans root/config.fichier json.
- Définit la configuration par défaut sur le nœud de développement trouvé dans config.json.
- Définit la configuration de l’environnement sur le nœud d’environnement correspondant trouvé dans la configuration.json basé sur la valeur de la variable d’environnement NODE_ENV (qui elle-même par défaut est development si null).
- Définit la configuration finale sur l’union de la configuration par défaut et de l’environnement en appelant la méthode de fusion de lodash.
- Définit la variable globale gConfig avec la valeur de la configuration finale.
- Enregistre la valeur de gConfig.
Enfin, créons racine / serveur.js pour tester tout cela dans un navigateur. Le code ci-dessous est explicite. Testez-le en définissant différentes valeurs pour la variable d’environnement NODE_ENV.
Et voici quelques captures d’écran des tests en définissant la variable d’environnement NODE_ENV dans le serveur.js au développement et à la mise en scène. Vous pouvez voir que pour l’environnement de transfert, les valeurs de app_name, app_desc et json_indentation ne changent pas et sont récupérées dans l’environnement de développement où les valeurs de config_id, node_port et database sont remplacées.
Vous pouvez cloner/ télécharger le code ci-dessus de mon dépôt GitHub ici.
En prime, rien ne vous empêche d’inclure des secrets comme les clés d’API ou les mots de passe dans la configuration.json. Il vous suffit de le chiffrer au repos avant de le transmettre à votre référentiel source à l’aide d’une solution de cryptage de niveau entreprise telle que le service de gestion des clés Cloud (KMS) de Google Cloud Platform. Et déchiffrez-le à chaque déploiement à l’aide de votre outil CI / CD préféré.
Consultez mon article de blog En utilisant le service de gestion des clés Cloud (KMS) de Google Cloud Platform pour Chiffrer / Déchiffrer les secrets pour plus d’informations.
Bon codage!