Usa git per più file di configurazione del server

Abbiamo migrato molto codice sorgente su git e siamo molto soddisfatti della nostra soluzione attuale. Vorremmo avere i nostri file di configurazione del server aggiornati sullo stesso sistema, ma ci sono alcune cose che non funzionano come vorremmo e spero che qualcuno possa condividere la sua esperienza qui.

Questa domanda è simile all'utilizzo del controllo di revisione per i file di configurazione del server? , ma abbiamo alcuni requisiti speciali che non funzionano con i suggerimenti su quella domanda.

L'impostazione corrente utilizza la sovversione per i file di configurazione. Il repository corrispondente è simile a questo

 / # root del repository
 + - www.domain.com/ # configuration per www
 | \--eccetera/
 | \ - apache2 /
 + - dev.domain.com/ # configuration per dev
 | + - etc /
 | \--optare/
 | \ - app1 /         
 | \ - conf / # configuration per app1 su dev
 \ - staging.domain.com/ # configurazione per la stadiazione

Con Subversion questo funzionerebbe perfettamente, perché è possibile effettuare il checkout di una sottodirectory di un repository. Inoltre è possibile utilizzare svn: externals per puntare a una struttura comune per diverse configurazioni di configurazione. Dovevamo solo gestire i file .svn in tutte le directory con versione. Git d'altra parte non ha svn: gli esterni e i checkout sparsi richiedono sempre che il percorso dalla radice alla directory effettiva sia lo stesso.

Quando ho discusso della migrazione a git, ho provato a scrivere i requisiti principali per il controllo delle versioni della configurazione del server:

• vogliamo solo un singolo repository
• dovrebbe essere possibile inviare facilmente le modifiche al telecomando centrale
• i changeset dovrebbero contenere il vero autore

C'è un buon modo per avere tutta la configurazione in un repository e avere un sotto-percorso come copia funzionante? Attualmente sto prendendo in considerazione due approcci, ma prima ho voluto porre questa domanda

1. Se il repository .git si trova in una posizione fissa, ad es. Da qualche parte in / var , potremmo collegarci al sotto-percorso dalla directory di lavoro "target". Il problema principale: non saprei un modo per "collegare" da / etc a un'altra directory al fine di importare solo i contenuti, tranne il collegamento simbolico di singoli file
2. Ho trovato un'altra alternativa su questa domanda SO , suggerendo di avere più rami in un repository. Ciò aumenterebbe sicuramente la complessità, ma potrei vederci provare in questo modo.

L'uso di git su una singola macchina per la gestione dei file di configurazione funziona bene, ma credo che ci debba essere qualcuno che lo sta usando nel modo in cui vorremmo usarlo.

Grazie
Kariem

Ho usato qualcosa di simile prima; è così che ha funzionato.

Repo Setup

1. Crea un repository git, "etc_files".
2. Creare un ramo per ogni tipo di macchina, ad es. "Server / www", "server / dev", ecc.
   • git supporta le barre nei nomi dei rami. Questo mi aiuta a mantenere i rami dritti nella mia testa.
   • Se hai poche macchine sufficienti, potresti invece avere un ramo per ogni singola macchina.
3. Crea un ramo per ogni infrastruttura condivisa, ad esempio "moduli / apache", "moduli / tazze", ecc.
   • Questi rami servono per contenere file uguali tra tutti i computer, come /etc/resolv.conf. Questi sarebbero i file che conservi nei repository "svn: externals" ora.

Costruire una nuova macchina

1. Su una nuova macchina, clona il repository git e controlla il ramo per quel tipo di macchina.
   • Faccio di questo un clone di sola lettura per impedire alle persone di eseguire modifiche dalle macchine di produzione senza test.
2. Imposta un cron job per git pullil repository automatico ogni giorno.

Modifica dei rami della macchina

La modifica del codice in una singola diramazione della macchina è semplice; solo git checkoutil ramo appropriato nel proprio ambiente di sviluppo, apportare le modifiche e ripristinarle nel repository centrale. Tutte le macchine in quel ramo riceveranno automaticamente le modifiche alla successiva esecuzione del cron job.

Modifica dei rami del modulo

La modifica del codice per un ramo del modulo è solo leggermente più complicata, poiché prevede due passaggi:

1. git checkout il ramo del modulo appropriato
2. Apportare le modifiche e inviarle al server centralizzato.
3. git checkoutogni ramo della macchina che utilizza quel ramo del modulo, quindi unire il ramo del modulo in esso. git scoprirà che hai unito quel ramo del modulo prima e noterà solo i cambiamenti che sono avvenuti dall'ultimo genitore comune.

Questo metodo presenta sia vantaggi che svantaggi. Un vantaggio è che posso apportare una modifica a un ramo del modulo e applicarlo ai rami della macchina che ne hanno bisogno, il che consente ai rami della macchina che non rimangono con la versione precedente fino a quando non sono pronti. Lo svantaggio, quindi, è che devi ricordare di unire il ramo del tuo modulo in ogni ramo della macchina che potrebbe usarlo. Uso uno script che attraversa l'albero di commit e fa automaticamente questa fusione per me, ma può comunque essere una seccatura.

In alternativa, le versioni più recenti di git supportano qualcosa chiamato " sottomoduli ":

I sottomoduli consentono ai repository esterni di essere incorporati in una sottodirectory dedicata dell'albero dei sorgenti, sempre puntata su un commit particolare.

Ciò ti consentirebbe di creare qualcosa di simile agli alberi "svn: externals", che potresti aggiornare più o meno allo stesso modo in cui lo fai ora.

Un po 'di confusione qui, ma sembra che un hook di ricezione post possa fare il lavoro

Repo master è memorizzato in / var / master,
l'hook lo clona su / var / localclone,
quindi copia i dettagli specifici dell'host
Dovresti impostare l'hook .git / post-reception localmente su ciascun server (con le impostazioni appropriate)

Sembra anche che tu voglia qualcosa di più simile a un burattino o uno chef che a git per questo, questo ti permetterebbe di eseguire git per gestire centralmente le configurazioni e i moduli e avere burattini \ chef a gestire la distribuzione e la verifica per te

ecco un lavoro veloce che ho pensato a
1. Avere un repository centrale in dire /var/repo
2. Mettere i file che sono globali per tutti i domini in quella directory.
3. Creare rami per ogni sottodominio /var/repo/subdomain1, /var/repo/subdomain2ecc.
4. Creare un gancio di post in cui qualsiasi push al ramo viene unito al master.

Pertanto, quando si modifica la configurazione /var/repo/subdomain2, viene immediatamente unito al master in modo da poter estrarre completamente il repository e disporre di tutti i file di configurazione.
Quando si desidera estrarre le singole configurazioni del sottodominio, è sufficiente estrarre il ramo appropriato.

Come inserire i tuoi file di configurazione /var/repo/*è una questione completamente diversa (schede cron, mi viene in mente)

~ $