Quali soluzioni esistono per consentire l'uso del controllo di revisione per i file di configurazione del server? [chiuso]

In un ambiente con più amministratori di sistema, vedo alcuni vantaggi nell'aggiungere i file di configurazione del server in un sistema di controllo delle revisioni. I più importanti sono la capacità di tracciare i cambiamenti, chi li ha fatti e, naturalmente, essere in grado di tornare alle configurazioni di lavoro conosciute.

Sono principalmente interessato alle soluzioni Unix / Linux, ma sarei curioso anche per le implementazioni di Windows.

Ho provato questo a casa (~ 3 host) da qualche tempo, provando diversi scms (RCS, Subversion, git). Il setup che funziona perfettamente per me in questo momento è git con il setgitpermsgancio.

Cose che devi considerare:

Gestione delle autorizzazioni e della proprietà dei file

• RCS: lo fa nativamente
• Subversion: l'ultima volta che ho provato, ti serviva un wrapper svnper farlo
• git: l' setgitpermshook lo gestisce in modo trasparente (necessita però di una versione abbastanza recente di git con supporto per gli post-checkouthook)

Inoltre, se non vuoi avere tutto il /etccontrollo sotto versione, ma solo i file che hai effettivamente modificato (come me), avrai bisogno di uno scm che supporti questo tipo di utilizzo.

• RCS: funziona comunque solo su singoli file.
• Subversion: l'ho trovato complicato.
• git: nessun problema, inserisci " *" nel .gitignorefile di livello superiore e aggiungi solo i file che desideri utilizzaregit add --force

Infine, ci sono alcune directory problematici sotto /etcdove i pacchetti possono cadere frammenti di configurazione che vengono poi letti da qualche programma o demone ( /etc/cron.d, /etc/modprobe.d, ecc). Alcuni di questi programmi sono abbastanza intelligenti da ignorare i file RCS (ad es. Cron), altri no (ad es. Modprobe). Stessa cosa con le .svn directory. Ancora una volta un grande vantaggio per git (crea solo una .git directory di livello superiore ).

L'ho fatto in modo informale con git, ma c'è anche il progetto etckeeper che è un'implementazione più completa e dettagliata.

Un'altra opzione è quella di utilizzare uno strumento di configurazione del server automatizzato come Puppet o Cfengine per creare script delle configurazioni del server in un linguaggio dichiarativo.

È un lavoro extra sul front-end, ma l'utilizzo di un'utilità come Puppet consente di ricostruire e configurare automaticamente un server con un intervento umano molto limitato.

Ho sperimentato etckeeper che sembra funzionare abbastanza bene. Non ho bisogno di un server centralizzato, che può essere importante in alcune situazioni. Puoi utilizzare diversi backend DVCS diversi, in modo da poter scegliere quello con cui hai più familiarità. Sembra funzionare molto bene per me, ma non ho ancora provato a trovare gli altri tecnici dove lavoro per iniziare ad usarlo.

Ho cercato Chef di recente. Non solo mantiene le configurazioni templatable (.erb) nel controllo versione, ma consente di eseguire azioni (come riavviare un servizio dopo aver caricato le configurazioni sul nodo). Chef aiuta nella gestione dei pacchetti in modo da poter verificare le dipendenze con qualsiasi nodo con cui si interfaccia (cioè deve avere installato il pacchetto sudo). Lo chef sembra essere facilmente estensibile in Ruby, quindi se hai processi personalizzati puoi semplicemente scriverlo all'interno del framework fornito.

Ma non l'ho ancora provato e devi installare Ruby sul client e sul server con le gemme appropriate (questo non è poi così difficile). Nel complesso sembra davvero facile gestire molti server contemporaneamente.

Sono in procinto di implementare Puppet attraverso la nostra infrastruttura ed è molto favorevole a mantenere i suoi dati nel controllo della versione.

Preferisco Mercurial poiché è solo una raccolta di file con alcuni metadati memorizzati in directory nascoste (facile da gestire, facile da capire, facile da usare).

I miei file Puppet sono in / usr / local / etc / puppet / (FreeBSD 7.1). Tutto ciò che è stato necessario per aggiungere Mercurial ad esso:

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

Tutte le modifiche vengono eseguite con un semplice "commit hg". Se una modifica genera qualcosa, posso ripristinare ogni singolo server su una determinata versione del file (diciamo, sudoers) con un solo comando.

Ottima introduzione a Mercurial

Ho usato Subversion sui server che gestisco. Funziona bene. Ho anche impostato un'istanza Trac , quindi abbiamo una visualizzazione della sequenza temporale, un sistema di ticketing, navigazione, ecc.

Utilizzando symlink, cron e subversion ho anche impostato la distribuzione automatica della configurazione basata sul repository subversion, in cui ogni server Linux aggiorna un repository utilizzando svn updatecon script (ad esempio script firewall).

Ecco un caso d'uso reale: usato Subversion per gestire i file di configurazione su 4 server diversi. Consiglio di utilizzare il controllo versione per i file di configurazione per lo stesso motivo per cui li useresti con il codice: è un backup e un pulsante Annulla tutto in uno. Se stessi gestendo un numero molto più grande di server e fossero molto più vicini in termini di configurazione, userei qualcosa come Puppet come dettagliato nella risposta di berberich.

L'idea è che è possibile disporre di un repository in cui è possibile effettuare il checkout di cartelle specifiche sui server (ad es. / Var / named /), quindi entrambi ho una cronologia e un backup dei file di configurazione (il backup è un vantaggio se si commette l'errore di utilizzare un'applicazione di configurazione della GUI che cancella la tosse aggiunta a mano Server Admin in Mac OS X Server tosse ). È quindi facile testarlo su un server di prova e successivamente aggiornare il server di produzione con file che funzionano senza copiare manualmente i file.

Ho creato un progetto qualche anno fa per fare esattamente questo: Savon

Usa la sovversione per archiviare i file e ha alcune funzionalità aggiuntive, come il monitoraggio della proprietà, le autorizzazioni e il contesto SELinux. Inoltre, consente di dividere logicamente le modifiche del file system in livelli, ad esempio è possibile tenere traccia delle modifiche che dovrebbero andare separatamente a tutti i server Web.

Subversion è molto facile da configurare e utilizzare e ci sono molte risorse:

Istruzioni di base

Libro SVN

Panoramica sulla gestione dei documenti

La maggior parte delle modifiche viene gestita con il nostro sistema di Help Desk, anche per le attività di manutenzione ordinaria. Abbiamo lentamente spostato la nostra documentazione in una wiki per nostro uso e ciò che pubblichiamo per gli utenti finali. Pubblicare le modifiche alla configurazione e la discussione alle spalle, è bello averlo aperto sulla nostra intranet.

Per molti anni ho usato rcs per i file che ho iniziato a modificare, ma un paio di anni fa ho iniziato a mettere l'intero / etc sotto controllo git. Richiede un po 'di lavoro per il check-in dei file in blocchi granulari (a volte ricorro a un enorme check-in "vari aggiornamenti"), e ho scritto alcuni script per aiutare con questo, ma etckeeper menzionato sembra molto interessante, lo proverò immediatamente.