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/

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)