Reprise du message précédent :

On l'utilise pour gérer tout notre parc.
Pour nous ça marche très bien.

certains ici ont déjà fait jou-joue avec fabric ?
 
http://www.fabfile.org/
https://www.youtube.com/watch?v=VmcGuKPpWH8
https://www.digitalocean.com/commun [...] eployments
 
je trouve le minimalisme du truc vachement sympa par rapport au grosses usines à gaz où on ne comprends jamais trop bien ce qu'il se passe quand on lance le truc

Bonjour à vous,
 
Vous auriez des bonnes lectures sur saltstack? j'y touche un peu mais c'est histoire de partir sur de bonnes bases.
 
Merci

 
Ta le Walkthrough qui est bien, mais après je sais pas où tu veux aller. C'est pour une grosse infra ?

en premier lieu c'est pour automatiser du déploiement de métrologie

Si ta pas de contraintes de scalabilité ni de rapidité, et sur une petite infra, Ansible pourra aussi t'aller
 
Si ta des besoins plus couillus, l'agent de Salt permet de faire des déploiements à vitesse grand V

on a des compétences en ansible, j'ai quelques compétences en salt et mon chef aimerait développer ce coté la (je fais parti d'une cellule d'intégration, donc plus y a de compétences mieux c'est)

Perso j'en suis resté sur la doc officielle de Salt qui me suffit (mais j'suis ptetre pas allé très loin dans son usage, un peu de pillar et quelques if)

d'accord, donc je vais continuer au moins par la.
 
Merci

ouai quand l'utilise et que c'est pas toi qui l'a développé c'est sur ca marche bien
mdr  

 
on l'utilise comme gestionnaire de configurations, pas plus.
nos modules restent relativement simple et tout se passe bien.
 

 
Pareil. L'idée c'est qu'on sépare la config des données.  
Si je dois faire une migration ou mise à jour importante, j'exporte les données si besoin, je reconfigure une VM depuis zéro et je réimporte.
L'idée, c'est que si un admin se barre, je peux redéployer tout ce qu'il a fait, et pour ça, il faut que les serveurs soient jetables et redéployables à la volée.

Quelqu'un ici a déjà eu la réflexion de partir de Puppet pour aller ailleurs ? Nous sommes de plus en plus en discussion pour remettre en compte ce choix. Les choix sont filtrés par le faite qu'il doit être hébergé chez nous, open-source et gratuit. Pis j'en ai ras le bol du ruby bref
 
Ansible ? Saltstack ? On utilise Puppet pour le déploiement mais surtout pour la normalisation, si ca peut faire du windows aussi je ne serais pas contre ^^

je suis passé de puppet à chef, il y a 6.5 ans

Ben Ansible ou saltstack, vous avez déjà identifié les seules alternatives (Chef étant out puisque tu ne veux plus de Ruby), après à creuser en fonction de vos contraintes.
 
Je ne connais pas vraiment salt, mais si votre but c'est la normalisation, il sera sûrement plus adapté qu'Ansible (que j'utilise beaucoup mais qui est très orienté déploiement de mon point de vue).

question conne: pourquoi les outils de conf management sont en général au format yaml/json/DSL plutôt que directement en python/ruby ?
ça apporte quoi ?

la simplcité et l'accessibilité pour les personnes qu(e) "écrire du code" rebutte/effraie.
 
et c'est aussi une abstraction : si tu veux changer le comportement derriere un provider, tu changes le DSL. Tu as plus de chances de garder ta rétro-compatibilité avec une couche de plus.

honnetement je ne vois pas ce qu'il y a de beaucoup plus compliqué entre ça:

 
et ça:

 
le problème c'est que dès qu'on veut rendre les choses plus complexes il faut utiliser du jinja, ce qui rend vite la recette illisible... alors qu'en python directement ça sera beaucoup plus simple et direct.

 
ce sont des ersatz de conf management ça
 

 
c'est du chef, mais tu as la meme chose avec puppet. là tu as du code, pas une pauvre description dans un yaml. tu peux y coller de la logique, des boucles, etc; tout ça sans rendre le tout illisible (IMO)

ah ok, je suis en train de me rendre compte que salt c'est pas du tout adapté à ce que je fais    
 
j'imagine qu'on a le même problème avec ansible ?  

Tu veux faire quoi en fait ?

gérer simplement différents paramètres sur différents serveurs. C'est tellement l'horreur avec salt que j'utilise des copier/coller de recettes que je modifie à la main... (very bad sligor, sad   )

Gérer des paramètres différents par serveur, c'est quand même un peu la base d'un outil de gestion de conf.
A mon avis tu passes à côté d'un truc avec salt (je ne connais pas mais j'imagine qu'il doit gérer ça).
 
Et sur le pourquoi du YAML/JSON, je dirais aussi pour pouvoir avoir des outils pour (auto-)générer des choses, genre des UI web, ou des scripts. Bien plus simple que de générer du code, puisque YAML/JSON ce n'est que de la sérialisation de types de données très répendus.

 
Tu utilises pas les pillar, les grains etc

Foreman+Puppet

 
J'avoue c'est sympa le dashboard
 
c'est mort ce topic  

Le config management c'est devenu trop mainstream