Quali sono i limiti di Puppet rispetto ad Ansible?

16

Vorrei capire le differenze tra Puppet e Ansible, in particolare che tipo di limitazioni Puppet ha rispetto ad Ansible.

Ci sono cose che non puoi fare in Puppet, ma puoi in Ansible? In altre parole, perché alcune persone si spostano da Puppet a Ansible?

ansible comparison puppet

— kenorb
fonte

Ho mantenuto la mia risposta ben separata da questo, uno dei motivi potrebbe essere tutto il denaro che sta investendo.

— ᴳᵁᴵᴰᴼ

19

Ovviamente ci sono molti pro e contro per ciascuno di Puppet, Ansible, Chef e aggiungi anche il tuo strumento preferito qui . Quindi cercherò di stare alla larga dall'opinione e di condividere ciò che è fantastico in Ansible come dato di fatto.

La principale capacità che pone Ansible al di sopra degli altri non è quella di dover fare affidamento su un agente personalizzato / aggiuntivo in esecuzione sui nodi di destinazione, ma basandosi solo su connessioni ssh. Sì, richiede ancora un server ssh, Python e un sacco di librerie Python sui nodi, e se la tua distribuzione (o, buona fortuna, ci sono alcuni nodi di Windows) non viene fornita con loro, sarà un po ' doloroso al bootstrap. Ma è improbabile e potrebbe anche farti pensare di nuovo alla tua distribuzione.

Ciò semplificherà il monitoraggio, non consumerà risorse aggiuntive, non forzerà il sistema a eseguire un demone come root in qualsiasi momento e, in generale, si sente meglio all'interno della filosofia UNIX. Chef ha chef-solo, Puppet può essere eseguito senza master, ma entrambi funzionano "nell'altra direzione", rispettivamente mediante clonazione e tramite hook. Mentre con Ansible, un'unione nel repository di origine può innescare la distribuzione in un modo a cui tutti siamo a nostro agio, sia in Jenkins, nel master git, o in qualche altro strumento come Rundeck, ad esempio.

— ᴳᵁᴵᴰᴼ
fonte

Vale la pena notare che se hai incasinato la tua configurazione ssh con Ansible sei bloccato fuori dalla tua macchina, questo è lo svantaggio del modello push. Le marionette o lo chef possono lavorare su un lavoro crontab in modo che non abbiano alcun impatto sul sistema rispetto al semplice codice Python

— Tensibai

1

Una nota sugli agenti: sono stato approvato per il funzionamento di Ansible in un ambiente HSE (ambiente ad alta sicurezza) da un team di sicurezza che aveva rifiutato Chef e Puppet, anche in una configurazione senza master. In alcuni casi, l'agente è un fattore vincente.

— Woodland Hunter

2

Se interrompi la configurazione di SSH, hai comunque problemi oltre Ansible. È buona prassi DevOps testare cose come i cambiamenti SSH in vari ambienti prima che arrivino alla produzione, ed è anche possibile convalidare la configurazione SSH è corretta durante la scrittura: il templatemodulo Ansible lo rende abbastanza semplice.

— RichVel,

Ho sentito che la gente ha sostenuto che l'architettura senza agente di Ansible la rende più adatta per la gestione, ad esempio, di router, dove non è possibile installare un agente Puppet, per esempio. Ma tali dispositivi sono dotati di interpreti Python? Forse no, quindi Python è davvero un forte requisito per ogni componente gestito da Ansible?

— Drux l'

9

No, le persone che si spostano da Puppet ad Ansible (o viceversa) non hanno nulla a che fare con ciò che può o non può essere realizzato con nessuno dei due strumenti. Puppet / Chef / Ansible - è principalmente una questione di gusti.

Ad esempio, Ansible si basa su Python e gli sviluppatori Python in genere si sentono più a loro agio con esso (non è necessario imparare un DSL) o Ruby (per Chef)). Più facile anche per gli sviluppatori Python estendere Ansible.

Ma in sostanza sono tutti molto simili in termini di ciò che puoi ottenere. Alcuni hanno punti di forza relativi in alcune aree e punti deboli in altri, ma in genere la scelta tra loro è fatta dallo stile / cultura / preferenza del team.

— Assaf Lavie
fonte

7

Fino a Puppet 4.0 non esisteva un modo semplice per orchestrare la diffusione delle applicazioni su più server o servizi, poiché era difficile ordinare azioni specifiche in Puppet, che era una scelta progettuale . Ansible era migliore nell'orchestrare e ordinare i passaggi, soprattutto su più server. Ciò è stato particolarmente significativo nelle applicazioni in cui un ordine errato di passaggi potrebbe portare a errori irrecuperabili attraverso la ripetizione di tali passaggi fino a quando non è stata raggiunta un'eventuale coerenza.

Questo non è più un problema e quindi le distinzioni sono in gran parte basate sulle preferenze.

— Jiri Klouda
fonte

2

La scelta del design del pupazzo è stata una delle ragioni per cui Chef ha iniziato e il principale che mi sono trasferito a Chef per la nostra infrastruttura e il nostro sistema di CD alcuni anni fa.

— Tensibai,

2

L'orchestrazione delle marionette è solo una funzione (commerciale) delle marionette, mentre l'orchestrazione in Ansible è nella versione open source. In genere Ansible è molto più facile da installare e da imparare rispetto a Puppet: dopo aver fatto una valutazione di entrambi, ora utilizzo Ansible. Ci sono anche altre differenze, quindi non è solo una questione di preferenze personali.

— RichVel,

1

Sto usando Ansible sia nel mio lavoro precedente che in quello attuale, ma ha i suoi problemi. Più utilizzo Ansible, più mi interessa apprendere un'altra alternativa. Preferirei questa alternativa per non usare Python per lo sviluppo di moduli e per avere una comunità open source vitale attiva. Le richieste pull out per Ansible richiedono quasi un anno per essere riviste. Di questo passo, potrebbe anche essere proprietario.

— Jiri Klouda,

1

Molte persone si lamentano dell'agente fantoccio, ma quando sei sul cloud e fai un gruppo con scalabilità automatica e non vuoi ricostruire l'immagine della tua vm, è bene che vm si connetta al burattinaio, non vedo alcun problema a avere un piccolo agente.

— c4f4t0r,