Puppetize tutto o no?

Avviso: ci sono molte domande teoriche.

Recentemente sto leggendo di Puppet (e sistemi simili) che, come credo, possono semplificare molto il mio lavoro. Ma provo - e purtroppo non riesco - a capire cosa posso "burattare". Posso immaginare "cloud" o cluster HA, dove è la stessa configurazione su più server. Ma per quanto riguarda le workstation? Ho un pc (centos con kvm), un notebook (fedora) e un server personale, può (o dovrebbe) essere burattato? Quali sono (dis) vantaggi? O nella nostra azienda abbiamo centinaia di server (principalmente con centos), ma ognuno di essi è un po 'diverso. Non riesci a decidere se è meglio avere un sacco di configurazioni in un unico posto. (Dis) vantaggi? Sarò felice per tutte le tue opinioni o collegamenti a questo argomento.

Il grado in cui è possibile marionizzare un intero ambiente dipende da diverse variabili:

• La volontà del personale dell'automazione di scrivere automazioni per tutti. poco. cosa.
• Il condizionamento culturale che permette a "cambierò solo questa cosa, è comunque una tantum" per trasformarsi in "cambierò solo questa cosa in questo manifesto fantoccio e lo applicherò ora; è solo una tantum ".
• Il grado di eterogeneità in un ambiente.

È sicuramente possibile marionizzare ogni cosa ********** che può essere burattata, ma per arrivarci è necessaria la cultura e il buy-in giusti da parte di chiunque sia in grado di toccare un dispositivo fantoccio. Alcuni dispositivi sono fondamentalmente difficili da gestire in questo modo, cose come le workstation e le marionette sono meglio come strumento di gestione temporanea rispetto a un motore di gestione della configurazione.

Puppet è fantastico quando gestisci una flotta di VM che fanno quasi tutte la stessa cosa. Vittoria totale e non molti sforzi per arrivarci.

All'altra estremità dello spettro hai quello che avevo nel mio ultimo lavoro, che era più di 200 server che offrivano 130 servizi e solo un piccolo gruppo di loro lo faceva con più di una macchina. Ci sono assolutamente aziende (e università) che hanno fatto questo genere di cose, ma è un grande sforzo e richiede molto buy-in. Richiede che il primo passo del processo di distribuzione di una nuova macchina non sia "Installa SO", ma "crea manifest".

In definitiva, si tratta di un problema culturale tra sforzo e efficienza che dovrai risolvere tra tutto il personale IT.

Tutto ciò che è ragionevolmente simile su tutti i sistemi (o un sottoinsieme di essi) o che è possibile basare un modello su un fatto da cui è possibile uscire facterè un gioco equo.

Le cose davvero uniche che probabilmente non dovresti disturbare e dovrebbero semplicemente servire le configurazioni da un filebucket.

Ciò che rientra in entrambe le categorie è una decisione che non possiamo prendere senza conoscere intimamente il tuo ambiente, quindi è quello che devi capire.

Penso che gli altri abbiano spiegato il perché, quindi mi occuperò del come. Penso che capendo come qualcuno potrebbe usare Puppet per fare ciò che vuoi, renderà la decisione più chiara.

Fai prima il caso base

Il modulo Puppet per Apache non dovrebbe fare molto per impostazione predefinita. Installa Apache, configuralo su uno standard minimo e avvia il servizio. Fai in modo che funzioni su tutte le distro che devi supportare.

Aggiungi flessibilità secondo

Dobbiamo aggiungere vhosts. Ti ritroverai con un sistema che può eliminare i file o rimuoverli da una serie di directory conf.d o vhosts.d / in base alle tue esigenze. Stessa cosa con l'abilitazione o la configurazione dei moduli.

Utilizzare le classi di ruolo o hostgroup per unire i blocchi predefiniti

Penso che il modo migliore per usare Puppet sia assicurarsi che sia additivo. Usando gli esempi sopra, dovremmo avere un modulo che lo fa

1. Installa Apache
2. Imposta le configurazioni di base
3. Aggiungi vhosts ad apache
4. Configura eventuali impostazioni extra
5. Avvia Apache

Invece di sovraccaricare il nostro modulo Apache predefinito per fare esattamente ciò di cui abbiamo bisogno per un determinato host o gruppo, dovremmo gestire questo è un ruolo o una classe hostgroup.

class role::web_cust1 {
  include apache
  apache::vhost {'www.domain.com': }
  apache::vhost {'www.domain2.com': priority => '99', }
  include php
  include php-fpm
  include mysql
}

Ancora additivo.

Metti casi speciali in Hiera

Sono un grande fan di lasciare che Puppet's Hiera, lo pensi come un database per Puppet, memorizzi i pezzi speciali. Se un determinato host o hostgroup ha bisogno di un'impostazione speciale, prima di tutto inserisci un modulo predefinito sano in modo che gli utenti normali non debbano conoscerlo. Quindi inserisci i dati per quegli host o hostgroup speciali in modo che Hiera possa consumarli e passarli a Puppet secondo necessità.

Il mio caso d'uso è la porta di ascolto. Alcuni server hanno una vernice o un haproxy davanti a loro. Per impostazione predefinita, il modulo Puppet ha Apache che utilizza la porta 80, ma se Hiera trova dati sostituirà quel valore predefinito.

Sono attualmente nella transizione tra Puppetize sistemi ragionevolmente simili a Puppetize tutto e sono convinto che a lungo termine Puppetize tutto sia un approccio migliore.

Se controlli la versione dei tuoi manifest Puppet (lo facciamo tutti, giusto) otterrai tutti i vantaggi del controllo delle versioni per la tua infrastruttura. Il tuo team diventa ingegnere operativo. Ciò è importante per i sistemi speciali una tantum delle aziende zootecniche omogenee. Si ottiene un registro di chi ha cambiato qualcosa, quando lo hanno cambiato, qual è stato il cambiamento esatto e la possibilità di ripristinare il cambiamento.

Personalmente, trovo anche che forzarmi a fare ogni cambiamento con Puppet mi fa riflettere più attentamente sul cambiamento. Mentre scrivo manifest, sono più attento a ogni modifica di quanto non stia tipicamente tagliando dalla riga di comando.

Anche i moduli Puppet miglioreranno. Hai più di un modulo Nginx? Forse questo significa che il tuo modulo Nginx non è eccezionale, e devi renderlo abbastanza flessibile per gestire tutte le tue esigenze speciali. Almeno astraggono le somiglianze in un modulo Nginx core che estendi per moduli "personalizzati".

Inoltre, quanto sei sicuro di poter ripristinare tutti i tuoi server con esigenze speciali al loro stato attuale (rispetto alla configurazione) quando si verifica il disastro? Se ogni modifica necessaria per inserire un server Ubuntu di fabbrica nel tuo wiki interno è Puppetized, puoi facilmente ricostruire lo stato corrente del tuo wiki, incluso il tweak memory di Tomcat di ieri di Bob.

Infine, questo può essere davvero difficile. La gestione di molti server molto diversi può portare a un po 'di codice Puppet hacktastic se non ti prendi il tempo per fare le cose nel modo giusto. Se non stai usando Puppet Enterprise, considera hiera e / o un ENC come Foreman per aiutarti a separare i tuoi dati dai tuoi manifest. Ogni giorno fantoccio qualcos'altro. Avere un collega di lavoro mentre spieghi come funziona in Puppet. Ogni modifica sarà più semplice.