Configuration de l'environnement : pourquoi, quoi et comment ?

La gestion de la configuration est un aspect important de l'ingénierie logicielle. Cet article mettra en lumière le pourquoi et le quoi du problème et expliquera les différentes solutions existantes.

L'approche de gestion de la configuration change à mesure que l'application évolue, à la fois en termes de trafic et de taille de l'équipe de développeurs. Pour illustrer le voyage, commençons par une simple application.

Il s'agit d'une application serveur simple qui se connecte à MongoDB et renvoie la liste des utilisateurs. Le code n'est qu'un pseudo code et n'est pas destiné à adhérer à un langage quelconque.

Configuration en hardcode dans l'application : un GRAND NON !

Si vous codez en dur l'URI MongoDB dans l'application, il sera très difficile de l'exécuter dans un autre environnement, comme les ordinateurs portables de vos collègues ou pour la production. Nous devons suivre les Méthodologie des applications à 12 facteurs ici pour séparer la configuration du code.

« CONFIGURATION SÉPARÉE DU CODE »

Maintenant, la question est de savoir ce que comprend la configuration d'une application? Citant https://12factor.net/config

Une application config est tout ce qui est susceptible de varier entre déploie (mise en scène, production, environnements de développement, etc.) Cela inclut :

1. Les descripteurs de ressources vers la base de données, Memcached et autres services de soutien

2. Informations d'identification pour des services externes tels qu'Amazon S3 ou Twitter

3. Valeurs par déploiement, telles que le nom d'hôte canonique pour le déploiement

La méthode la plus simple et la plus courante pour séparer la configuration du code consiste à placer les variables dans un fichier .env.

Une fois cela fait, nous devons charger les variables dans le code à partir du fichier .env. Il existe plusieurs packages pour faire comme doten c. et dotenv-expand. Le fichier .env n'est pas envoyé vers Git dans ce cas et chaque développeur remplace la variable en fonction de son propre environnement. Pour donner à tous les développeurs une idée des variables d'environnement à ajouter, nous validons généralement un fichier comme .env. exemple à Git.

Nous devrons également fournir les valeurs de ces variables dans les environnements de production et de production. Presque tous les systèmes de déploiement proposent un moyen de stocker et de fournir des variables d'environnement telles que ConfigMap et Secrets dans Kubernetes, ou S3 pour Elastic Container Service.

Nous devrons copier ces variables dans ces environnements et les synchroniser chaque fois que les développeurs ajoutent/suppriment des variables d'environnement. Une approche possible consiste à disposer d'un fichier .env distinct pour les environnements de préparation, de production, etc.

Comment et où stockons-nous les fichiers .env spécifiques à l'environnement ?

On peut suggérer de stocker ces fichiers dans Git, mais il existe un gros problème de sécurité dans ce cas, en particulier pour certaines des informations d'identification sensibles contenues dans les fichiers env.

1. Nous ne voulons probablement pas que tous les développeurs aient accès aux informations d'identification de la base de données et à d'autres informations sensibles à la sécurité.
2. Le stockage de toutes les informations d'identification en texte brut dans le référentiel Github représente également un risque de sécurité important du point de vue des fuites de sécurité.

Les gens utilisent différentes approches ici, mais certaines des méthodes les plus connues sont les suivantes :

1. Stockez les valeurs cryptées dans le référentiel Git et les valeurs ne peuvent être déchiffrées que par quelqu'un qui possède les clés. Une bonne bibliothèque pour y parvenir est https://github.com/StackExchange/blackbox
2. Utiliser un stockage externe : cette approche repose sur le stockage des variables d'environnement pour le staging, la production, etc. dans une couche de stockage différente, telle que S3 ou AWS Parameter Store. Seuls les environnements de production et de mise en scène sont autorisés à lire ces valeurs et peuvent donc être protégées contre les développeurs. Les SecretManagers peuvent également stocker les secrets cryptés, fournir un contrôle d'accès et également faire pivoter automatiquement les secrets. Voici quelques exemples de tels gestionnaires de secrets/magasins de paramètres :

Lorsque vous utilisez l'un de ces systèmes externes, nous avons maintenant réparti la configuration entre les fichiers .env et les secretmanagers. Certains paramètres non sensibles proviendront des fichiers .env et d'autres du stockage à distance des informations d'identification. Nous pouvons affirmer que nous pouvons stocker tous les paramètres dans le stockage distant, mais cela peut parfois être exagéré. Alors maintenant, nous en arrivons à :

Notre application a maintenant besoin d'un code à lire à partir de ces deux sources de configuration. La lecture à partir des fichiers .env peut être effectuée à l'aide du package dotenv, cependant, l'obtention des variables d'environnement à partir des secretmanagers nous oblige à utiliser leurs API correspondantes pour obtenir les valeurs.

Cela permet de résoudre le problème de la sécurité de notre configuration et de suivre la méthodologie à 12 facteurs.

Cependant, écrire du code d'application pour obtenir des secrets finit par être une pratique répétitive dans laquelle chaque application doit désormais ajouter du code spécifique au gestionnaire de secrets pour obtenir les valeurs de l'API. Cela signifie également que si jamais nous changeons de fournisseur de secretsmanager, le code de toutes les applications doit changer. Pour résoudre ce problème, il existe plusieurs approches :

1. Résumez le code pour extraire les secrets sous forme de bibliothèque standard à partager entre toutes vos applications. Cela peut simplifier le problème dans une certaine mesure.
2. Synchronisez les valeurs des secretmanagers avec l'environnement d'hébergement de manière asynchrone. Cela nécessite un système externe qui peut compliquer la synchronisation des versions de code et des modifications de configuration. Par exemple, coffre-k8s permet de synchroniser les secrets de Vault avec les environnements Kubernetes.
3. Utilisez une solution payante comme Doppler (doppler.com)
4. Utilisez des solutions open source telles que Fonderie Secrets — cela vous permet de parler à différents gestionnaires de secrets sans ajouter de code dans vos applications. J'écrirai plus sur SecretsFoundry dans mon prochain article.

La gestion des configurations est complexe et doit être effectuée correctement dès le départ pour garantir que la rapidité des développeurs reste élevée sans pour autant sacrifier les aspects de sécurité. Kubernetes, qui est le plus utilisé aujourd'hui pour déployer des applications, possède sa propre configuration et sa propre gestion des secrets, que j'aborderai dans un autre article. De plus, si vous utilisez un autre moyen de gestion de la configuration, veuillez le mentionner dans les commentaires. J'aimerais en savoir plus et apprendre de vous !

True Foundry est une passerelle d'IA de niveau professionnel qui englobe un LLM, un MCP et des passerelles d'agents, permettant aux entreprises de se connecter, d'observer et de gérer l'accès aux modèles, aux outils, aux garde-corps et aux agents en toute sécurité à partir d'un plan de contrôle unique. L'AI Gateway permet de gérer des charges de travail agentiques qui sont les suivantes :
a) Sécurisé — résolution des problèmes de gestion des clés, d'authentification et d'autorisation
b) Efficace — optimisation des coûts, de la latence et des basculements multirégionaux
c) Sécuritaire pour l'avenir — permettant des connexions unifiées et composables entre les LLM, les MCP et les garde-corps de n'importe quel fournisseur