Quelle est la méthode préférée pour stocker les configurations d'application?
La plupart du temps, je stocke la configuration de l'application de développement dans le répertoire racine du projet, comme ceci:
app
|-- config.json
Mais cela ne semble pas être la meilleure approche, car cette configuration finit par être stockée dans le système de contrôle de version - ce qui peut entraîner des fuites de noms d'utilisateur, de mots de passe et d'autres éléments sensibles.
12 Factor App le guide recommande de supprimer complètement les fichiers de configuration et d'utiliser les variables d'environnement pour la configuration:
... stocke la configuration dans les variables d'environnement. Les vars Env sont faciles à changer entre les déploiements sans changer de code; contrairement aux fichiers de configuration, il y a peu de chances qu'ils soient archivés accidentellement dans le dépôt de code; et contrairement aux fichiers de configuration personnalisés ou à d'autres mécanismes de configuration tels que Java Propriétés système, ils sont une norme indépendante du langage et du système d'exploitation).
Cela me semble vraiment sympa, mais où stocke-t-on les variables d'environnement sans les vérifier dans le contrôle de code source? Et quels outils puis-je utiliser pour transmettre ces variables à l'application? Il peut y avoir des dizaines d'options de configuration, et les taper à la main chaque fois que vous lancez l'application n'est pas sympa - elles doivent donc être stockées dans une sorte de fichier quelque part. Ce fichier finira donc en contrôle de source, et nous reviendrons là où nous avons commencé.
Existe-t-il un moyen universellement accepté de gérer les options de configuration, qui n'a pas le risque de stocker la configuration locale dans le contrôle de code source?
Il n'y a peut-être pas de bonne réponse à cela. Il semble que vous deviez stocker ces données dans un endroit sûr, car elles seront un jour nécessaires à la récupération après sinistre. Cela s'applique également aux fichiers de propriétés et aux scripts qui définissent les variables d'environnement.
- Avec le code source (dans SVN/GIT, etc.) est une très mauvaise idée, car ces données contiendront des mots de passe de base de données de production et autres.
- La sauvegarde nocturne de votre entreprise peut être suffisante, mais il est peu probable qu'elle conserve un historique des modifications facilement accessible.
- Les données doivent être versionnées séparément pour le logiciel consommateur. Dans notre système actuel, un changement de configuration conduit à une nouvelle génération d'application, et c'est tout simplement faux.
Nous recherchons actuellement des solutions à ce problème et nous nous orientons vers un référentiel de code à accès restreint. Ce référentiel contiendrait uniquement des données de cofiguration. Les autres ont-ils des expériences à partager?
En examinant les problèmes et les solutions possibles, cela m'aide à utiliser une méthode popularisée par Jeff Atwood : Si Dieu devait créer un moyen de stocker des informations de configuration sensibles, comment le ferait-il?
Eh bien, il saurait qui a besoin d'informations de configuration et ne les donnerait qu'à ces personnes, et les informations ne seraient jamais accessibles à quiconque.
La première partie doit déjà être prise en charge: votre système de contrôle de code source doit authentifier les utilisateurs. Et cette approche est également validée selon # 10 dans 10 Commandements of Source Control de Troy Hunt , "les dépendances doivent être dans le contrôle de source".
Mais comment le sécuriser en cas de fuite? Eh bien, il n'a pas besoin d'y être stocké en texte clair! Utilisez le cryptage. Dans .NET, vous pouvez suivre certaines étapes pour crypter les données de la chaîne de connexion dans vos fichiers de configuration . Vous devrez trouver les méthodes équivalentes pour le faire avec la technologie de votre choix.
Beaucoup de gens critiquent le stockage de la configuration dans des fichiers normaux avec votre code source, mais d'après mon expérience, c'est en fait une assez bonne solution:
- Simple à implémenter dans n'importe quelle langue. Dans de nombreux cas, vous bénéficiez d'une prise en charge des fichiers de configuration complexes prêts à l'emploi. Par exemple. dans le cas de Java avec Spring Boot, vous obtenez le support YAML qui peut exprimer n'importe quelle structure arborescente, et il est facile d'avoir des fichiers de configuration séparés pour différents environnements ainsi qu'une configuration de base à partir de laquelle les fichiers spécifiques à l'environnement peuvent hériter.
- La configuration est nécessaire pour exécuter votre logiciel et les modifications de code nécessitent souvent l'ajout/la modification de paramètres de configuration, il est donc naturel de conserver la configuration et le code ensemble.
- Le stockage de la configuration avec la source vous offre tous les avantages du contrôle de source, comme savoir qui a modifié quel paramètre et quand ou être en mesure de vérifier les configurations lors d'une révision régulière du code.
- À moins que vous ne travailliez pour la CIA, l'argument de la sécurité me semble exagéré. Ainsi, le mot de passe de votre base de données est stocké dans un fichier sur la machine sur laquelle votre application s'exécute. Eh bien, si quelqu'un a accès à la machine avec votre application, vous avez probablement déjà beaucoup de problèmes - ils peuvent par exemple supprimez votre application et démarrez sa propre application à sa place sur le même port. Dans un tel scénario, l'accès au mot de passe de la base de données peut ne pas être un gros problème. À moins que toutes vos connexions ne soient entièrement cryptées, ayant accès à votre machine, elles peuvent quand même renifler une grande partie des données intéressantes des interfaces réseau.
- Vous pouvez utiliser un outil tel que Hiera pour avoir un fichier de configuration textuel mais pas pour y stocker des mots de passe ou d'autres données sensibles.
Ainsi, dans de nombreux cas, la configuration textuelle stockée dans le contrôle de code source avec le code est un bon début.
Si vous êtes dans des systèmes distribués ou si vous voulez pouvoir échanger à chaud votre configuration sans redéployer vos applications, vous pouvez trouver une solution basée sur un serveur de configuration mieux. Spring Cloud a prise en charge de tels mécanismes , et les configurations de serveur principal peuvent être un référentiel git ou Eureka . Vous pouvez également lancer le vôtre en utilisant par exemple Gardien . Chacune de ces approches facilitera la gestion de configurations cohérentes sur de nombreux serveurs pour mettre à jour les configurations sans avoir à reconstruire et redéployer votre logiciel. Cela a un coût bien sûr, qui est d'apprendre le serveur de configuration et comment l'utiliser à partir de vos applications ainsi que d'un autre système à déployer et à maintenir.
Nous luttons contre le même problème là où je travaille. À l'heure actuelle, toutes nos configurations sont basées sur des fichiers et contrôlées par la source avec les applications individuelles qui les utilisent. Cela conduit à la duplication et aux développeurs ayant accès aux mots de passe de production/qa au lieu du développement.
Cela dit, je pense que nous avons trouvé une bonne solution à l'avenir. Nous déplaçons nos fichiers de configuration vers un référentiel git séparé (appelé le référentiel de configuration). Nous avons ensuite mis en place un serveur Spring-cloud-config (Java) qui sert simplement les fichiers du référentiel de config en fonction des profils qui lui sont passés. C'est très bien pour Java applications qui peuvent utiliser le client et les télécharger au moment du démarrage. Pour nos applications PHP/non Java, nous déroulons le fichier directement. (Pas idéal). Dans le à l'avenir, nous pourrons écrire quelque chose qui permettra à l'application PHP de télécharger les configurations par elle-même et de les mettre en cache quelque part, mais ce n'est pas une priorité élevée pour la première exécution. Je pense que cette solution est la configuration en tant que service qui ne viole pas explicitement les recommandations des 12 applications factorielles.
Je crois que zookeeper peut être utilisé pour la même chose (j'ai vu une configuration avec kubernetes + zookeeper), donc je ne sais pas trop pourquoi cette réponse a obtenu un -1 ci-dessus.
Liens:
Au lieu de stocker la configuration entière dans un fichier, stockez-la dans plusieurs fichiers.
- Avoir un répertoire de configuration . Tous les fichiers sont interprétés comme des fichiers de configuration, sauf peut-être
README*. - Tous les noms de fichiers sont triés par ordre alphabétique et les fichiers sont chargés dans cet ordre. C'est pourquoi les fichiers dans de tels cas commencent souvent par un chiffre ou deux:
01-logging.json.02-database.json, etc. - Les données de tous les fichiers sont chargées dans la même structure de configuration disponible pour l'application. C'est ainsi que plusieurs fichiers peuvent compléter les paramètres des autres, et même les remplacer de manière prévisible.
- Ne stockez dans le VCS que les fichiers de configuration avec des valeurs sûres ou des valeurs par défaut. Ajoutez les fichiers de configuration avec des secrets lors du déploiement ou, mieux encore, utilisez un service de stockage de secrets authentifiés.
Sur la boîte Linux la plus proche, jetez un œil à /etc/sudoers.d ou /etc/nginx/conf.d. Il montre le même schéma.
La gestion des secrets est une bête différente. Vous pouvez les gérer comme une étape manuelle lorsque vous êtes petit. Vous pouvez utiliser des choses comme Zookeeper. Vous pouvez même archiver les secrets dans un VCS sous forme cryptée , et les décrypter comme étape de déploiement. Un certain nombre d'autres options existent.
(En outre, un article d'opinion: JSON n'est pas un bon format de fichier de configuration, car il n'autorise pas les commentaires; les commentaires sont cruciaux. TOML, YAML et même INI sont meilleurs dans la pratique). )
Je pense que vos options sont quelque peu définies par le système d'exploitation sur lequel vous déployez
Je dirais, oui, mettez les valeurs dans le contrôle de source. MAIS seulement les versions "dev". Vous voulez que votre code source compile ET fonctionne! ne pas inclure d'étapes secrètes supplémentaires
Votre processus de génération et de déploiement doit ensuite échanger ces valeurs par environnement pendant le déploiement. (le poulpe a ce genre de modèle)
Apache zookeeper offre de merveilleuses options pour stocker les configurations d'application pour les systèmes distribués. Les modifications apportées à zookeeper peuvent être capturées et traitées en ayant un conservateur ou un auditeur zookeeper à la fin de l'application.