Quelles solutions existent pour permettre l'utilisation du contrôle de révision des fichiers de configuration du serveur?
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 des révisions. Les plus notables sont la possibilité de suivre les modifications, qui les a apportées et bien sûr de pouvoir revenir à des configurations de travail connues.
Je suis principalement intéressé par les solutions Unix/Linux, mais je serais également curieux des 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 crochet setgitperms .
Éléments à considérer:
Gestion des autorisations et de la propriété des fichiers
- RCS: fait nativement
- Subversion: la dernière fois que j'ai essayé, vous aviez besoin d'un wrapper autour de
svnpour ce faire - git: le crochet
setgitpermsgère cela de manière transparente (nécessite une version assez récente de git avec le support depost-checkoutcrochets, cependant)
De plus, si vous ne voulez pas tous vos /etc sous contrôle de version, mais uniquement les fichiers que vous avez réellement modifiés (comme moi), vous aurez besoin d'une scm qui prend en charge ce type d'utilisation.
- RCS: ne fonctionne de toute façon que sur des fichiers uniques.
- Subversion: J'ai trouvé que c'était délicat.
- git: pas de problème, mettez "
*"dans le niveau supérieur.gitignorefichier et ajoutez uniquement les fichiers de votre choix à l'aide degit add --force
Enfin, il existe des répertoires problématiques sous /etc où les packages peuvent supprimer des extraits de configuration qui sont ensuite lus par un programme ou un démon (/etc/cron.d, /etc/modprobe.d, etc.). Certains de ces programmes sont suffisamment intelligents pour ignorer les fichiers RCS (par exemple cron), d'autres non (par exemple modprobe). Même chose avec .svn répertoires. Encore un gros plus pour git (ne crée qu'un seul niveau supérieur .git répertoire).
Je l'ai fait de manière informelle avec git, mais il y a aussi le projet etckeeper qui est une implémentation plus complète et détaillée.
Une autre option consiste à utiliser un outil de configuration de serveur automatisé comme Puppet ou Cfengine pour écrire vos configurations de serveur dans un langage déclaratif.
C'est un travail supplémentaire sur le front-end, 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 qui semble assez bien fonctionner. Je n'ai pas besoin d'un serveur centralisé, ce qui peut être important dans certaines situations. Vous pouvez utiliser plusieurs backends DVCS différents, vous pouvez donc choisir celui que vous connaissez le mieux. Cela semble très bien fonctionner pour moi, mais je n'ai pas encore essayé d'obtenir les autres technologies où je travaille pour commencer à l'utiliser.
J'ai étudié Chef récemment. Non seulement il conserve templatable (.erb) configs dans le contrôle de version, mais vous permet d'effectuer des actions (comme redémarrage d'un service après avoir téléchargé les configs sur le nœud). Chef aide à la gestion des packages afin que vous puissiez vérifier les dépendances avec n'importe quel nœud avec lequel vous vous connectez (c'est-à-dire que le package Sudo doit être installé). Chef semble être facilement extensible dans Ruby, donc si vous avez des processus personnalisés, vous pouvez simplement les écrire 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). Globalement, il semble vraiment facile de gérer de nombreux serveurs sur une fois que.
Je suis en train d'implémenter Puppet à travers notre infrastructure, et c'est très propice à garder ses données sous contrôle de version.
Je préfère Mercurial car c'est juste une collection de fichiers avec des 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). Tout ce qu'il a fallu pour y ajouter Mercurial:
> cd /usr/local/etc/puppet
> hg init
Toutes les modifications sont validées avec un simple "hg commit". Si un changement modifie quelque chose, je peux restaurer chaque serveur à une version donnée du fichier (par exemple, sudoers) avec une seule commande.
J'utilise Subversion sur les serveurs que je gère. Fonctionne bien. J'ai également mis en place une instance Trac , nous avons donc une vue chronologique, un système de billetterie, une navigation, etc.
En utilisant des liens symboliques, cron et Subversion, j'ai également installé une distribution de configuration automatisée basée sur le référentiel Subversion, où chaque serveur Linux met à jour un référentiel en utilisant svn update avec des scripts (par exemple, des scripts de pare-feu).
Voici un cas d'utilisation réel: Subversion utilisé pour gérer les fichiers de configuration sur 4 serveurs différents. Je recommanderais d'utiliser le contrôle de version pour les fichiers de configuration pour la même raison que vous les utiliseriez avec du code - c'est une sauvegarde et un bouton d'annulation tout en un. Si je gérais une quantité beaucoup plus grande de serveurs et qu'ils étaient beaucoup plus proches en termes de configuration, j'utiliserais quelque chose comme Puppet comme détaillé dans la réponse de berberich.
L'idée est que vous pouvez avoir un référentiel que vous pouvez extraire des dossiers spécifiques sur les serveurs (par exemple./Var/named /) donc j'ai à 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 efface vos ajouts modifiés à la main toux Admin Serveur dans Mac OS X Server toux). Il est ensuite facile de le tester sur un serveur de test et de mettre à jour le serveur de production avec des fichiers qui fonctionnent sans copier manuellement les fichiers.
J'ai créé un projet il y a quelques années pour faire exactement cela: Savon
Il utilise Subversion pour stocker des fichiers et dispose de fonctionnalités supplémentaires, telles que le suivi de la propriété, des autorisations et du contexte SELinux. Il vous permet également de diviser logiquement les modifications de votre système de fichiers en couches, de sorte que vous pouvez par exemple suivre les modifications qui devraient aller à tous vos serveurs Web séparément.
Subversion est très facile à configurer et à utiliser et il existe de nombreuses ressources:
La plupart de nos modifications sont gérées avec notre système Help Desk, même pour les tâches de type maintenance de routine. Nous avons lentement déplacé notre documentation dans un wiki pour notre propre usage et ce que nous publions aux utilisateurs finaux. Publier les changements de configuration et la discussion derrière, c'est bien d'avoir ouvert sur notre intranet.
Pendant de nombreuses années, j'ai utilisé rcs pour les fichiers que j'ai commencé à modifier, mais il y a quelques années, j'ai commencé à mettre tout/etc sous contrôle git. Il faut un peu de travail pour archiver les fichiers en vrac (j'utilise parfois une énorme consignation "diverses mises à jour"), et j'ai écrit quelques scripts pour aider à cela, mais etckeeper mentionné semble très intéressant, je vais essayer immédiatement.