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.
J'ai testé cela à la maison (~ 3 hôtes) depuis un certain temps maintenant, en essayant différents scms (RCS, Subversion, git). La configuration qui fonctionne parfaitement pour moi en ce moment est git avec le site setgitperms crochet.
Les choses que vous devez prendre en compte :
Traitement des permissions et de la propriété des fichiers
svn pour ce fairesetgitperms s'en occupe de manière transparente (il faut une version récente de git avec le support de post-checkout crochets, cependant)Aussi, si vous ne voulez pas que tous vos /etc sous contrôle de version, mais seulement mais seulement les fichiers que vous avez réellement modifiés (comme moi), vous aurez besoin d'un scm qui qui supporte ce type d'utilisation.
* "dans la version de haut niveau .gitignore et n'ajoutez que les que vous voulez en utilisant git add --force
Enfin, il existe des répertoires problématiques sous la rubrique /etc où les colis peuvent être déposés qui sont ensuite lus par un programme ou un démon ( /etc/cron.d , /etc/modprobe.d etc.). Certains de ces programmes sont assez intelligents pour ignorer les fichiers RCS (par exemple, cron), d'autres ne le sont pas (par exemple, modprobe). Même chose avec .svn les répertoires. Encore une fois, c'est un gros avantage pour git (qui ne crée qu'un seul répertoire de premier niveau). .git ).
Une autre option consiste à utiliser un outil de configuration automatisée du serveur comme Marionnette ou Cfengine pour script vos configurations de serveur dans un langage déclaratif.
C'est un travail supplémentaire en amont, mais l'utilisation d'un utilitaire comme Puppet vous permet de reconstruire et de configurer automatiquement un serveur avec très peu d'intervention humaine.
J'ai fait des expériences avec etckeeper ce qui semble fonctionner assez bien. Il ne nécessite pas de serveur centralisé, ce qui peut être important dans certaines situations. Vous pouvez utiliser plusieurs backends DVCS différents, ce qui vous permet de choisir celui avec lequel vous êtes le plus familier. Il semble fonctionner très bien pour moi, mais je n'ai pas encore essayé de convaincre les autres techniciens de mon lieu de travail de l'utiliser.
Je me suis penché sur Chef dernièrement. Non seulement ça garde modulable (.erb) dans le contrôle de version, mais vous permet d'effectuer des actions (telles que redémarrage d'un service après avoir téléchargé les configurations sur le nœud). Chef aide à la gestion des paquets afin que vous puissiez vérifier les dépendances avec tout nœud avec lequel vous vous interfacez (c'est-à-dire qu'il doit avoir le paquet sudo installé). Chef semble être facilement extensible en Ruby, donc si vous avez des processus personnalisés, vous pouvez juste script le sortir dans le cadre fourni.
Mais je ne l'ai toujours pas essayé et vous devez installer Ruby sur le client et le serveur avec les gemmes appropriées (ce n'est vraiment pas si difficile). Dans l'ensemble, il semble très facile de gérer plusieurs serveurs à la fois.
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.
