Juste je confirme pour les PR dans salt, ayant vu mes codes acceptes puis apparaitre dans la version en dev puis dans la derniere release 2016.11 8-). il est d ailleurs regrettable qu il n y en ai pas plus finalement :)

-------- Message d'origine -------- De : Nathan delhaye contact@nathan-delhaye.fr Date : 09/12/2016 17:32 (GMT+01:00) À : Gilou contact+frsag@gilouweb.com Cc : French SysAdmin Group frsag@frsag.org Objet : Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

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/