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+fr...@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/ > -- Nathan Delhaye 06 69 27 64 25 0805 696 494
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
