Articles

Chef vs Puppet: Differenze, somiglianze e come scegliere

Oggi mettiamo uno contro l’altro due strumenti popolari per la gestione della configurazione: Chef vs Puppet. Questi tipi di strumenti aiutano gli ingegneri a mantenere una configurazione coerente in tutti i server. Per esempio, tutti i server potrebbero aver bisogno di avere IIS con un binding alla porta 443 per l’accesso HTTPS e la rispettiva regola del firewall per il traffico in entrata. Ancora più importante, se qualcuno rimuove la regola del firewall, questo tipo di strumenti manterrà la coerenza creando di nuovo la regola del firewall.

Che mi dici delle stringhe di connessione al database dove ne hai una diversa per dev, test e prod?

Sì, Puppet o Chef possono gestire anche questo.

Il post di oggi è sul confronto tra Chef e Puppet. Sono strumenti molto simili che realizzano lo stesso obiettivo: mantenere uno stato coerente. Ma, differiscono anche nel modo in cui aiutano gli utenti a mantenere la coerenza e la ripetibilità in tutta la pipeline di consegna. Infine, parlerò di come scegliere uno strumento piuttosto che l’altro, a seconda delle vostre esigenze e di quelle del vostro team.

Perciò entriamo nel merito.

Tip: Trova gli errori delle applicazioni e i problemi di performance istantaneamente con Stackify Retrace
La risoluzione dei problemi e l’ottimizzazione del tuo codice è facile con gli errori integrati, i log e gli approfondimenti sulle performance a livello di codice.
Try today for free

Similitudini

Chef e Puppet hanno similitudini nel modo di gestire le configurazioni nei server. Anche se entrambi gli strumenti lavorano internamente in modi diversi, il risultato è lo stesso. Con entrambi gli strumenti, è possibile definire lo stato desiderato attraverso il codice. Entrambi gli strumenti lavorano con un’architettura master-nodo dove il master è incaricato di memorizzare tutti i dati, e i nodi sono incaricati di assicurarsi che i server abbiano sempre la configurazione dello stato desiderato.

Per esempio, uno degli obiettivi principali dell’uso di Chef o Puppet per la gestione della configurazione è che si può definire come codice quello che dovrebbe essere lo stato desiderato di un gruppo di server. Non dovrebbe importare se si vuole applicare la stessa configurazione ai server, Chef e Puppet faranno in modo di implementare qualsiasi cambiamento in modo indipendente. Allo stesso modo, tutti noi premiamo Ctrl + S più volte per assicurarci di salvare le modifiche. Ma dove questo tipo di strumenti brilla è che se qualcuno entra nel server manualmente, e cambia lo stato desiderato del server, questi strumenti porteranno i server aggiornati riconfigurandoli.

Dal punto di vista dell’architettura, Chef e Puppet sembrano abbastanza simili poiché entrambi usano un’architettura master-agente. Un nodo master è dove tutte le configurazioni del server vengono memorizzate. I master di entrambi gli strumenti sono altamente disponibili (HA), ma con leggere differenze – ne parleremo più avanti. Poi, per ogni server che si vuole gestire, c’è un agente installato che tira la configurazione a periodi automaticamente. Gli agenti controllano sempre che lo stato desiderato sia conforme, non il contrario. Entrambi gli strumenti possono gestire server Linux e Windows.

Infine, entrambi gli strumenti hanno una versione open-source e una versione a pagamento con più caratteristiche come una migliore configurazione HA.

Differenze

Ho detto prima che l’architettura di Chef e Puppet sono simili, ma differiscono leggermente su come gestiscono HA. In Puppet, il master replica i suoi dati su un altro server, e lavorano in modo attivo/passivo. Per Chef, la HA è gestita con tre server in modo attivo/attivo con un front end API che può scalare orizzontalmente.

Una differenza significativa tra Chef e Puppet è nel modo in cui definiscono la configurazione dello stato desiderato per i server. Ogni strumento ha il proprio linguaggio specifico del dominio (DSL). Chef usa Ruby per il DSL. Hai più libertà di creare configurazioni complesse perché stai usando un linguaggio di programmazione. Chef chiama queste configurazioni di stato desiderate che si scrivono ricette. Tutto ciò che si può fare con Ruby, si può fare in Chef per creare ricette come le if-conditions o chiamare altre librerie. Il vantaggio di questo è che gli sviluppatori potrebbero sentirsi più a loro agio nello scrivere ricette di Chef. Inoltre, gli sviluppatori non si sentiranno limitati ad un DSL solo, aggiungendo quando si definisce una configurazione.

D’altra parte, Puppet ha il proprio DSL, “che è stato progettato per essere accessibile ai sysadmin”. E se avete esperienza di lavoro con i file di configurazione di Nagios, scrivere manifesti (la loro versione delle ricette di Chef) non sarà un problema. Non avete troppa libertà qui, ma questo è anche un bene dal punto di vista di avere un linguaggio universale. Pertanto, non è necessario avere un background da sviluppatore per usare e imparare Puppet.

Infine, questi strumenti differiscono nel modo di sviluppare e testare le ricette o i manifesti. Chef ha una workstation che include l’SDK di Chef che puoi installare nel tuo computer locale come ambiente di staging. È possibile testare le ricette localmente, quindi caricarle sul nodo master. Puppet non ha una workstation, ma ha un SDK dove è possibile testare i manifesti mentre li si sviluppa. Inoltre, puoi applicare i manifesti localmente con il comando puppet apply.

person wearing white apron walkin on stairs

Esempi

Diamo un’occhiata a un esempio di codice per assicurarci che l’agente Stackify sia installato.

Una ricetta in Chef sarà come questa (puro Ruby):

# ...# bunch of variables declared# ...# download and extract stackify agenttar_extract node do target_dir Chef::Config creates "#{Chef::Config}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}" not_if { File.exist?(stackify_agent_jar_location) }endtemplate_file = "#{Chef::Config}/#{stackify_agent_install_relative_path}/stackify-agent.conf"template template_file do source "stackify-agent.conf.erb"end# run stackify agent install scriptbash 'agent_install' do user 'root' cwd "#{Chef::Config}/#{stackify_agent_install_relative_path}" code <<-EOH ./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options} rm -rf #{Chef::Config}/Linux rm -rf #{Chef::Config}/#{stackify_agent_install_relative_path} EOH not_if { File.exist?(stackify_agent_jar_location) }end

Per Puppet, c’è un modulo per installare l’agente Stackify, e il manifesto sarà come questo:

 class { 'stackify': package_ensure => 'present', package_install_options_environment => 'development', package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', file_download_directory => 'C:\Temp', service_manage => true, service_ensure => true, service_enable => true, }

Come potete vedere, gli esempi di codice sopra confermano quello che ho detto prima. In Chef, avete più libertà. Ma in Puppet, il codice potrebbe sembrare più semplice quando c’è un modulo che puoi usare.

Funzioni premium

Prendiamo il confronto, comprese le funzioni premium, che includono altre cose oltre alla gestione della configurazione.

Per Puppet, hanno Puppet Enterprise che include le seguenti funzionalità:

  • Rapporti che aiutano con le politiche di conformità
  • Orchestrazione di applicazioni e distribuzioni di infrastrutture
  • Automatizzare il provisioning dell’infrastruttura con l’infrastruttura come codice
  • Gestione del codice per promuovere automaticamente i cambiamenti dell’infrastruttura
  • Gestione dei nodi per un controllo granulare dei server
  • Politiche di controllo dell’accesso basate sul ruolo per gli utenti
  • Grazie a Puppet Enterprise.
  • Politiche di controllo dell’accesso basate sul ruolo per gli utenti
  • Supporto via email o telefono

Hanno anche Puppet Remediate, che è uno strumento per la gestione delle vulnerabilità dei vostri server. È possibile ottenere una migliore comprensione di quali vulnerabilità esistono nei vostri server, e applicare le patch su scala a tutti i server.

In Chef, oltre alla gestione della configurazione, la versione a pagamento include le seguenti capacità:

  • Gestione della conformità e della sicurezza
  • Creare pipeline CI/CD e gestire i rilasci per tutte le applicazioni
  • Visibilità con dashboard su tutto lo stack dell’infrastruttura

Si ottengono maggiori dettagli su ogni sito del fornitore, hanno risorse abbastanza buone per aiutarvi ad iniziare rapidamente.

person playing puppet dog

Come scegliere

Come scegliere tra Chef e Puppet è una domanda difficile, e la risposta, come sempre, è … “dipende”. Un buon approccio potrebbe essere considerare il background della squadra. Le persone con un background da sysadmin potrebbero trovare più adatto l’uso di Puppet. Anche se dovranno imparare il DSL, non sarà mai come imparare un linguaggio di programmazione. Anche se, se hanno un background nello sviluppo, alla gente potrebbe piacere di più Chef (anche se non conoscono Ruby).

Ma dovresti anche considerare le caratteristiche premium di ogni strumento. Quale di queste caratteristiche aiuterà la vostra organizzazione a ridurre i silos e gli sprechi? Di nuovo, tutto dipende dalle vostre esigenze. Ho visto che entrambi i fornitori cercheranno sempre di salire di livello l’uno con l’altro con le caratteristiche. Per esempio, in Puppet, è possibile creare funzioni personalizzate con Ruby.

E naturalmente, un altro aspetto essenziale è il prezzo. Non voglio includere i prezzi qui perché fluttuano molto, e variano a seconda delle esigenze di ogni cliente. Un altro motivo è che nel caso di Puppet, la loro pagina dei prezzi non ha un numero pubblico ma un pulsante “Contattaci”. Chef, d’altra parte, la sua pagina dei prezzi ha dei numeri, ma è comunque necessario contattarli. Ti consiglio di contattarli direttamente e cercare una buona offerta. A seconda del numero di server che devi gestire potrebbero offrirti un prezzo migliore.

Non c’è una pallottola d’argento

Come promemoria amichevole, non c’è una pallottola d’argento per uno strumento di gestione della configurazione. Sia Chef che Puppet sono molto maturi al giorno d’oggi, e stanno costantemente migliorando il loro prodotto, facendo investimenti nella ricerca, creando modi migliori per le persone di imparare il loro strumento, ecc. Spero che questo confronto vi abbia aiutato a capire meglio come funzionano entrambi gli strumenti. Forse vi state preparando per un colloquio di lavoro, o siete curiosi di conoscere le principali differenze e somiglianze.

Ma se state decidendo quale strumento utilizzare per la vostra azienda, assicuratevi di avere una chiara idea di quali problemi state avendo e come questo tipo di strumenti possono aiutarvi ad alleviare il carico. Ci sarà sempre una curva di apprendimento, e dipenderà dal background del team e da quale strumento è più adatto a loro. Inoltre, guardate le caratteristiche e i servizi premium oltre alla gestione della configurazione, poiché la vostra azienda potrebbe aver bisogno di più aiuto con le politiche di conformità.

  • Chi è l’autore
  • Ultimi messaggi

Chi è Christian Melendez

Christian Meléndez è un tecnologo che ha iniziato come sviluppatore di software e più recentemente è diventato un architetto cloud focalizzato sull’implementazione di pipeline di consegna continua con applicazioni in diversi gusti, tra cui .NET, Node.js e Java, spesso utilizzando contenitori Docker.

  • AWS Elastic Beanstalk .NET Core Getting Started – January 17, 2020
  • AWS Batch: A Detailed Guide to Kicking Off Your First Job – December 26, 2019
  • Azure Container Service (AKS) – A Detailed Intro – December 18, 2019
  • Sending CloudWatch Custom Metrics From Lambda With Code Examples – November 14, 2019
  • Chef vs Puppet: Differenze, somiglianze e come scegliere – 24 settembre 2019