Merci pour la trouvaille, reste à voir en prod, mais cela me semble mieux que Puppet... Le 25 juin 2012 10:58, Ludovic Cartier <cartier.ludovic@gmail.com> a écrit :

Hello,

La même ici :-) Puppet me rebute un peu, et Ansible est la meilleure alterntive que j'ai trouvé pour le moment.

Je vais le tester sur mes plate-formes de prod dans peu de temps, je vous ferais un retour :-)

Le 25 juin 2012 10:52, JF Bustarret <jf@bustarret.com> a écrit :

Tout pareil que toi...

...

J'ai découvert ansible il y a quelques semaines, ça m'a interpelé... Mais c'est toujours sur ma todo !

JFB

Le 25 juin 2012 à 10:46, Gregory Duchatelet a écrit :

...

Bonjour,

on vient de me faire découvrir Ansible (http://ansible.github.com/), encore un outil pour manager des fermes de serveurs. Jusqu'à présent je n'avais pas trouvé Puppet, Chef et compagnie, comme étant des outils me permettant de gagner du temps. Trop long à configurer, trop pénible à maintenir, notamment avec les versions de Ruby différentes ... bref pas assez fiable dans un environnement un minima hétérogène.

Ansible est en Python mais uniquement coté client, tout le reste se fait via SSH.

Je vais le mettre à l'essai sur mon archi, en remplacement de mon script shell maison, mais je suis très étonné de voir si peu d'infos sur ce programme, qu'il ne soit toujours pas dans les dépôts Debian, donc si vous avez des retours sur Ansible ça m'intéresse !

-- Greg

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

-- Ludovic Cartier

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Merci pour ces trouvailles messieurs. Utilisateur de puppet, je suis satisfait par ce qu'il nous offre mais je dois admettre qu'une longue configuration a précédé ce stade et me demandais, à part Chef, ce qu'il pouvait y'avoir d'autre. Je serais super intéressé par vos retours et tenterais de les tester également de mon côté si je parviens à plier la variable qui nous pose à tous défaut :D le temps... -- Laurent Tupin

On me souffle que dans le genre, il y a aussi "cdist" qui soit intéressant :

http://www.nico.schottelius.org/software/cdist/

Avis aux amateurs :)

Le 25 juin 2012 11:03, Sébastien Mureau <sebastien.mureau@gmail.com> a écrit :

...

Merci pour la trouvaille, reste à voir en prod, mais cela me semble mieux que Puppet...

Le 25 juin 2012 10:58, Ludovic Cartier <cartier.ludovic@gmail.com> a écrit :

Hello,

...

La même ici :-) Puppet me rebute un peu, et Ansible est la meilleure alterntive que j'ai trouvé pour le moment.

Je vais le tester sur mes plate-formes de prod dans peu de temps, je vous ferais un retour :-)

Le 25 juin 2012 10:52, JF Bustarret <jf@bustarret.com> a écrit :

Tout pareil que toi...

...

J'ai découvert ansible il y a quelques semaines, ça m'a interpelé... Mais c'est toujours sur ma todo !

JFB

Le 25 juin 2012 à 10:46, Gregory Duchatelet a écrit :

...

Bonjour,

on vient de me faire découvrir Ansible (http://ansible.github.com/), encore un outil pour manager des fermes de serveurs. Jusqu'à présent je n'avais pas trouvé Puppet, Chef et compagnie, comme étant des outils me permettant de gagner du temps. Trop long à configurer, trop pénible à maintenir, notamment avec les versions de Ruby différentes ... bref pas assez fiable dans un environnement un minima hétérogène.

Ansible est en Python mais uniquement coté client, tout le reste se fait via SSH.

Je vais le mettre à l'essai sur mon archi, en remplacement de mon script shell maison, mais je suis très étonné de voir si peu d'infos sur ce programme, qu'il ne soit toujours pas dans les dépôts Debian, donc si vous avez des retours sur Ansible ça m'intéresse !

-- Greg

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

-- Ludovic Cartier

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

-- Ludovic Cartier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Le 25/06/2012 23:44, Marc Fournier a écrit :

Sans vouloir faire le troll, dès le 2e paragraphe du "getting started" d'Ansible, on apprend déjà à installer une version plus moderne de python sur RHEL/CentOS 5. Puppet tourne out of the box aussi bien sur la version de ruby livrée avec RHEL/CentOS 4 (!) que celle d'Ubuntu 12.04 ;-) Bref, où je voulais réagir, c'est que: - le gain de temps avec puppet et cie n'est peut-être pas immédiat, mais lorsqu'on a passé le cap, le gain est énorme. Passé l'étape d'installation initiale, je parie qu'on observera aussi ce symptôme sous Ansible - puppet génère un graph dans lequel on peut à loisir injecter/retirer des branches et noeuds. C'est à ma connaissance le seul de ces systèmes qui permet de faire cela. Cette particularité permet une réutilisabilité et factorisation du code optimale, ce qui est justement critique pour un environnement hétérogène ! De toute façon, peu importe l'outil. C'est bien qu'il y en ait pour tous les goûts. L'essentiel AMHA c'est d'avoir des systèmes reconstructibles par du code versionné et réutilisable. À+, Marc

Le souci de Puppet/Chef c'est de faire des modèles qui collent à ce que l'on a en prod. On a beau avoir de super doc d'installation (chez moi on peut faire du copier coller des commandes ou les mettre dans un script et ça installe et configure tout) le soucis c'est qu'il faut les mettre à jour lors des évolutions des services ou de l'os. J'ai tenté de faire tout ce qu'il faut pour Puppet et quand j'ai fini pour avoir juste le déploiement d'une machine avec tout ce qu'il faut de configuré, changement sur plusieurs logiciels et obligé de me remettre sur la conf des modèles, pas du tout un gain de temps. Et encore j'ai la chance de travailler uniquement sur des Debian j'imagine pas du tout devoir maintenir plusieurs distros sans une sacrée équipe derrière. La seule boite qui utilise cela dans mes connaissances, ils sont 2 sysadm pour gérer plusieurs milliers de vm qui ont strictement les mêmes modèles. Ma conclusion c'est que ce n'est pas assez souple pour de l'exploitation quotidienne dans un parc hétérogène. Au passage Greg merci pour cette découverte je vais tester rapidement.

Le 26/06/2012 10:38, Marc Fournier a écrit :

Copier-coller des commandes c'est un job manuel et répétitif, donc risque d'erreurs d'inattention. Quand au script, que se passe-t-il lorsque il se plante au milieu du run et que le système reste à moitié configuré ? Et ne faut-il pas le mettre à jour pour suivre les évolutions de l'OS également ? C'est exactement pour résoudre cette problématique que Puppet, Chef ou Ansible ont été conçus...

Si bien sur des mises à jours de scripts il y en a mais c'est à mon sens bien plus rapide à mettre à jour. Enfin pour tester mes scripts, je redéploie des vms jusqu'à ce que ça passe sans accrocs.

C'est un peu comme de dire « j'ai fait un script en perl, mais mon code avait plein de bugs. J'en conclus que le perl c'est nul. Au passage, merci de m'avoir montré python, ça va sans doute résoudre tous les problèmes que j'avais avec perl » :-)

Ce que je veux dire, c'est que les problèmes que tu as eu ne sont pas propres à puppet, et tu tomberas probablement sur les mêmes problèmes sous Chef ou Ansible.

Quelle que soit la solution utilisée, le "problème" que tu décris se résout en (ré)apprenant à organiser le code de façon modulaire, évolutive, réutilisable, etc. C'est pas facile, c'est quelque chose qu'on n'est pas habitués à faire en tant que sysadmins. À mon avis, ça vaut vraiment la peine de demander de l'aide à un collègue développeur et de s'inspirer de la quantité de doc qu'on peut trouver à ce sujet sur le web. Je pense que la modularité a été mon problème, pas que je ne sache pas la mettre en place mais au contraire qu'étant aussi développeur j'ai fait beaucoup de couches différentes pour gérer des éléments simples. Dans mes tests de Puppet, j'imaginais vraiment pouvoir gérer du Linux et BSD peu importe la distro, je n'aurais sans doute pas du le faire dès le début.

Autre élément qui m'a rebuté sur Puppet et qui est résolu avec Ansible que je vais tester, pas de daemon qui tourne sur la machine. Autant je ne suis pas contre, j'utilise des daemons nrpe sans soucis, autant le client Puppet était vraiment trop lourd en mémoire (Python effect). Or J'ai certaines vm qui n'ont pas besoin de plus de 128Mo de ram, leur ajouter Puppet les faisaient swaper, alors que l'ajout de nrpe et d'un dameon perso en C n'a pas posé de souci.

À+, Marc (qui gère avec satisfaction plusieurs parcs hétérogène grâce à puppet) Je pense qu'il faudrait que je vois une organisation de Puppet sur de l'hétérogène pour comprendre la manière de l'aborder. L'ayant vu que sur des modèles similaires de machines web et sql, rien n'avait été fait pour la modularité.

On 26/06/2012 20:10, Florian Maury wrote:

Le 26 juin 2012 à 11:28, Wallace a écrit :

...

Autre élément qui m'a rebuté sur Puppet et qui est résolu avec Ansible que je vais tester, pas de daemon qui tourne sur la machine. Autant je ne suis pas contre, j'utilise des daemons nrpe sans soucis, autant le client Puppet était vraiment trop lourd en mémoire (Python effect). Or J'ai certaines vm qui n'ont pas besoin de plus de 128Mo de ram, leur ajouter Puppet les faisaient swaper, alors que l'ajout de nrpe et d'un dameon perso en C n'a pas posé de souci.

Bonjour, Je suis étonné de ne pas avoir lu le moindre email sur cfengine. Les prérequis exprimés dans l''email auquel je réponds m'y font particulièrement pensé. Je ne l'ai pas mis en place, faute de changement de carrière : je ne pourrais donc fournir de retour d'expérience. Cependant, lorsque j'avais regardé les différentes solutions, j'avais été rebuté par Puppets pour son coté trop... développeur (je déteste l'idée d'intégrer du code (qui plus est ruby, non standard dans les distribs que j'utilise, au contraire de perl et python) à droite à gauche de cette manière) et j'avais été assez charmé par l'aspect "lightweight" de cfengine, sans compter sa security track plutôt bonne (malgré qu'il soit écrit en C (troll free)). Bref, c'était probablement la solution vers laquelle je me serai orienté.

Qqn a des retours ou des commentaires ?

Florian Maury _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Bonsoir, parmi les autres alternatives il y a Bcfg2, en python, qui utilise essentiellement une configuration XML. C'est cet aspect très "descriptif" qui m'a séduit, avec le petit bonus de pouvoir facilement l'interfacer avec d'autres outils plus tard. Pas de démon sur les machines, il faut lancer (via SSH) le client "bcfg2" sur les machines pour appliquer les modifications. Olivier

Je réponds pour la partie Puppet, que j'ai pas mal utilisé en prod il y a un an. Je ne réagirai pas sur l'argument "ansible n'est pas un outil de gestion de conf", ce qui pourrait aiguiller le thread vers du troll alors qu'on n'est pas vendredi, d'autant que sur le fond, je suis assez d'accord : ansible ne répond pas au même besoin. Le 28 juin 2012 à 09:01, Nicolas Charles a écrit :

Par contre, gérer à distance, c'est impossible quand la machine n'est plus accessible (par exemple une attaque qui coupe le reseau entre le serveur Ansible et la machine cible), c'est pas très scalable, et si le serveur qui gère est mort, tout s'arrête (enfin, rien de peut être changé manuellement)

Le problème se pose à chaque fois il y a un repository central avec toute la conf... Si le repository n'est pas accessible il ne se passe plus grand chose. Côté scalabilité, Puppet n'est pas non plus idéal : avec pas mal de machines et une grosse config, une install "out-of-the-box" dont le client tourne automatiquement et régulièrement part facilement à l'ouest et ça demande un peu de boulot pour lui faire tenir la charge (NB : ça a pu changer dans les dernières versions). Le client a aussi un bel impact sur la machine sur lequel is se trouve. J'en connais plusieurs qui lancent le client puppet en SSH lors d'un changement de config, avec un fonctionnement qui se rapproche finalement d'ansible.

Les outils CFEngine/Chef/Puppet ont une version locale des promesses/recettes/manifests qui les rend résilient à une panne réseau; et c'est en fonction de ces règles qu'ils décideront d'aller parler à un serveur ou non (avec peut être plusieurs serveurs différents), et avec ca on peut commencer à être scalable.

Je ne vois pas l'intérêt : si le client a la config en local, c'est que logiquement elle est déjà appliquée. Si le client n'a pas accès au serveur, il ne peut plus appliquer les changements de config ou initier une nouvelle config dans le cas d'un déploiement... JFB Frustré par puppet, et n'ayant pas envie de se lancer dans chef/cfengine

On 28/06/2012 09:36, JF Bustarret wrote:

Je réponds pour la partie Puppet, que j'ai pas mal utilisé en prod il y a un an.

Je ne réagirai pas sur l'argument "ansible n'est pas un outil de gestion de conf", ce qui pourrait aiguiller le thread vers du troll alors qu'on n'est pas vendredi, d'autant que sur le fond, je suis assez d'accord : ansible ne répond pas au même besoin.

Le 28 juin 2012 à 09:01, Nicolas Charles a écrit :

...

Par contre, gérer à distance, c'est impossible quand la machine n'est plus accessible (par exemple une attaque qui coupe le reseau entre le serveur Ansible et la machine cible), c'est pas très scalable, et si le serveur qui gère est mort, tout s'arrête (enfin, rien de peut être changé manuellement) Le problème se pose à chaque fois il y a un repository central avec toute la conf... Si le repository n'est pas accessible il ne se passe plus grand chose.

Si, il se passe toujours la même chose (et c'est déjà bien). Par exemple, verifier qu'il n'y a pas de nouveaux utilisateurs créés sur la machine et les supprimer le cas échéant. Corriger le contenu du fichier hosts ou des dns, pour reparer une erreur utilisateur possible qui aurait rendu la machine inutilisable sur le reseau. Il y a encore pleins d'autres exemples !

Côté scalabilité, Puppet n'est pas non plus idéal : avec pas mal de machines et une grosse config, une install "out-of-the-box" dont le client tourne automatiquement et régulièrement part facilement à l'ouest et ça demande un peu de boulot pour lui faire tenir la charge (NB : ça a pu changer dans les dernières versions). Le client a aussi un bel impact sur la machine sur lequel is se trouve.

J'en connais plusieurs qui lancent le client puppet en SSH lors d'un changement de config, avec un fonctionnement qui se rapproche finalement d'ansible.

Je suis d'accord avec ces points (et c'est principalement pour ca que j'utilise CFEngine)

...

Les outils CFEngine/Chef/Puppet ont une version locale des promesses/recettes/manifests qui les rend résilient à une panne réseau; et c'est en fonction de ces règles qu'ils décideront d'aller parler à un serveur ou non (avec peut être plusieurs serveurs différents), et avec ca on peut commencer à être scalable. Je ne vois pas l'intérêt : si le client a la config en local, c'est que logiquement elle est déjà appliquée. Si le client n'a pas accès au serveur, il ne peut plus appliquer les changements de config ou initier une nouvelle config dans le cas d'un déploiement...

Il n'y a pas forcement de changement de config à faire, mais une correction ! Un exemple : - je veux avoir la dernière version d'apache2 installé (c'est un exemple un peu stupide). La règle est simple, et elle n'a pas besoin de changer, juste le repository avec les paquets apache2 - je veux être sur qu'apache2 tourne. La règle est simple : si il est arreté, l'agent le redemarre. Pareil, pas besoin de changer des règles ni d'action humaine

JFB Frustré par puppet, et n'ayant pas envie de se lancer dans chef/cfengine

C'est dommage, surtout qu'il existe des outils ou surcouches pour faciler les choses... Nicolas

Bonjour, Un autre outil du même style que Ansible et codé en Python est Fabric (http://docs.fabfile.org/en/1.4.2/index.html) Un article est paru dans 'GNU/Linux Magazine France' et disponibles librement (http://www.unixgarden.com/index.php/gnu-linux-magazine/fabric-administration...) Cdt, Le 28 juin 2012 22:24, Marc Fournier <marc.fournier@camptocamp.com> a écrit :

Excerpts from Nicolas Charles's message of Thu Jun 28 12:02:31 +0200 2012:

...

...

...

Les outils CFEngine/Chef/Puppet ont une version locale des promesses/recettes/manifests qui les rend résilient à une panne réseau; et c'est en fonction de ces règles qu'ils décideront d'aller parler à un serveur ou non (avec peut être plusieurs serveurs différents), et avec ca on peut commencer à être scalable. Je ne vois pas l'intérêt : si le client a la config en local, c'est que logiquement elle est déjà appliquée. Si le client n'a pas accès au serveur, il ne peut plus appliquer les changements de config ou initier une nouvelle config dans le cas d'un déploiement...

Il n'y a pas forcement de changement de config à faire, mais une correction ! Un exemple : - je veux avoir la dernière version d'apache2 installé (c'est un exemple un peu stupide). La règle est simple, et elle n'a pas besoin de changer, juste le repository avec les paquets apache2 - je veux être sur qu'apache2 tourne. La règle est simple : si il est arreté, l'agent le redemarre. Pareil, pas besoin de changer des règles ni d'action humaine

J'évite pour ma part d'utiliser puppet pour les exemples que tu cites. Il y a des outils plus adaptés qui existent pour cela.

Je vois plutôt cela comme une sorte de cache: dans le cas de puppet, si la config réseau est cassée et que le client ne peut plus accéder au serveur pour récupérer sa config, il va appliquer la version locale de sa config, ce qui (avec un peu de chance) va corriger le problème réseau. Idem, si le master est en rade et que quelqu'un modifie une config importante à la main, puppet utilisera la version en cache pour remettre le système en ordre.

À+, Marc _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

-- Matthieu MONNIER @: monnier.matthieu@gmail.com O< ascii ribbon campaign - stop html mail - www.asciiribbon.org