Orienterò questa risposta come se la domanda fosse "quali sono i vantaggi dello chef-solo" perché è il modo migliore che conosco per coprire le differenze tra gli approcci.
La mia raccomandazione riassuntiva è in linea con gli altri: utilizzare uno chef-server se è necessario gestire un ambiente dinamico e virtualizzato in cui aggiungere e rimuovere nodi spesso. Un server chef è anche un buon CMDB , se ne hai bisogno. Usa chef-solo se hai un ambiente meno dinamico in cui i nodi non cambieranno troppo spesso ma i ruoli e le ricette cambieranno. Le dimensioni e la complessità del tuo ambiente sono più o meno irrilevanti. Entrambi gli approcci si adattano molto bene.
Se distribuisci chef-solo, usa un cronjob con rsync, 'git pull' o qualche altro meccanismo di trasferimento file idempotente per mantenere una copia completa del repository chef su ciascun nodo. Il cronjob dovrebbe essere facilmente configurabile per (a) non funzionare affatto e (b) eseguire, ma senza sincronizzare il repository locale. Aggiungi una directory / nodi nel tuo repository chef con un file json per ciascun nodo. Il tuo cronjob può essere sofisticato quanto desideri in termini di identificazione del giusto file di file (anche se consiglierei semplicemente $ (hostname -s) .json. Puoi anche creare un account opscode e configurare un client con chef ospitato, se per nessun altro motivo se non quello di poter usare il coltello per scaricare libri di cucina della comunità e creare scheletri.
Ci sono diversi vantaggi in questo approccio, oltre all'ovvio "non dover amministrare un server". Il tuo controllo del codice sorgente sarà l'arbitro finale di tutte le modifiche alla configurazione, il repository includerà tutti i nodi e le liste di esecuzione e ogni server essendo completamente indipendente facilita alcuni convenienti scenari di test.
Chef-server introduce un buco in cui si utilizza il "caricamento del coltello" per aggiornare un ricettario e si deve correggere questo buco da soli (come con un hook post-commit) o rischiare che le modifiche al sito vengano sovrascritte silenziosamente da qualcuno che "carica il coltello" s una ricetta obsoleta dal repository locale obsoleto sul suo laptop. È meno probabile che ciò accada con chef-solo, poiché tutte le modifiche verranno sincronizzate con i server direttamente dal repository principale. Il problema qui è la disciplina e il numero di collaboratori. Se sei uno sviluppatore solista o una squadra molto piccola, caricare libri di cucina tramite l'API non è molto rischioso. In una squadra più grande può essere se non si mettono in atto buoni controlli.
Inoltre, con chef-solo puoi memorizzare tutti i ruoli, gli attributi personalizzati e le playlist dei tuoi nodi come file node.json nel tuo repository principale di chef. Con chef-server, i ruoli e le playlist vengono modificati al volo utilizzando l'API. Con chef-solo, puoi tenere traccia di queste informazioni nel controllo di revisione. È qui che si vede chiaramente il conflitto tra ambienti statici e dinamici. Se il tuo elenco di nodi (non importa quanto tempo potrebbe essere) non cambia spesso, avere questi dati nel controllo di revisione è molto utile. D'altra parte, se stai generando frequentemente nuovi nodi e distruggendo quelli vecchi (per non vedere mai più il loro nome host o fqdn), tenere tutto sotto controllo di revisione è solo una seccatura inutile e avere un'API per apportare modifiche è molto conveniente. Chef-server ha un'intera funzionalità orientata anche alla gestione di ambienti cloud dinamici, come l'opzione nome su "coltello bootstrap" che consente di sostituire fqdn come modo predefinito per identificare un nodo. Ma in un ambiente statico queste funzionalità hanno un valore limitato, soprattutto se confrontate con il controllo di ruoli e liste di controllo con qualsiasi altra cosa.
Infine, gli ambienti di test delle ricette possono essere impostati al volo per quasi nessun lavoro extra. Puoi disabilitare i cronjob in esecuzione su un server e apportare modifiche direttamente al suo repository locale. Puoi testare le modifiche eseguendo chef-solo e vedrai esattamente come si configurerà il server in produzione. Una volta che tutto è stato testato, puoi effettuare il check-in delle modifiche e riattivare i cronjobs locali. Quando si scrivono ricette, tuttavia, non sarà possibile utilizzare l'API "Cerca", il che significa che se si desidera scrivere ricette dinamiche (ad esempio loadbalancer), sarà necessario aggirare questa limitazione, raccogliendo i dati dai file json in i tuoi nodi / directory, che probabilmente saranno meno convenienti e mancheranno alcuni dei dati disponibili nel CMDB completo. Ancora una volta, ambienti più dinamici favoriranno l'approccio basato su database, gli ambienti meno dinamici andranno bene con i file json sul disco locale. In un ambiente server in cui un cuoco deve eseguire chiamate API a un database centrale, dipenderà dalla gestione di tutti gli ambienti di test all'interno di quel database.
L'ultimo può essere utilizzato anche in caso di emergenza. Se si sta risolvendo un problema critico sui server di produzione e si risolve con una modifica della configurazione, è possibile effettuare immediatamente la modifica nel repository del server, quindi inviarlo a monte verso il master.
Questi sono i principali vantaggi dello chef-solo. Ce ne sono altri, come non dover amministrare un server o pagare per chef ospitati, ma quelli sono preoccupazioni relativamente minori.
Per riassumere: se sei dinamico e altamente virtualizzato, chef-server offre una serie di fantastiche funzionalità (coperte altrove) e la maggior parte dei vantaggi di chef-solo sarà meno evidente. Tuttavia, ci sono alcuni vantaggi, spesso non menzionati, per lo chef-solo, specialmente in ambienti più tradizionali. Tieni presente che la distribuzione sul cloud non significa necessariamente che hai un ambiente dinamico. Se, ad esempio, non puoi aggiungere più nodi al tuo sistema senza rilasciare una nuova versione del tuo software, probabilmente non sei dinamico. Infine, da una prospettiva di alto livello un CMDB può essere utile per qualsiasi numero di cose solo tangenzialmente legate all'amministrazione e alla configurazione del sistema come la contabilità e la condivisione delle informazioni tra i team. L'uso di chef-server potrebbe valere la pena solo per quella funzione.