Quelles solutions existent pour permettre l'utilisation du contrôle de révision pour les fichiers de configuration du serveur? [fermé]


85

Dans un environnement avec plusieurs administrateurs système, je vois quelques avantages à ajouter les fichiers de configuration du serveur à un système de contrôle de révision. Les plus remarquables sont la capacité de suivre les changements, leur auteur et, bien sûr, la possibilité de revenir à des configurations de travail connues.

Je suis principalement intéressé par les solutions Unix / Linux, mais je serais également intéressé par les implémentations Windows.


Semble dupliquer ou être très lié à cette question serverfault.com/questions/3852/…
Zoredache

Réponses:


52

J'ai testé cela à la maison (~ 3 hôtes) pendant un certain temps, en essayant différents scms (RCS, Subversion, git). La configuration qui fonctionne parfaitement pour moi maintenant est git avec le setgitpermscrochet.

Choses que vous devez considérer:

Gestion des autorisations de fichiers et de la propriété

  • RCS: est-ce natif
  • Subversion: la dernière fois que j'ai essayé, vous aviez besoin d'un wrapper svnpour le faire
  • git: le setgitpermshook gère cela de manière transparente (nécessite une version assez récente de git avec le support des post-checkouthooks, cependant)

En outre, si vous ne souhaitez pas /etccontrôler tous vos sous versions, mais uniquement les fichiers que vous avez réellement modifiés (comme moi), vous aurez besoin d'un logiciel SCM prenant en charge ce type d'utilisation.

  • RCS: ne fonctionne de toute façon que sur des fichiers individuels.
  • Subversion: J'ai trouvé cela difficile.
  • git: no probem, mettez " *" dans le .gitignorefichier de niveau supérieur et ajoutez uniquement les fichiers souhaités à l'aide degit add --force

Enfin, il y a quelques répertoires problématiques sous /etcoù les paquets peuvent déposer des extraits de configuration qui sont ensuite lues par un programme ou 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 les .svn annuaires. Encore un gros avantage pour git (crée seulement un .git répertoire de niveau supérieur ).


1
Subversion nécessite asvn svn.collab.net/repos/svn/trunk/contrib/client-side/asvn . Archive SVN (asvn) autorisera l'enregistrement de types de fichiers qui ne sont normalement pas gérés par svn. Actuellement, cela inclut les périphériques, les liens symboliques et les droits de propriété / autorisations sur les fichiers.
Cristian Ciupitu le

Avez-vous une écriture n'importe où indiquant comment installer les crochets que vous avez utilisés, etc.
grufftech

Un bref résumé est ici: jottit.com/jg8h7
8jean

Voici un article sur la configuration d’un système similaire dans Arch Linux ARM, qui devrait s’appliquer également ici. zduck.com/2012/storing-your-raspberry-pi-config-in-git
silent__thought Le

28

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 plus détaillée.


4
etckeeper est vraiment bon - il gère la restauration des autorisations (non supporté par git, hg, etc.) et supporte votre backend de choix (y compris git, hg, bazar, etc.). A également été intégrée à APT pour que chaque fois que vous effectuez une opération apt-get, le référentiel / etc soit validé et effectue des commits du jour au lendemain. Cela fait un moment que je l'utilise et, dans l'ensemble, c'est beaucoup mieux que d'utiliser un VCS vanilla, ne serait-ce que pour la fonctionnalité des autorisations.
RichVel

23

Une autre option consiste à utiliser un outil de configuration de serveur automatisé, tel que Puppet ou Cfengine, pour écrire les configurations de vos serveurs dans un langage déclaratif.

C'est un travail supplémentaire sur le front-end, mais utiliser un utilitaire comme Puppet vous permet de reconstruire et de configurer automatiquement un serveur avec très peu d'intervention humaine.


5
Oui, mais vous devriez également réviser vos configurations Puppet / CFengine. Je suis aussi un partisan de la révision de contrôle de la sortie afin que vous puissiez répondre à la question "quelle était la configuration à la date x?" ainsi que "quelle devrait être la configuration selon puppet?", et corréler les entrées avec les sorties pour le dépannage du système de gestion de la configuration.
Rob Chanter

10

J'ai expérimenté avec etckeeper qui semble fonctionner assez bien. Je n'ai pas besoin d'un serveur centralisé, ce qui peut être important dans certaines situations. Vous pouvez utiliser plusieurs serveurs DVCS différents pour choisir celui que vous connaissez le mieux. Cela semble fonctionner très bien pour moi, mais je n'ai pas encore essayé de le faire utiliser par les autres techniciens avec lesquels je travaille.


6

Je me suis intéressé à Chef ces derniers temps. Cela permet non seulement de conserver les configurations modifiables (.erb) dans le contrôle de version, mais vous permet également d'effectuer des actions (comme le redémarrage d'un service après avoir téléchargé les configurations sur le nœud). Chef facilite la gestion des packages pour vous permettre de vérifier les dépendances avec tous les nœuds avec lesquels vous êtes en interface (le package sudo doit être installé par exemple). Chef semble être facilement extensible en Ruby, alors si vous avez des processus personnalisés, vous pouvez simplement en faire un script dans le cadre fourni.

Mais ne l’avez 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 très facile de gérer plusieurs serveurs à la fois.


Nous utilisons beaucoup Chef (plus de 60 serveurs) avec succès. Toutes les recettes et les fichiers de configuration sont archivés dans Subversion.
organicveggie

3

Je suis en train d'implémenter Puppet dans notre infrastructure, ce qui est très propice au maintien de ses données dans le contrôle de version.

Je préfère Mercurial car il ne s'agit que d'une collection de fichiers contenant des métadonnées stockées dans des répertoires cachés (facile à gérer, facile à comprendre, facile à utiliser).

Les fichiers de ma marionnette se trouvent dans / usr / local / etc / puppet / (FreeBSD 7.1). Tout ce qu'il fallait pour y ajouter Mercurial:

> cd /usr/local/etc/puppet
> hg init

Toutes les modifications sont validées avec un simple "commit hg". Si une modification nécessite quelque chose, je peux ramener chaque serveur à une version donnée du fichier (par exemple, sudoers) avec une seule commande.

Grande introduction à Mercurial


3

J'utilise Subversion sur les serveurs que je gère. Fonctionne bien. J'ai également mis en place une instance de Trac . Nous avons donc une vue de la chronologie, un système de ticket, une navigation, etc.

Utilisation de liens symboliques, de cron et de subversion J'ai également mis en place une distribution de configuration automatisée basée sur le référentiel de subversion, chaque serveur Linux mettant à jour un référentiel à l'aide svn updatede scripts (par exemple, des scripts de pare-feu).


2

Voici un cas d'utilisation pratique: Utilisé Subversion pour gérer les fichiers de configuration sur 4 serveurs différents. Je vous recommande 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 un nombre beaucoup plus important de serveurs et que leur configuration était plus proche, j'utiliserais quelque chose comme Puppet, comme indiqué dans la réponse de berberich.

L'idée est que vous pouvez avoir un référentiel dans lequel vous pouvez extraire des dossiers spécifiques sur les serveurs (par exemple, / var / named /), de sorte que je dispose d'un historique et d'une sauvegarde des fichiers de configuration (la sauvegarde est un bonus si vous commettez l'erreur. d'utiliser une application de configuration de l' interface qui efface vos ajouts modifié manuellement toux admin serveur sous Mac OS X Server toux ). Il est ensuite facile de le tester sur un serveur de test, puis de mettre à jour le serveur de production avec des fichiers qui fonctionnent sans copier manuellement les fichiers.


1

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é, les autorisations et le contexte SELinux. Il vous permet également de scinder logiquement les modifications apportées au système de fichiers en couches, de sorte que vous puissiez par exemple suivre les modifications qui doivent être appliquées séparément à tous vos serveurs Web.



0

La plupart de nos modifications sont gérées avec notre système Help Desk, même pour les tâches de maintenance courante. Nous avons lentement déplacé notre documentation vers un wiki pour notre propre usage et ce que nous publions aux utilisateurs finaux. Afficher les modifications de configuration et la discussion qui s’y déroule est un plaisir d’être ouvert sur notre intranet.


0

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é à placer tout / etc sous le contrôle de Git. Il faut un peu de travail pour archiver des fichiers en vrac granulaire (parfois, j’ai recours à une énorme "mise à jour variée"), et j’ai écrit quelques scripts pour vous aider, mais le nom de l’agent de maintenance mentionné semble très intéressant, j’essaierai immédiatement.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.