Cosa NON deve essere gestito da burattino?

Sto imparando la mia strada attraverso la gestione della configurazione in generale e usando Puppet per implementarlo in particolare, e mi chiedo quali aspetti di un sistema, se ce ne sono, non dovrebbero essere gestiti con Puppet?

Ad esempio, di solito diamo per scontato che i nomi host siano già impostati prima di prestare il sistema alla gestione delle marionette. La connettività IP di base, almeno sulla rete utilizzata per raggiungere il burattinaio, deve funzionare. L'uso di Puppet per creare automaticamente file di zone DNS è allettante, ma i puntatori inversi DNS dovrebbero essere già in atto prima di avviare la cosa o i certificati diventeranno divertenti.

Quindi dovrei tralasciare la configurazione IP di Puppet? O dovrei configurarlo prima di avviare il burattino per la prima volta ma gestire comunque gli indirizzi IP con il burattino? Che dire dei sistemi con più IP (ad es. Per WAN, LAN e SAN)?

Che dire di IPMI ? Puoi configurarne la maggior parte, se non tutte, con ipmitool , risparmiandoti l'accesso alla console (fisico, seriale su LAN, KVM remoto, qualunque cosa) in modo che possa essere automatizzato con le marionette. Ma ricontrollare il suo stato ad ogni corsa di agenti fantoccio non mi sembra interessante, e le luci di base che accedono al sistema sono qualcosa che mi piacerebbe avere prima di fare qualsiasi altra cosa.

Un'altra storia completa riguarda l'installazione degli aggiornamenti. Non sto andando in questo punto specifico, ci sono già molte domande su SF e molte filosofie diverse tra amministratori di sistema diversi. Io stesso, ho deciso di non lasciare che le marionette aggiornino le cose (solo per esempio ensure => installed) e facciano gli aggiornamenti manualmente come siamo già abituati, lasciando l'automazione di questa attività a un giorno successivo quando siamo più sicuri con le marionette (ad esempio aggiungendo MCollective a il mix).

Erano solo un paio di esempi che mi sono venuti in mente in questo momento. C'è qualche aspetto del sistema che dovrebbe essere lasciato fuori dalla portata delle marionette? Oppure, detto in un altro modo, dov'è la linea di demarcazione tra cosa dovrebbe essere impostato al momento del provisioning e "staticamente" configurato nel sistema e cosa viene gestito attraverso la gestione centralizzata della configurazione?

Regola generale: se stai utilizzando la gestione della configurazione, gestisci tutti gli aspetti della configurazione che puoi. Più centralizzi, più facile sarà ridimensionare il tuo ambiente.

Esempi specifici (paralizzati dalla domanda, tutti i racconti "Ecco perché vuoi gestirlo"):

Configurazione della rete IP

OK, certo, hai configurato un indirizzo / gateway / NS sulla macchina prima di lasciarlo cadere nel rack. Voglio dire, se non lo facessi, come faresti a correre fantoccio per fare il resto della configurazione?

Ma ora dì che aggiungi un altro nameserver al tuo ambiente e devi aggiornare tutte le tue macchine - Non vuoi che il tuo sistema di gestione della configurazione lo faccia per te?

Oppure dì che la tua azienda viene acquisita e che la tua nuova società madre richiede che passi dal tuo indirizzo 192.168.0.0/24 al 10.11.12.0/24 per adattarlo al loro sistema di numerazione.

O improvvisamente ottieni un enorme contratto governativo - L'unico problema è che devi attivare IPv6 GIUSTO FREAKIN 'ORA o l'accordo è saltato ...

Sembra che la configurazione di rete sia qualcosa che vorremmo gestire ...

Configurazione IPMI

Proprio come con gli indirizzi IP, sono sicuro che hai impostato questo prima di mettere la macchina nel rack - È solo un buon senso comune abilitare IPMI, console remota, ecc. Su qualsiasi macchina che abbia la capacità e quelle configurazioni don cambierò molto ...

... Fino a quella ipotetica acquisizione che ho citato in Configurazione IP sopra - Il motivo per cui sei stato costretto a liberare quegli indirizzi 192.168-net è perché quella è terra IPMI secondo i tuoi nuovi padroni aziendali, e devi andare ad aggiornare tutte le tue schede IPMI ORA perché calpesteranno lo spazio IP riservato di qualcuno.

OK, è un po 'un tratto qui, ma come hai detto - tutto può essere gestito con ipmitool, quindi perché non far funzionare Puppet lo strumento e confermare la configurazione mentre sta facendo tutto il resto? Voglio dire, non farà male a niente, quindi potremmo anche includere anche IPMI ...

aggiornamenti

Gli aggiornamenti del software sono più un'area grigia - Nella mia organizzazione abbiamo valutato il pupazzo per questo e lo abbiamo trovato "gravemente carente", quindi lo utilizziamo radmindper questo scopo. Non c'è motivo per cui Puppet non possa chiamare radmind - In realtà se / quando migriamo su Puppet per la gestione della configurazione, è esattamente quello che succederà!

La cosa importante qui è avere tutti gli aggiornamenti installati in modo standard (standard all'interno dell'organizzazione o standard all'interno delle piattaforme) - Non c'è motivo per cui Puppet non dovrebbe avviare il processo di aggiornamento, purché sia ​​stato accuratamente testato tutto per garantire che Puppet non rovini nulla.
Non c'è nemmeno motivo per cui Puppet non possa chiamare uno strumento più adatto a questo compito se hai stabilito che Puppet non può fare un buon lavoro da solo ...

Non reinventare la ruota.

Sì, puoi avere 50 risorse utente virtuali fantoccio e realizzarle secondo necessità nei tuoi moduli ... ma se puoi, usa LDAP.

Parlo per amara esperienza. Anche se ldap non è ancora un'opzione qui.

Un altro esempio è la rimozione dei file host, anziché l'utilizzo del DNS.

• Puppet non è un sistema di orchestrazione. In particolare:
  • Puppet non è adatto all'orchestrazione delle VM, in quanto le VM hanno un ciclo di vita proprio che dovrebbe essere rispettato.
  • Puppet non è adatto alla gestione delle versioni dell'applicazione / aggiornamenti complessi. A questo scopo si potrebbero sfruttare le marionette autonome, ma almeno non è Puppet in controllo, ma sono i tuoi script wrapper o un robot umano, il che va bene.
• Puppet non è un buon sistema di gestione degli utenti (deve essere in grado di gestire tutte le voci degli utenti, anche quelle cancellate, per essere efficace. Quindi trova un'altra soluzione)
• Puppet non è un buon database di configurazione (guarda usando un database esterno di qualche tipo, e un ENC, Hiera o una colla simile)

Ovviamente puoi fare tutte queste cose con Puppet .. ma non è la soluzione migliore per loro. A volte dovresti posare il martello e andare a cercare una chiave inglese.

Puppet è tuttavia estremamente bravo a mantenere la configurazione di base per una macchina e ad installare gli strumenti che consentono di eseguire VM e rilasciare orchestrazione, gestione utenti ecc.

Sono principalmente d'accordo con voretaq7, ma con un paio di avvertenze.

• Raramente ho mai configurato l'indirizzamento IP nelle marionette, a meno che il sistema non usi DHCP (suppongo che la maggior parte dei grandi fornitori "cloud" lo faccia). Ho avuto situazioni in cui ho rotto le configurazioni di rete con le marionette, ma non sono riuscito a correggerle con le marionette perché il nodo non aveva modo di contattare il burattinaio.

• Sono fermamente convinto che la gestione degli aggiornamenti sia nelle mani degli strumenti di sistema e non vedo l'uso di Puppet come cron glorificato per migliorare.

Nel mio caso, ho uno script bootstrap che carica la configurazione minima del sistema (Ubuntu): Ruby, Rubygems, build-essential, git, ecc. I manifest di My Puppet sono tenuti sotto controllo della versione e clonerò semplicemente il repository. Da lì, il mio script bootstrap fa un'ipotesi hostname --shortvalida e tenta di farlo puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Per rispondere alla tua domanda:

• I miei script assumono la connettività di rete di base (DNS, IP) e non la gestiscono o la cambiano;
• I miei script presumono che l'identità della macchina sia corretta e non la cambiano;
• I miei script presumono che Ruby / Rubygems / Git sia presente, ma lo gestiscono in seguito.

Pensi di non aver bisogno di usare le marionette per la configurazione della rete. Una volta è una cosa configurata di solito. Inoltre puoi ottenere qualche schifezza se avrai un errore (i) con IP o MAC o qualcosa di simile che porterà con le marionette.