Quelles sont les limites de Puppet par rapport à Ansible?

17

Je voudrais comprendre les différences entre Puppet et Ansible, en particulier le type de limitations de Puppet par rapport à Ansible.

Y a-t-il des choses que vous ne pouvez pas faire dans Puppet, mais que vous pouvez dans Ansible? En d'autres termes, pourquoi certaines personnes s'éloignent-elles de Puppet à Ansible?

ansible comparison puppet

— Kenorb
source

J'ai gardé ma réponse bien séparée de cela, l'une des raisons peut être tout l'argent qui y investit.

— 2017

20

Il y a bien sûr plusieurs avantages et inconvénients pour chacun de Puppet, Ansible, Chef et ajoutez également votre outil préféré ici . Je vais donc essayer de rester à l'écart de l'opinion et partager ce qui est génial dans Ansible en fait.

La principale capacité qui place Ansible au-dessus des autres n'est pas d'avoir à s'appuyer sur un agent personnalisé / supplémentaire s'exécutant sur les nœuds cibles, mais plutôt sur des connexions ssh uniquement. Oui, cela nécessite toujours un serveur ssh, Python et un tas de bibliothèques Python sur les nœuds, et si votre distribution de choix (ou, bonne chance, il y a des nœuds Windows) ne les accompagne pas, ce sera un peu pénible à bootstrap. Mais c'est peu probable, et cela pourrait même vous faire repenser votre distribution.

Cela simplifiera la surveillance, ne consommera pas de ressources supplémentaires, ne forcera pas le système à exécuter un démon en tant que root tout le temps, et en général, il se sent mieux dans la philosophie UNIX. Le chef l'a fait chef-solo, Puppet peut être exécuté sans maître, mais ils fonctionnent tous les deux «dans l'autre sens», par clonage et via des crochets respectivement. Alors qu'avec Ansible, une fusion dans le référentiel source peut déclencher le déploiement d'une manière avec laquelle nous sommes tous à l'aise, que ce soit dans Jenkins, dans le git master ou dans un autre outil comme Rundeck par exemple.

— ᴳᵁᴵᴰᴼ
source

Il convient de noter que si vous avez foiré votre configuration ssh avec ansible, vous êtes verrouillé hors de votre machine, c'est l'inconvénient du modèle push. La marionnette ou le chef peut travailler sur un travail crontab afin qu'ils n'affectent pas plus le système que le code Python

— ansible

1

Une note sur les agents: j'ai été approuvé pour embarquer Ansible dans un HSE (environnement haute sécurité) par une équipe de sécurité qui avait décliné Chef et Puppet, même en configuration sans maître. Sans agent est un facteur gagnant dans certains cas.

— Woodland Hunter

2

Si vous cassez votre configuration SSH, vous avez en tout cas des problèmes au-delà d'Ansible. C'est une bonne pratique DevOps de tester des choses comme les changements SSH dans divers environnements avant d'arriver en production, et il est également possible de valider la configuration SSH est correcte dans le cadre de l'écriture - le templatemodule Ansible rend cela assez facile.

— RichVel

J'ai entendu des gens dire que l'architecture sans agent d'Ansible la rend plus adaptée à la gestion de routeurs, par exemple, où vous ne pouvez pas installer d'agent Puppet, par exemple. Mais ces appareils sont-ils livrés avec des interprètes Python? Peut-être pas, donc Python est-il vraiment une exigence forte sur chaque composant géré par Ansible?

— Drux

10

Non, les gens qui s'éloignent de Puppet vers Ansible (ou vice versa) n'ont rien à voir avec ce qui peut ou ne peut pas être accompli avec l'un ou l'autre outil. Marionnette / Chef / Ansible - c'est surtout une question de goût.

Par exemple, Ansible est basé sur Python, et les développeurs Python se sentent généralement plus à l'aise avec lui (pas besoin d'apprendre une DSL), ou Ruby (pour Chef)). Il est également plus facile pour les développeurs Python d'étendre Ansible.

Mais en substance, ils sont tous très similaires en termes de ce que vous pouvez réaliser. Certains ont des forces relatives dans certains domaines et des faiblesses dans d'autres, mais généralement le choix entre eux est fait par le style / la culture / les préférences de l'équipe.

— Assaf Lavie
source

8

Jusqu'à Puppet 4.0, il n'y avait pas de moyen facile d' orchestrer les applications réparties sur plusieurs serveurs ou services, car il était difficile de commander spécifiquement des actions dans Puppet, ce qui était un choix de conception . Ansible était meilleur pour orchestrer et ordonner les étapes, en particulier sur plusieurs serveurs. Cela était particulièrement important dans les applications où le mauvais ordre des étapes pouvait conduire à des erreurs irrécupérables en répétant ces étapes jusqu'à ce qu'une cohérence éventuelle puisse être atteinte.

Ce n'est plus un problème et les distinctions sont donc largement basées sur les préférences.

— Jiri Klouda
source

2

Le choix de conception de la marionnette a été l'une des raisons pour lesquelles Chef a commencé, et j'ai principalement déménagé chez Chef pour notre infrastructure et notre système de CD il y a quelques années.

— Tensibai

2

L'orchestration de marionnettes est une fonctionnalité de Puppet Enterprise (commerciale) uniquement, tandis que l'orchestration dans Ansible est dans la version open source. En général, Ansible est beaucoup plus facile à installer et à apprendre que Puppet - après avoir fait une évaluation des deux, j'utilise maintenant Ansible. Il y a aussi d'autres différences, donc ce n'est pas seulement une question de préférence personnelle.

— RichVel

1

J'utilise Ansible à la fois dans mon ancien et actuel emploi, mais il a ses propres problèmes. Plus j'utilise Ansible, plus je suis intéressé à apprendre une autre alternative. Je préfère cette alternative à ne pas utiliser Python pour le développement de modules et à avoir une communauté open source vitale active. Les demandes de retrait pour Ansible prennent presque un an pour être même examinées. À ce rythme, il pourrait être aussi propriétaire.

— Jiri Klouda

1

Beaucoup de gens se plaignent de l'agent de marionnettes, mais lorsque vous êtes sur le cloud et que votre groupe de mise à l'échelle automatique et que vous ne voulez pas reconstruire l'image de votre VM, c'est bien que VM se connecte au maître de marionnettes, je ne vois aucun problème à avoir un petit agent.

— c4f4t0r