En général, le premier argument, ça va être les compétences et les affinités. Si tu as des gens dans ton équipe qui sont familier avec un outil, alors il vaut mieux le prendre.
Sinon, j'ai fait du puppet (beaucoup, mais y a longtemps), je fait beaucoup d'ansible et en ce moment, pas mal de salt, donc j'ai un avis forcément éclairé et valide sur le sujet (non pas que ça change grand chose, je l'aurais donné même si non fondé bien sur, on est sur l'internet).
Déja, ça depend de ce que tu as comme besoin. Puppet ne fait que de la gestion de configuration, donc si tu doit déployer ou orchester des choses, il te faut un deuxième outil (mcollective, func, fabric, ansible, saltstack, etc). Ansible par contre à la base fait du déploiement et de l'orchestration, et ça a été étendu à la gestion de configuration, et ça change tout.
Ça change tout parce que Ansible, étant sans agent, est plus ou moins obligé de faire des aller/retours sans arrêt et ça reste assez lent. Pour un projet, on a une infra de 10 machines, ça mets 10 à 15 minutes à tout appliquer à chaque commit git sur le dépôt. À coté de ça, Puppet était pas super rapide dans mon souvenir à cause de ruby ( notamment les allocations d'objets ) , mais c'était une infra plus compliqué, et au final, c'était quand même bien plus acceptable.
Du point de vue des fonctions, Puppet est bien plus mature et son DSL propose vraiment plus de choses, la ou Ansible pêche un peu ( le fait de pas avoir de fonction, par exemple, même si un équivalent va revenir avec la version 2 du moteur, via le fait d'avoir des includes dynamiques ). Puppet a un ecosystéme plus riche qu'ansible ( genre foreman, r10k, etc ), plus de modules et plus de gens qui connaissent. Et forcément, il y a aussi des bonnes pratiques à tort et à travers, des patterns, etc.
Puppet est plus complexe à installer, pas forcément à apprendre. Tu es pas obligé de tout connaitre, tout comme dans ansible, tu as pas forcément besoin de connaitre tout les modules.
Mais c'est vrai qu'avec ansible, tu arrives plus rapidement à obtenir un résultat utile, et l'outil est plus versatile.
Donc pour un usage perso, je pense qu'ansible fait l'affaire.
Pour une infra plus conséquente, je regarderais peut être plus du coté de puppet ou saltstack pour le moment.
De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.
[^] # Re: Ansible / Puppet
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 10.
En général, le premier argument, ça va être les compétences et les affinités. Si tu as des gens dans ton équipe qui sont familier avec un outil, alors il vaut mieux le prendre.
Sinon, j'ai fait du puppet (beaucoup, mais y a longtemps), je fait beaucoup d'ansible et en ce moment, pas mal de salt, donc j'ai un avis forcément éclairé et valide sur le sujet (non pas que ça change grand chose, je l'aurais donné même si non fondé bien sur, on est sur l'internet).
Déja, ça depend de ce que tu as comme besoin. Puppet ne fait que de la gestion de configuration, donc si tu doit déployer ou orchester des choses, il te faut un deuxième outil (mcollective, func, fabric, ansible, saltstack, etc). Ansible par contre à la base fait du déploiement et de l'orchestration, et ça a été étendu à la gestion de configuration, et ça change tout.
Ça change tout parce que Ansible, étant sans agent, est plus ou moins obligé de faire des aller/retours sans arrêt et ça reste assez lent. Pour un projet, on a une infra de 10 machines, ça mets 10 à 15 minutes à tout appliquer à chaque commit git sur le dépôt. À coté de ça, Puppet était pas super rapide dans mon souvenir à cause de ruby ( notamment les allocations d'objets ) , mais c'était une infra plus compliqué, et au final, c'était quand même bien plus acceptable.
Du point de vue des fonctions, Puppet est bien plus mature et son DSL propose vraiment plus de choses, la ou Ansible pêche un peu ( le fait de pas avoir de fonction, par exemple, même si un équivalent va revenir avec la version 2 du moteur, via le fait d'avoir des includes dynamiques ). Puppet a un ecosystéme plus riche qu'ansible ( genre foreman, r10k, etc ), plus de modules et plus de gens qui connaissent. Et forcément, il y a aussi des bonnes pratiques à tort et à travers, des patterns, etc.
Puppet est plus complexe à installer, pas forcément à apprendre. Tu es pas obligé de tout connaitre, tout comme dans ansible, tu as pas forcément besoin de connaitre tout les modules.
Mais c'est vrai qu'avec ansible, tu arrives plus rapidement à obtenir un résultat utile, et l'outil est plus versatile.
Donc pour un usage perso, je pense qu'ansible fait l'affaire.
Pour une infra plus conséquente, je regarderais peut être plus du coté de puppet ou saltstack pour le moment.
De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.