Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait pas. Est-ce seulement le fait qu'il soit agentless ?
Merci :)
Bonjour,
Salt peut l'être aussi via salt-ssh il me semble.
Le 2016-12-09 15:47, Jonathan Leroy a écrit :
Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait pas. Est-ce seulement le fait qu'il soit agentless ?
Merci :)
Le 09/12/2016 à 15:47, Jonathan Leroy a écrit :
Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ? Parce que : - 0 infrastructure pour commencer => (SSH / DNS + inventaire, le pré-requis est très bas) - Accès ultra-simple => (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes) - Passer d'un shell script à un playbook (salement) : 5 minutes - Industrialiser et comprendre l'idempotence, easy - Se plugger sur un inventaire (cloud ou pas) existant (amazon, openstack, ...) easy.
Et parce que.. ça répond au besoin de mise en conformité en passant par le code, propre d'une mise ne place DevOps, et facilite grandement l'idempotence et l'orchestration à grande échelle.
Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans Tower). Les outils basés sur un agent sont plus faciles à manipuler à plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds.
J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait pas. Est-ce seulement le fait qu'il soit agentless ?
Il est aussi lent que SSH l'est, malgré les optimisations diverses (notamment très ressenties en 2 puis en 2.2). Pour ce qui est du comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la vitesse d'exécution, mais je pense aussi que c'est un critère assez secondaire.
Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas facilement les accès simultanés et la gestion de privilèges, par nature, mais il scale très bien, et les callbacks sont très facile d'accès pour les besoins (ou bien, on achète Tower).
Bref, Ansible, ça rox, ça demande rien, et ça claque.
@+ Gilou
Bonjour, juste pour mettre mon grain de sel , salt est nativement intégré dans les dernières versions de Suse Manager, le pendant Suse de RedHat Satellite (spacewalk).
Le ven. 9 déc. 2016 16:01, Gilou contact+frsag@gilouweb.com a écrit :
Le 09/12/2016 à 15:47, Jonathan Leroy a écrit :
Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ? Parce que :
- 0 infrastructure pour commencer => (SSH / DNS + inventaire, le pré-requis est très bas)
- Accès ultra-simple => (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes)
- Passer d'un shell script à un playbook (salement) : 5 minutes
- Industrialiser et comprendre l'idempotence, easy
- Se plugger sur un inventaire (cloud ou pas) existant (amazon,
openstack, ...) easy.
Et parce que.. ça répond au besoin de mise en conformité en passant par le code, propre d'une mise ne place DevOps, et facilite grandement l'idempotence et l'orchestration à grande échelle.
Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans Tower). Les outils basés sur un agent sont plus faciles à manipuler à plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds.
J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait pas. Est-ce seulement le fait qu'il soit agentless ?
Il est aussi lent que SSH l'est, malgré les optimisations diverses (notamment très ressenties en 2 puis en 2.2). Pour ce qui est du comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la vitesse d'exécution, mais je pense aussi que c'est un critère assez secondaire.
Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas facilement les accès simultanés et la gestion de privilèges, par nature, mais il scale très bien, et les callbacks sont très facile d'accès pour les besoins (ou bien, on achète Tower).
Bref, Ansible, ça rox, ça demande rien, et ça claque.
@+ Gilou
Liste de diffusion du FRsAG http://www.frsag.org/
Le Fri, Dec 09, 2016 at 03:47:56PM +0100, Jonathan Leroy [jonathan@unsigned.inikup.com] a écrit:
Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
Comme Gilou, je dirais qu'une raison du succes d'Ansible, c'est qu'on demarre avec en 5 minutes, il suffit de ssh et python, rien a installer sur la cible. (et c'est la raison pour laquelle j'aime bien Fabric aussi, qui a les memes avantages, de ce point de vue)
Et les mêmes inconvénients, donc, lorsque tu as une architecture système un peu moins simpliste :) (anycast, lb etc, et sans avoir les moyens d'avoir X ip globalement adressable par machine)
On 09/12/2016 16:29, Dominique Rousseau wrote:
Le Fri, Dec 09, 2016 at 03:47:56PM +0100, Jonathan Leroy [jonathan@unsigned.inikup.com] a écrit:
Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
Comme Gilou, je dirais qu'une raison du succes d'Ansible, c'est qu'on demarre avec en 5 minutes, il suffit de ssh et python, rien a installer sur la cible. (et c'est la raison pour laquelle j'aime bien Fabric aussi, qui a les memes avantages, de ce point de vue)
Hello,
De mon côté j'ai remplacé Puppet par Salt il y a un an environs. Le choix s'est fait entre Chef, Puppet, Ansible et Salt lorsque nous avons du refaire notre infra. Puppet et Chef ont été éliminés bien vite parce que je Déteste le ruby (non mais sérieux "(var ||= []) << var" comment on peut trouver ça simple a lire?? )
Le choix final s'est porté sur Salt pour 4 raisons principales a l'époque : - La possibilité de travailler en mode minion/master ET en mode ssh : permet d'avoir une infra complexe et des scripts de bootstrap simples - La mine intégrée, qui remplace très efficacement etcd - Le système de reactor, pratique pour faire du monitoring réactif ou de la coordination de cluster - La scalabilité et rapidité d'éxécution des states.
Concernant la scalabilité/rapidité d'éxécution, je m'explique : lorsque j'ai un grand nombre d'états (users, fichiers, archives, certificats, etc...) sur un serveur, le cache de Salt permet d'accélérer grandement les choses. Sur un test sur un serveur un peu lourd, type Wordpress du marketing/SEO (http://bit.ly/2hdbhxN) avec une pétachiée de vhost, je passe de 2 minutes d'éxécution avec le script ansible à 10-15 secondes avec Salt lorsqu'il y as peu de modif a faire (exemple, créer un nouveau vhost).
Pour moi c'est le cas le plus important a benchmark dans la mesure ou le temp d’exécution lors du setup initial va être sensiblement le même parce que les deux systèmes vont devoir exécuter le package manager, installer des trucs, créer des users, générer des certificats, etc, etc ce qui prend généralement plus de temps que le calcul des diff par le système d'industrialisation.
Cela dit, le ticket d'entrée sur Salt est bien plus élevé que sur Ansible. On se rapproche plus de Chef que de la philosophie Ansible proche du "rsync script.sh server: && ssh server script.sh"
Après un peu de recul, en plus des 4 points qui ont motivé le choix de la techno voila mon avis sur Salt: - Systèmes Modules/States/Formulas/Grains qui sépare bien les différents composants d'un système d'industrialisation absolument jouissif a utiliser. - Modules/States/formules faciles a développer - Possibilité de faire du quick & dirty dans les formules avec du pur Yaml/Json, mais aussi des trucs bien complexes en Python - Les gars de Salt sont réactifs au merge de PR sur leur git
A+
Le 9 décembre 2016 à 15:59, Gilou contact+frsag@gilouweb.com a écrit :
Le 09/12/2016 à 15:47, Jonathan Leroy a écrit :
Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ? Parce que :
- 0 infrastructure pour commencer => (SSH / DNS + inventaire, le pré-requis est très bas)
- Accès ultra-simple => (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes)
- Passer d'un shell script à un playbook (salement) : 5 minutes
- Industrialiser et comprendre l'idempotence, easy
- Se plugger sur un inventaire (cloud ou pas) existant (amazon,
openstack, ...) easy.
Et parce que.. ça répond au besoin de mise en conformité en passant par le code, propre d'une mise ne place DevOps, et facilite grandement l'idempotence et l'orchestration à grande échelle.
Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans Tower). Les outils basés sur un agent sont plus faciles à manipuler à plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds.
J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait pas. Est-ce seulement le fait qu'il soit agentless ?
Il est aussi lent que SSH l'est, malgré les optimisations diverses (notamment très ressenties en 2 puis en 2.2). Pour ce qui est du comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la vitesse d'exécution, mais je pense aussi que c'est un critère assez secondaire.
Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas facilement les accès simultanés et la gestion de privilèges, par nature, mais il scale très bien, et les callbacks sont très facile d'accès pour les besoins (ou bien, on achète Tower).
Bref, Ansible, ça rox, ça demande rien, et ça claque.
@+ Gilou
Liste de diffusion du FRsAG http://www.frsag.org/
Bah, en ce qui me concerne, c'est Ansible que j'ai eu en premier dans les mains. Ensuite, et à l’époque, la concurrence n’était peut être pas aussi mature que ce qu'elle peut être aujourd'hui. D'ailleurs, je me suis laissé entendre dire que certains collègues avaient essayé Salt (alors qu'on était sur du Ansible de la première heure), et qu'ils kiffaient pas mal, mais je pourrais pas en dire plus.
Apres, de ce que je connais d'Ansible, je dirais que c'est pas la solution à tout, et que le couple Puppet + Ansible me parait tout a fait recommandé pour géré une infrastructure hétérogène; oui, parceque dans ma boite, j'ai autant de serveurs que de config :/ D'ailleurs si y'en a qui veulent philosopher sur le fait que Ansible et Puppet sont complémentaire, I'm open. Maintenant si Salt propose la combinaison des deux (en terme de concepts/processus), bah il est tant que j'aille voir Salt :D .
Dernier point, Ansible est désormais RedHat backed maintenant, ça a tendance a faire réfléchir les DSI sur le coté corpo de la chose. Je ne sais pas pour la concurrence qui gère qui.
Sur tes points précis, concernant la vitesse, la réponse de Gilou me semble toute à fait bonne. Pour la partie scaling, alors là, explique moi, car je ne vois pas, j'ai jamais été bloqué sur ce point (en même temps, je déploie rarement de 10K nodes, j'ai tendance à préférer Puppet pour cette job la).
-- MrJK GPG: https://jeznet.org/jez.asc
Le 9 décembre 2016 à 09:47, Jonathan Leroy jonathan@unsigned.inikup.com a écrit :
Salut à tous,
J'ai l'impression ces derniers temps qu'il y a de plus en plus d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu partout sur l'Internet. Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait pas. Est-ce seulement le fait qu'il soit agentless ?
Merci :)
-- Jonathan Leroy. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
boris.tassou＠securmail.fr -
Dominique Rousseau -
frsag＠jack.fr.eu.org -
Gilou -
Jonathan Leroy -
Mrjk -
Nathan delhaye -
Olivier Duquesne (DaffyDuke)