Vraag Welke oplossingen bestaan ​​om het gebruik van revisiesturing voor serverconfiguratiebestanden mogelijk te maken? [Gesloten]


In een omgeving met meerdere systeembeheerders, zie ik een paar voordelen bij het toevoegen van de serverconfiguratiebestanden aan een revisiesysteem. Meest opvallend zijn de mogelijkheid om wijzigingen bij te houden, wie ze heeft gemaakt en natuurlijk om terug te kunnen naar bekende werkconfiguren.

Ik ben vooral geïnteresseerd in Unix / Linux-oplossingen, maar ben ook benieuwd naar Windows-implementaties.


85
2018-05-06 17:46


oorsprong


Lijkt te dupliceren of zeer gerelateerd aan deze vraag serverfault.com/questions/3852/... - Zoredache


antwoorden:


Ik heb dit al een tijdje thuis getest (~ 3 hosts), probeer het anders scms (RCS, Subversion, git). De opstelling die op dit moment perfect werkt voor mij is git met de setgitperms haak.

Dingen waar je rekening mee moet houden:

Afhandeling van bestandsrechten en eigendom

  • RCS: doet dit van nature
  • Subversion: als laatste probeerde ik, je had een wikkel nodig svn om dit te doen
  • git: de setgitperms haak behandelt dit op een transparante manier (heeft een rechtvaardige nodig recente versie van git met ondersteuning voor post-checkout haken, hoewel)

Ook als u niet wilt dat al uw /etc onder versiebeheer, maar alleen de bestanden die je hebt aangepast (zoals ik), je hebt dat nodig ondersteunt dit soort gebruik.

  • RCS: werkt sowieso alleen op enkele bestanden.
  • Subversion: Ik vond dit lastig.
  • git: geen probleem, zet "*"op het hoogste niveau .gitignore bestand en voeg alleen die toe bestanden die u wilt gebruiken git add --force

Ten slotte zijn er enkele problematische mappen onder /etc waar pakketten kunnen vallen config-fragmenten die vervolgens worden gelezen door een programma of daemon (/etc/cron.d, /etc/modprobe.d, enz.). Sommige van deze programma's zijn slim genoeg om te negeren RCS-bestanden (bijvoorbeeld cron), sommige zijn niet (bijvoorbeeld modprobe). Hetzelfde met .svn directories. Nogmaals een groot pluspunt voor git (maakt slechts één topniveau .git directory).


52
2018-05-06 18:23



Subversion heeft asvn nodig svn.collab.net/repos/svn/trunk/contrib/client-side/asvn. Archive SVN (asvn) staat de opname van bestandstypes toe die normaal niet door svn worden afgehandeld. Momenteel omvat dit apparaten, symlinks en bestandseigendom / rechten. - Cristian Ciupitu
Heb je overal een opgave van hoe je de haken die je hebt gebruikt moet instellen, ect.? - GruffTech
Een korte beschrijving is hier: jottit.com/jg8h7 - 8jean
Hier is een bericht over het instellen van iets als dit in Arch Linux ARM, in zou hier net zo goed van toepassing moeten zijn. zduck.com/2012/storing-your-raspberry-pi-config-in-git - silent__thought


Ik heb het informeel gedaan met git, maar er is ook de etckeeper project dat een completere en gedetailleerdere implementatie is.


28
2018-05-06 17:47



etckeeper is echt goed - het behandelt het herstellen van permissies (niet ondersteund door git, hg, etc) en ondersteunt je backend naar keuze (inclusief git, hg, bazaar, enz.). Heeft ook integratie in APT, zodat elke keer dat u een apt-get-bewerking uitvoert, de / etc-repository is vastgelegd en de overnachtingsverbintenissen heeft. Ik heb dit al een tijdje gebruikt en over het algemeen is het veel beter dan een vanille VCS te gebruiken, al was het maar voor de permissiefunctie. - RichVel


Een andere optie is om een ​​geautomatiseerd serverconfiguratietool te gebruiken zoals Marionet of cfengine om uw serverconfiguraties in een declaratieve taal te schrijven.

Het is extra werk aan de voorkant, maar met behulp van een hulpprogramma zoals Puppet kunt u automatisch een server opnieuw opbouwen en configureren met zeer weinig menselijke tussenkomst.


23
2018-05-06 18:03



Ja, maar je moet ook je confiectie Puppet / CFengine reviseren. Ik ben ook een fan van revision-controlling van de output, zodat je de vraag "what" kunt beantwoorden was de config op datum x? "en" wat zouden de config moeten zijn volgens de pop? ", en de invoer correleren met de uitgangen voor het oplossen van problemen met het configuratiebeheersysteem. - Rob Chanter


Ik heb geëxperimenteerd met etckeeper dat lijkt redelijk goed te werken. Ik heb geen gecentraliseerde server nodig, wat in sommige situaties belangrijk kan zijn. U kunt verschillende backends van DVCS gebruiken, zodat u degene kunt kiezen waarmee u het meest vertrouwd bent. Het lijkt heel goed te werken voor mij, maar ik heb niet geprobeerd om de andere techneuten waar ik werk te krijgen om het nog te gebruiken.


10
2018-05-06 18:10





Ik heb er naar gekeken Chef de laatste tijd. Niet alleen houdt het templatable (.erb) configs in versiebeheer, maar je kunt acties uitvoeren (zoals herstarten van een dienst nadat je de configs hebt geüpload naar het knooppunt). Chef helpt met pakketbeheer, zodat u het kunt afhankelijkheden verifiëren met elk knooppunt waarmee u een interface hebt (d.w.z. sudo-pakket moet zijn geïnstalleerd). Chef lijkt gemakkelijk uitbreidbaar te zijn in Ruby, dus als je aangepaste processen hebt, kun je het gewoon in het opgegeven kader uitlezen.

Maar heb het nog steeds niet geprobeerd en je moet Ruby op de client en server installeren met de juiste edelstenen (dit is echt niet zo moeilijk). Al met al ziet het er heel gemakkelijk uit om veel servers tegelijk te beheren.


6
2018-05-27 20:49



We gebruiken Chef zwaar (60+ servers) behoorlijk succesvol. Alle recepten en configuratiebestanden worden gecontroleerd in Subversion. - organicveggie


Ik ben Puppet aan het implementeren in onze infrastructuur en het is erg bevorderlijk om de gegevens in versiebeheer te houden.

Ik geef de voorkeur aan Mercurial omdat het gewoon een verzameling bestanden is waarvan sommige metadata zijn opgeslagen in verborgen mappen (gemakkelijk te beheren, gemakkelijk te begrijpen, gemakkelijk te gebruiken).

Mijn Puppet-bestanden zijn op / usr / local / etc / puppet / (FreeBSD 7.1). Alles wat nodig was om Mercurial eraan toe te voegen:

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

Alle wijzigingen worden vastgelegd met een eenvoudige "hg commit". Als een verandering iets slinks, kan ik elke afzonderlijke server terugdraaien naar een bepaalde versie van het bestand (zeg sudoers) met een enkele opdracht.

Geweldige introductie tot Mercurial


3
2018-05-06 19:59





Ik heb Subversion gebruikt op de servers die ik beheer. Werkt prima. Ik heb ook een opgezet Trac Zo hebben we bijvoorbeeld een tijdlijnweergave, ticketsysteem, browsen, etc.

Met behulp van symlinks, cron en subversion heb ik ook geautomatiseerde configuratiedistributie ingesteld op basis van de subversion-repository, waar elke Linux-server een repository bijwerkt met behulp van svn update met scripts (bijvoorbeeld firewall-scripts).


3
2018-05-07 16:19





Hier is een praktijkvoorbeeld: Used Subversion om configuratiebestanden op 4 verschillende servers te beheren. Ik zou aanbevelen om versiebeheer voor configuratiebestanden te gebruiken, om dezelfde reden dat je ze zou gebruiken met code - het is een back-up en een knop voor ongedaan maken allemaal in één. Als ik een veel groter aantal servers zou beheren en ze qua configuratie veel dichter bij elkaar zouden staan, zou ik iets als Puppet gebruiken, zoals gedetailleerd in Berberich's antwoord.

Het idee is dat u één repository kunt hebben waarmee u specifieke mappen op de servers kunt uitchecken (bijv. / Var / named /), dus ik heb beiden een geschiedenis en een back-up van configuratiebestanden (de back-up is een bonus als u de fout maakt van het gebruik van een GUI-configuratietoepassing die uw met de hand bewerkte toevoegingen wist hoesten Serverbeheerder in Mac OS X Server hoesten). Het is dan eenvoudig om het op een testserver te testen en vervolgens de productieserver bij te werken met bestanden die werken zonder handmatig bestanden te kopiëren.


2
2018-05-06 19:11





Ik heb een paar jaar geleden een project gemaakt om precies dit te doen: Savon

Het gebruikt subversion om bestanden op te slaan, en heeft een aantal extra functies, zoals het volgen van de eigendomsrechten, toestemmingen en SELinux-context. Het biedt u ook de mogelijkheid uw wijzigingen in het bestandssysteem in lagen logisch te splitsen, zodat u bijvoorbeeld wijzigingen kunt volgen die afzonderlijk naar al uw webservers moeten gaan.


1
2018-05-12 07:13