Quali sono le domande giuste da porre quando si decide se utilizzare Chef o Puppet?

Sto per iniziare un nuovo progetto che, in parte, richiederà l'implementazione di molti nodi identici di circa tre classi diverse:

• Nodi dati , che eseguiranno istanze frammentate di MongoDB.
• Nodi dell'applicazione , che eseguiranno istanze di un'applicazione Ruby on Rails e un'applicazione ASP.NET MVC precedente.
• Elaborazione di nodi , che eseguiranno i lavori richiesti dai nodi dell'applicazione.

Tutti i nodi verranno eseguiti su istanze di Ubuntu 10.04, anche se avranno pacchetti diversi installati.

Ho una certa familiarità con lo Chef di progetti precedenti, anche se non mi considero un esperto. Nel tentativo di fare la dovuta diligenza, ho studiato possibilità alternative. Abbiamo un certo numero di persone che sono utenti di marionette da molto tempo e mi hanno incoraggiato a dare un'occhiata.

Tuttavia, ho problemi a valutare entrambe le scelte. Chef e Puppet condividono la stessa terminologia del dominio: pacchetti , risorse , attributi e così via, e hanno una storia comune che deriva dall'approccio diverso allo stesso problema. Quindi in un certo senso sono molto simili. Ma molte delle informazioni di confronto che ho trovato, come questo articolo , sono un po 'datate.

Se avessi iniziato questo progetto oggi, quali domande ti porresti per decidere se utilizzare Chef o Puppet per la gestione della configurazione? (Nota: non voglio rispondere alla domanda "Dovrei usare Chef o Puppet?")

Puppet e Chef possono fare quello che vuoi bene. Il tuo meglio sarà iniziare a fare quello che stai cercando di fare e decidere quale strumento ti piace di più. Penso che le grandi domande che devi porre siano:

Vuoi una DSL? - Le ricette dello chef sono scritte in rubino, il burattino ha una DSL. Che una DSL sia una buona o una cattiva scelta è una delle maggiori differenze tra chef e burattino. Il link che hai pubblicato per il confronto di bitfield consulting contiene alcuni buoni commenti a riguardo che dovresti leggere se non l'hai già fatto. Ho anche trovato utile questo post sul blog , assicurati di leggere anche i commenti.

Conosci il rubino? - Se non conosci il rubino, iniziare con lo chef può essere più difficile o richiedere un investimento di tempo maggiore poiché devi imparare una nuova lingua. Puppet ha una sua lingua con cui è facile iniziare. A partire da Puppet 2.6, i manifest possono essere scritti anche in ruby .

All'Open Source Bridge nel 2009, avevano un gruppo di autori e rappresentanti di chef, burattini, bcfg2, cfengine e automateit che puoi guardare su bliptv che ha 1,75 ore di discussione sulle utility di gestione della configurazione.

Opscode / Chef parla anche della differenza tra esso e le marionette nelle loro FAQ .

Penso che non conoscere le domande giuste da porre potrebbe derivare dal fatto che non hai troppa esperienza di lavoro con nessuno dei due, una volta che inizi a usarli inizierai a vedere le differenze tra di loro. Suggerirei di venire con alcuni problemi di vita reale che risolverai con lo chef o il burattino, quindi inizi a provare a risolverli e vedere cosa ti piace / non ti piace di loro. Con Opscode / Chef, offrono una soluzione ospitata che consente di impostare 5 nodi gratuitamente per iniziare.

Lasciatemi dire per primo - se non state usando Puppet o Chef; non c'è una risposta sbagliata. O sarà molto meglio di quello che stai facendo ora.

Come capo squadra, ho fatto la scelta per Puppet per la mia squadra. Se fossi stata una squadra solo per me, avrei scelto Chef invece. Ecco perché:

Mentre la mia esperienza è sicuramente nell'amministrazione dei sistemi, il mio background è nella programmazione. È quello per cui sono andato a scuola e non sono estraneo a scrivere applicazioni complete (non solo script). Anche se non conoscevo Ruby, lo volevo e lo Chef sarebbe stata un'ottima scusa per andare ad imparare entrambi.

Tuttavia, il mio team è pieno di amministratori di sistema con poca o nessuna esperienza di programmazione, a parte lo script di shell occasionale. Per loro, scrivere un modulo fantoccio è molto simile alla scrittura di un file di configurazione. È dichiarativo, non ci sono iteratori e nel complesso è più facile da gestire.

Squadre piene di sviluppatori che svolgono attività di amministratore di sistema tendono a preferire lo Chef. Poiché il DSL di Puppet è dichiarativo, l'ordine (anche all'interno di singoli file) non ha importanza, e questo frustra molti abituati al linguaggio di programmazione più tipico.

Ho anche sentito dire molte volte che Chef è molto più cloud-friendly di Puppet, ma Puppet ha focalizzato l'attenzione sul proprio prodotto Puppet Enterprise nell'ultimo anno. Non posso parlare per esperienza sulle capacità del cloud di entrambi i prodotti.

A causa di queste qualità, lo stereotipo (ed è spesso corretto) è che troverai Puppet più pervasivo nell'impresa su macchine fisiche, dove Chef governa le startup nel cloud. Ci sono ovviamente delle eccezioni, ma quello che ho visto sostiene sicuramente lo stereotipo.

Se si tratta di un team di una sola persona, quindi valutare entrambi e scegliere quale ti piace. Tuttavia, se come me hai un team di persone, assicurati di mantenere le esigenze del tuo team prioritarie rispetto a qualsiasi preferenza personale, ti salverà in seguito quando proverai ad ottenere il buy-in.

Divulgazione completa, non utilizziamo nessuno di questi, sebbene li abbiamo valutati internamente mentre cercavamo di decidere su un sistema di gestione della configurazione. Quindi non considerarmi un esperto su cosa sia uno di questi dopo tutto.

• Quanto è facile ottenere una configurazione dell'istanza?
• Quale configurazione è richiesta sul client per farlo comunicare con il server?

E così via. Puoi rispondere a queste domande molto facilmente da solo: impostale! Ottenere un campione attivo e funzionante è qualche ora del tuo tempo per ogni prodotto, e considerando che qualunque cosa tu usi per questo sarà probabilmente usato per molto tempo, ne vale la pena. Non solo puoi avere un'idea di come gestiscono cose specifiche della piattaforma (ad es. Basate su Debian e apt, basate su RPM e yum), ma ti aiuteranno sicuramente a farti un'idea delle applicazioni.

Tieni presente, inoltre, che tutte le funzionalità del mondo non compenseranno un'interfaccia difficile, inoltre, potrebbe esporre problemi specifici della tua infrastruttura, ovvero cosa succede se i file di configurazione vengono aggiornati in un ordine diverso del previsto?

Questo è il mio consiglio; Chef e Puppet non sono poi così difficili da configurare un server e uno o due client e ti daranno un'esperienza di prima mano su entrambi. Inoltre, se inizi a configurarlo e ti rendi conto che è un dolore enorme, avrai già le conoscenze prima di impegnarti.

Se ci sono persone nel tuo progetto che hanno già esperienza con Puppet, allora ti suggerisco di usare Puppet.

Chef e Puppet sono abbastanza simili, ed entrambi i progetti sono ugualmente di alta qualità. Se hai accesso a persone che hanno già esperienza Puppet, usa Puppet.

Quanto sopra è sicuramente una buona linea guida, mi piace anche porre queste domande generali ogni volta che sto prendendo in considerazione una nuova dipendenza da terze parti.

• Qual è l'età del progetto?
• Quanto è attiva la community (mailing list, bug, irc ecc.)?
• Una buona documentazione solida è fornita con pratiche standard?

Questi sono buoni indicatori del successo complessivo del progetto e possono in qualche modo prevedere la durata della vita.

Cerca di trovare persone che usano Chef o Puppet da più di un paio di mesi e chiedi loro delle loro esperienze.

Per me è strettamente legato alla tradizione di una specifica comunità. Storicamente lo Chef era più vicino ai ragazzi di RubyOnRails. Anche un grande pezzo di popolarità dello Chef nella comunità ROR perché Engineyard ha costruito la propria infrastruttura sopra lo Chef.