Quelles sont les limites de Puppet par rapport à Ansible?

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?

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.

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.

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.