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


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.


85
2018-05-06 17:46


origine


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


Réponses:


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

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 svn pour faire ça
  • git: le setgitperms crochet gère cela de manière transparente (nécessite un version récente de git avec support pour post-checkout crochets, cependant)

En outre, si vous ne voulez pas tous vos /etc sous contrôle de version, mais seulement les fichiers que vous avez réellement modifiés (comme moi), vous aurez besoin d’une scm prend 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, put "*"au plus haut niveau .gitignore déposer et ajouter seulement ceux fichiers que vous voulez utiliser git add --force

Enfin, il existe des répertoires problématiques sous /etc où les colis peuvent tomber 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 assez intelligents pour ignorer Fichiers RCS (par exemple, cron), certains ne le sont pas (par exemple, modprobe). Même chose avec .svn répertoires. Encore un gros avantage pour git (crée seulement un top-level .git annuaire).


52
2018-05-06 18:23



Subversion a besoin d'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 de fichiers. - Cristian Ciupitu
Avez-vous une écriture n'importe où montrant 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


Je l'ai fait de manière informelle avec git, mais il y a aussi le etckeeper projet qui est une mise en œuvre plus complète et détaillée.


28
2018-05-06 17:47



etckeeper est vraiment bon - il gère la restauration des permissions (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


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

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


23
2018-05-06 18:03



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


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.


10
2018-05-06 18:10





J'ai examiné Chef dernièrement. Non seulement il garde modèle (.erb) dans le contrôle de version, mais vous permet d’effectuer des actions (comme redémarrer un service après avoir téléchargé les configurations sur le nœud). Chef vous aide dans la gestion des paquets pour que vous puissiez vérifier les dépendances avec tout nœud avec lequel vous vous connectez (c’est-à-dire que le paquet sudo doit être installé). 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.


6
2018-05-27 20:49



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


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).

Mes fichiers de marionnettes 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
2018-05-06 19:59





J'utilise Subversion sur les serveurs que je gère. Fonctionne bien. J'ai aussi mis en place un Trac par exemple, nous avons donc une vue de la chronologie, système de billetterie, 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 de svn update avec des scripts (par exemple, des scripts de pare-feu).


3
2018-05-07 16:19