Come possono i ragazzini imparare e usare efficacemente Puppet? [chiuso]

Sei mesi fa, nel nostro progetto no profit abbiamo deciso di iniziare a migrare la gestione del nostro sistema in un ambiente controllato da Puppet perché prevediamo che il nostro numero di server crescerà sostanzialmente tra adesso e un anno da oggi.

Da quando è stata presa la decisione, i nostri ragazzi IT sono diventati un po 'troppo infastiditi un po' troppo spesso. Le loro maggiori obiezioni sono:

• "Non siamo programmatori, siamo amministratori di sistema";
• I moduli sono disponibili online ma molti differiscono l'uno dall'altro; le ruote vengono reinventate troppo spesso, come si decide quale si adatta al conto;
• Il codice nel nostro repository non è abbastanza trasparente, per scoprire come funziona qualcosa che devono ricorrere attraverso manifesti e moduli che potrebbero essersi persino scritti un po 'di tempo fa;
• Un nuovo demone richiede la scrittura di un nuovo modulo, le convenzioni devono essere simili agli altri moduli, un processo difficile;
• "Eseguiamolo e vediamo come funziona"
• Tonnellate di "estensioni" poco conosciute nei moduli della community: "trocla", "augeas", "hiera" ... come possono tenere traccia i nostri amministratori di sistema?

Posso capire perché una grande organizzazione avrebbe inviato i propri amministratori di sistema ai corsi di marionette per diventare maestri di marionette. Ma in che modo i giocatori più piccoli imparerebbero Puppet a livello professionale se non frequentassero i corsi e fondamentalmente lo imparassero tramite il loro browser ed editor?

Ho iniziato a utilizzare Puppet prima di implementare una nuova infrastruttura e ho semplicemente acquistato un libro ( ben considerato ) sull'argomento. Non penso che la maggior parte delle persone ottenga effettivamente una formazione professionale di marionette. Ho lavorato su esempi fino a quando non ho potuto modellare il processo nel mio ambiente. Era il dicembre 2011, quindi nel giro di poche settimane sono stato in grado di comprendere le basi e creare un quadro produttivo. Non ero nuovo nella gestione della configurazione, con un background di CFEngine , ma risuonano molte delle preoccupazioni dei tuoi amministratori di sistema. Ho fatto errori e ho dovuto refactoring più volte, ma ho fatto funzionare le cose in modo soddisfacente.

Alcune note sui tuoi punti ...

• Il ruolo di amministrazione dei sistemi tradizionali sta cambiando. Adatta o lasciati alle spalle. Sono stato un ingegnere di sistemi di successo, ma devo anche riorganizzare (imparando Python, per esempio). L'attenzione per i singoli server è diminuita man mano che l'astrazione dell'hardware attraverso la virtualizzazione e i servizi cloud pubblici e privati ​​guadagnano trazione. Ciò significa automazione delle attività di sistema e utilizzo della gestione della configurazione per controllare il controllo di un numero maggiore di server. Aggiungi i concetti DevOps al mix e vedrai che le aspettative e i requisiti dei clienti / utenti finali stanno cambiando.

• I moduli fantoccio disponibili online differiscono per stile e struttura e sì, ho visto molte sovrapposizioni, ridondanze e sforzi duplicati. Uno sviluppatore con cui ho lavorato ha detto: "avresti potuto sviluppare i tuoi strumenti nel tempo trascorso a cercare online qualcosa che funzioni!" Ciò mi ha dato una pausa quando mi sono reso conto che Puppet sembra fare appello più ai tipi di sviluppatori che agli amministratori che cercano le migliori pratiche o l' approccio giusto .

• Documenta pesantemente per avere un'idea di come le cose sono collegate. Date le definizioni traballanti e la mancanza di un modo standard di fare le cose, la struttura di gestione della configurazione è davvero unica per il tuo ambiente. Tale trasparenza dovrà essere sviluppata all'interno.

• Direi che è abbastanza facile duplicare un modulo per ospitare un nuovo demone o aggiungere un servizio a un manifest esistente, a seconda di come hai organizzato i tuoi server e ruoli.

• Ho trascorso molto tempo a testare su un singolo target prima di inviare le modifiche a gruppi più grandi di server. L'esecuzione manuale di puppetd su un server rappresentativo mi ha permesso di eseguire il debug delle modifiche e valutarne l'impatto. Forse è un po 'conservativo, ma era necessario.

• Non sono sicuro di quanto dipenderei dai moduli della community. Ho dovuto iniziare ad usare Augeas per qualche lavoro , e mi sono lamentato del fatto che si trattava di una funzionalità che ho dato per scontato in CFEngine.

Nel complesso, mi sento come se non ci fosse uno standard ben definito per quanto riguarda Puppet. Ho avuto difficoltà a capire come organizzare la struttura delle directory sul mio Puppetmaster, capire come gestire la firma dei certificati, ottenere il DNS inverso corretto ovunque, fare in modo che Puppet si ridimensionasse in modo appropriato per l'ambiente e capire quando sfruttare i moduli della comunità anziché costruirne uno mio. È un cambiamento nel modo di pensare e vedo come sarebbe un panico da amministratore di sistema. Tuttavia, questa è stata anche una soluzione costruita da zero, quindi ho avuto il lusso di valutare gli strumenti. La decisione di procedere in questo modo si basava sulla condivisione della mente e sullo slancio dietro Puppet. Ne è valsa la pena imparare qualcosa di nuovo.

Ricorda, anche questo sito è una buona risorsa.

In un precedente lavoro, mi era stato assegnato il compito di realizzare un'implementazione pilota di Puppet. Ora ho un background di programmazione, sebbene non Ruby, quindi non ho molti problemi come altri.

Tuttavia, è interessante notare che i programmatori senza esperienza con paradigmi non tradizionali hanno problemi anche con Puppet, perché Puppet è dichiarativo , non imperativo. In questo senso, Puppet funziona praticamente come qualsiasi file di configurazione: dici come dovrebbero essere le cose e Puppet si occupa di tutto il resto.

Dopo il pilot ho avuto l'opportunità di addestrare una dozzina di altri amministratori con Puppet, oltre a tenere presentazioni al riguardo in due eventi. La mia opinione su quell'esperienza è che alcuni amministratori l'hanno presa e altri no. Questi erano tutti amministratori tradizionali, senza capacità di programmazione e vari livelli di competenza.

Una cosa particolare che ho notato è che Puppet richiede una pratica costante . Le persone che sono state addestrate, hanno scritto moduli e poi hanno trascorso un intero mese o due a fare qualcos'altro tornando a Puppet con poca abilità utile. Le persone che continuavano a fare piccole cose ogni settimana non hanno mai perso l'abilità.

Sulla base di queste due osservazioni, ti consiglio di assicurarti che tutti continuino ad aggiungere alcune classi, definizioni o moduli Puppet ogni settimana (preferibilmente almeno due o tre volte). Coloro che non riescono ancora ad abituarsi potrebbero davvero non avere le capacità per farlo.

Inoltre, se Puppet fosse imposto loro dall'alto, potrebbero semplicemente reagire a ciò che percepiscono come una gestione che si intromette nel modo in cui svolgono il loro lavoro - il che sarebbe abbastanza vero, in effetti. Potrebbe essere il caso che consentire loro di scegliere quale sistema di gestione della configurazione utilizzare migliorerebbe le cose. Ecco alcune alternative:

• ANSIBILE : Questo è nuovo, ma si basa su comandi shell e ssh, che potrebbero allettarlo ai tradizionali amministratori di sistema.
• Chef : Forse il loro problema è lo stile dichiarativo, nel qual caso Chef sarebbe meglio se avessero esperienza di Ruby.
• SaltStack : basato su Python e open-source
• CFEngine : vecchio, veloce, tradizionale - potrebbe conquistarli per quei motivi.

Uso Puppet da più di due anni in piccoli negozi in cui ero l'unico amministratore di sistema. Il più grande ostacolo che ho avuto è imparare a sviluppare correttamente il software. Non è trascorsa una settimana in cui non ho rovinato qualcosa che ho detto agli sviluppatori di non fare una dozzina di volte. Ho controllato troppo codice, non ho interrotto i check-in, non ho taggato, non ho ramificato, non ho eseguito il controllo sintassi, non ho usato uno standard, ecc. Se hai appena iniziato fuori raccomanderei alcune delle seguenti.

1. Realizza che stai sviluppando software che o non sai come fare o che stai facendo male. Questo è previsto perché è nuovo.
2. L'infrastruttura come codice è la realtà e una volta superata la gobba è abbastanza potente. Inviterei alcuni sviluppatori, mostrerei loro il tuo attuale processo di sviluppo (o la loro mancanza), non offendermi quando alzano le sopracciglia e prendo sul serio i loro suggerimenti. Consiglio di utilizzare qualsiasi sistema e processo utilizzato dai tuoi sviluppatori a meno che non sia del tutto inappropriato.
3. I moduli marionette di terze parti assorbono il 90% delle volte. Li avrei letti. Ruberei loro delle idee. Non li inserirei nel mio sistema senza modifiche importanti. Comunque vorrei inserire il pupazzo stdlib che aggiunge alcune belle funzionalità.
4. agosto e hiera. Impara quei due. Il primo consente la modifica complessa di file esistenti in atto. Il secondo è un archivio dati esterno.
5. Separare il codice dai dati. Questo è uno dei concetti più difficili da imparare. Valori hardcoding come il monitoraggio degli host nel codice del tuo modulo non sono validi. Metterli in un archivio dati (db, yaml (Hiera usa questo come predefinito), csv, qualunque cosa) che i tuoi moduli possano usare è buono. Un esempio è una webapp che utilizza Mysql. Ciò che consente è la possibilità di inviare codice e dati separatamente. Ciò semplifica il processo di sviluppo.
6. validazione del parser delle marionette e lanugine delle marionette come parte del processo di checkin pre o post code. Anche i test rspec potrebbero essere una buona idea una volta che sei al passo.
7. scrivere una guida di stile / codice standard e usarlo. "dov'è il codice che installa Apache" è un problema comune. Se i tuoi moduli sono per lo più gli stessi, dovrebbe essere facile.

In sintesi, ho riscontrato tutti questi problemi e quindi molti dei miei amici di amministratore di sistema. Ci vorrà del tempo per diventare bravi a usare un sistema di gestione della configurazione. Una volta fatto, ti chiederai come hai mai vissuto senza uno. "Accedi a un server e apporta le modifiche manualmente? Ick."

Sei mesi fa, nel nostro progetto no profit abbiamo deciso di iniziare la migrazione del nostro sistema di gestione in un ambiente controllato da Puppet perché prevediamo che il nostro numero di server crescerà sostanzialmente tra adesso e un anno da oggi.

Sembra dannatamente una buona idea iniziare presto - Puppet è molto più di una semplice gestione della configurazione, è una forma di documentazione.

Da quando è stata presa la decisione, i nostri ragazzi IT sono diventati un po 'troppo infastiditi un po' troppo spesso.

Hanno bisogno di un adattamento dell'atteggiamento.

"We're not programmers, we're sysadmins";

Ancora una volta, atteggiamento. -Puoi- creare un file conf per un server giusto? Puoi semplificare la creazione di modelli / "programmatori" man mano che le tue esigenze e complessità si evolvono .

I moduli sono disponibili online ma molti differiscono l'uno dall'altro; le ruote vengono reinventate troppo spesso, come si decide quale si adatta al conto;

Difficile rispondere - Preferisco sempre i moduli delle marionette rispetto alla maggior parte - e anche a questo, non ne uso molti. Il giudizio chiama di sicuro. Secondo me, alcuni moduli sono "troppo agili".

Il codice nel nostro repository non è abbastanza trasparente, per scoprire come funziona qualcosa che devono ricorrere attraverso manifesti e moduli che potrebbero essersi persino scritti un po 'di tempo fa;

Questo non suona come un problema fantoccio, ma piuttosto un problema organizzativo o di documentazione?

Un nuovo demone richiede la scrittura di un nuovo modulo, le convenzioni devono essere simili agli altri moduli, un processo difficile;

Quel demone potrebbe essere una classe se è abbastanza semplice da gestire. Non sono sicuro di cosa intendi con convenzioni, il burattino ti applica abbastanza bene le convenzioni, vero? Oppure stiamo parlando lungo la formattazione del codice?

"Let's just run it and see how it works"

Non è poi così male un'idea se la prendi lentamente e in sicurezza. Comincerei ancora con una macchina virtuale per capire le cose.

Tonnellate di "estensioni" poco conosciute nei moduli della community: "trocla", "augeas", "hiera" ... come possono tenere traccia i nostri amministratori di sistema?

moduli postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl .. Scegli cosa vuoi e usalo? Immagino che questo assomigli di più a una cosa di atteggiamento ...

Posso capire perché una grande organizzazione avrebbe inviato i propri amministratori di sistema ai corsi di marionette per diventare maestri di marionette. Ma in che modo i giocatori più piccoli imparerebbero Puppet a livello professionale se non frequentassero i corsi e fondamentalmente lo imparassero tramite il loro browser ed editor?

Non ho frequentato alcun corso - mentre sono un programmatore più che un amministratore di sistema, ho scoperto che non era necessaria molta abilità di programmazione per ottenere risultati.

La documentazione di Puppet, quando seguita, è abbastanza approfondita. Basta prestare attenzione ai tipi integrati e passare un po 'di tempo a guardare come vengono messi insieme altri moduli. Non direi che è -super- facile, ma neanche -hard-. È un po 'di tempo per preparare la tua infrastruttura per le marionette, ma il tempo investito è garantito per essere ben speso durante l'espansione.

KISS (Keep it simple stupid) - Non usare le nuove tecnologie solo perché sono lì piuttosto perché hai un requisito per loro, usa il minimo indispensabile richiesto dalla tua distribuzione, aggiorna come richiesto non cercare di tenere il passo con l'emorragia bordo. Se inizi con un'impostazione di base e ti basi sul fatto che è più facile raccogliere mentre procedi e non dovrebbero aver bisogno di un corso (sono anche disponibili?).

L'altra area che puoi vedere sono i tuoi amministratori di sistema. Se non sono in grado di programmare altrettanto bene, allora sono abbastanza avanzati per un'implementazione di grandi dimensioni, dove la maggior parte del lavoro deve essere programmata con qualsiasi strumento tu usi?

Lavoro anche a scopo non lucrativo ed ero responsabile di portare inizialmente le scatole Linux in casa e poco dopo Puppet per gestirle. Abbiamo fatto un paio di cose specifiche che ci hanno davvero aiutato a far funzionare le cose.

Innanzitutto ho cercato di stare lontano dai moduli di terze parti. Gli strumenti integrati gestiscono il 90% della nostra gestione. La più grande utility di terze parti che utilizzo è il modulo firewall. Eventuali fatti personalizzati, ecc. Vengono sviluppati con l'intero team coinvolto. Abbiamo sviluppato un modulo modello e manteniamo la gestione dei file, il pacchetto, i servizi, ecc. Tutti standardizzati da questo modello.

In secondo luogo, dopo aver standardizzato l'utilizzo dei moduli integrati, abbiamo iniziato a utilizzare Git e Atlassian's Crucible - a titolo gratuito, senza scopo di lucro - per eseguire revisioni di tutte le modifiche alla configurazione. Ciò fornisce la trasparenza desiderata.

In terzo luogo, ho automatizzato l'installazione di Puppet in modo che i nuovi host possano essere aggiunti automaticamente con un set predefinito di opzioni. Esistono diversi modi per affrontarlo. Dato che avevo già un ambiente Kickstart completo, ho deciso di aggiungere uno script lì.

"Non siamo programmatori, siamo amministratori di sistema"

Il mio modo in cui i tempi sono cambiati, in peggio: un greybeard come me avrebbe dovuto essere un programmatore migliore dei programmatori professionisti, altrimenti non sarebbe mai stato in grado di passare per un amministratore di sistema .

Ora abbiamo "amministratori di sistema", che sono fondamentalmente utenti desktop di Windows che a un certo punto si sono convertiti in Linux e non possono programmare e non trovano nulla di sbagliato in questo.

L'elefante nella stanza è il motivo per cui la gestione tollera un atteggiamento così distruttivo. Distruttivo per chi o cosa? All'azienda e all'infrastruttura.

Torna all'argomento Puppet [, CFEngine, Chef]: non appena si pone una soluzione come questa, si perde. Tutti perdono. Perché? Perché chiunque abbia l'idea non è in grado di progettare la gestione della configurazione incapsulata sotto forma di pacchetti di sistema operativo Kickstart [, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM] incentrati su di sé. Quando devi usare uno strumento di hacking automatizzato come Puppet (o Chef o CFEngine), significa che non hai i mezzi per progettare e implementare un processo che, con quello stesso design, imporrebbe completamente incontaminato e spegnerebbe i sistemi gestiti, completamente automatizzato e completamente non interattivo.

Un altro punto importante è, se devi avere Puppet o qualche soluzione simile per correggere manualmente qualcuno che hackera il sistema o la configurazione dell'applicazione, che risale anche al fatto di non avere l'esperienza per progettare un processo, e in quel processo un framework in cui la configurazione è impacchettata in componenti discreti. In effetti, chiunque implementa Puppet e simili, non ha il concetto di proprietari dei componenti, rilasci, gestione della configurazione, modello di maturità delle capacità. Questo sta rapidamente diventando un problema molto serio nel settore.

Lavorare con Puppet mi ha anche aiutato a imparare Ruby, che è arrivato a sostituire Bash come linguaggio predefinito per gli strumenti di sistema ".

Perché è necessario Ruby, quando una gestione completa della configurazione end-to-end può essere incapsulata nelle sezioni preinstall, postinstall, preremove e postremove dei pacchetti del sistema operativo, semplicemente usando i programmi shell Bourne, AWK e sed? Che qualcuno si spinga fino in fondo all'apprendimento di una lingua esoterica di Ruby, e di un suo dialetto nel contesto di Puppet, è completamente inutile. Il problema della gestione della configurazione è facilmente risolvibile (e, per intenderci, è stato risolto) con i programmi di shell e AWK, e un po 'di sed (1) qua e là come una colla.

È una bella sensazione vedere il manifest di Puppet configurare un'intera macchina o un nuovo servizio da zero.

È una cosa ancora più interessante vederlo fatto da Kickstart, AutoYaST o JumpStart, senza una singola riga di codice , ed essere in grado di interrogare il sistema operativo utilizzando strumenti integrati, senza bisogno di alcun software esoterico o extra , nessun client-server architettura richiesta (SSH è più che soddisfacente, molto più che soddisfacente) e vedere il sistema operativo consapevole di ogni singola modifica apportata.

5. Separare il codice dai dati. Questo è uno dei concetti più difficili da imparare. Valori hardcoding come il monitoraggio degli host nel codice del tuo modulo non sono validi. Metterli in un archivio dati (db, yaml (Hiera usa questo come predefinito), csv, qualunque cosa) che i tuoi moduli possano usare è buono. Un esempio è una webapp che utilizza Mysql. Ciò che consente è la possibilità di inviare codice e dati separatamente. Ciò semplifica il processo di sviluppo.

... Oppure si può semplicemente template i file di configurazione con variabili di shell, anche apici (ad esempio ls -1 ...) e scrivere uno script di shell che utilizza AWK chiamare eval (1) ed espandere tutte le variabili nel modello, sfruttando in tal modo la stessa potente parser quali shell hanno incorporato. Perché renderlo complesso, quando può essere davvero, davvero semplice? Dove memorizzerai i valori di configurazione? Perché, ovunque tu voglia, come ad esempio file pkginfo (4), o un database come Oracle, o praticamente ovunque . Non sono necessarie soluzioni ultracomplex. La libreria che menziono sopra potrebbe semplicemente essere ricavata dalle sezioni preinstall o postinstall nei pacchetti del sistema operativo, rimuovendo così la duplicazione e sfruttando un pezzo di codice centrale ...

Ma soprattutto, trovo che la citazione sopra sia un esempio della prossima generazione di amministratori di sistema che necessitano di tutoraggio non dagli amministratori di sistema, ma dagli ingegneri di sistema . Trova te stesso una barba grigia e iscriviti come apprendista.