Dans un environnement avec plusieurs administrateurs système, je vois quelques avantages à ajouter les fichiers de configuration du serveur dans un système de contrôle de révision. Les plus notables sont la possibilité de suivre les changements, de savoir qui les a effectués et, bien sûr, de pouvoir revenir à des configurations connues et fonctionnelles.
Je suis principalement intéressé par les solutions Unix/Linux, mais je serais également curieux de voir les implémentations Windows.
Je suis en train de mettre en œuvre Puppet sur l'ensemble de notre infrastructure, et il est très favorable à la conservation de ses données sous contrôle de version.
Je préfère Mercurial car il s'agit simplement d'une collection de fichiers avec quelques métadonnées stockées dans des répertoires cachés (facile à gérer, facile à comprendre, facile à utiliser).
Mes fichiers Puppet se trouvent dans /usr/local/etc/Puppet/ (FreeBSD 7.1). Il a suffi d'y ajouter Mercurial :
> cd /usr/local/etc/puppet
> hg initToutes les modifications sont validées par un simple "hg commit". Si une modification hostile quelque chose, je peux ramener chaque serveur à une version donnée du fichier (disons, sudoers) avec une seule commande.
J'ai utilisé Subversion sur les serveurs que je gère. Cela fonctionne bien. J'ai également mis en place un Trac Nous disposons donc d'une vue chronologique, d'un système de billetterie, d'une navigation, etc.
En utilisant des liens symboliques, cron et subversion, j'ai également mis en place une distribution automatique de la configuration basée sur le dépôt subversion, où chaque serveur Linux met à jour un dépôt à l'aide de svn update avec scripts (par exemple, pare-feu scripts).
Voici un cas concret d'utilisation : Utilisation de Subversion pour gérer les fichiers de configuration sur 4 serveurs différents. Je recommande d'utiliser le contrôle de version pour les fichiers de configuration pour la même raison que pour le code - c'est une sauvegarde et un bouton d'annulation tout en un. Si je devais gérer un nombre beaucoup plus important de serveurs et qu'ils étaient beaucoup plus proches en termes de configuration, j'utiliserais quelque chose comme Puppet, comme indiqué dans la réponse de Berberich.
L'idée est d'avoir un référentiel dans lequel vous pouvez extraire des dossiers spécifiques sur les serveurs (par exemple /var/named/) afin d'avoir à la fois un historique et une sauvegarde des fichiers de configuration (la sauvegarde est un bonus si vous faites l'erreur d'utiliser une application de configuration GUI qui vous essuie la main). toux Administrateur de serveur dans Mac OS X Server toux ). Il est alors facile de le tester sur un serveur de test et de mettre ensuite à jour le serveur de production avec des fichiers qui fonctionnent sans avoir à copier manuellement des fichiers.
J'ai créé un projet il y a quelques années pour faire exactement cela : Savon
Il utilise subversion pour stocker les fichiers, et possède quelques fonctionnalités supplémentaires, comme le suivi de la propriété, des permissions, et du contexte SELinux. Il vous permet également de diviser logiquement vos modifications du système de fichiers en couches, de sorte que vous pouvez par exemple suivre séparément les modifications qui doivent être apportées à tous vos serveurs web.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
