Bravo pour votre projet. Monkeyble est sûrement tout à fait utile pour améliorer les playbook, mais ça ne me semble pas suffisant.
les ressources Ansible sont des "modèles d'états souhaités"
Perso ce qui m'a éloigné de Ansible c'est justement que cette phrase est fausse ! Rare sont les modules Ansible vraiment écrits comme ça.
(attention, mon expérience date un peu, si des choses ont changé c'est super)
Un des manques criant, par exemple, est le nettoyage des tâches supprimées (si j'enlève une tâche qui ajoute une ligne dans un fichier de conf, cette ligne restera là où elle a été mise), il faudrait plutôt que Ansible gère un état on/off.
Pour assurer sa maxime, Ansible devrait drastiquement limiter les modules à ceux capable de gérer ces cas là, mais ce n'est pas vrai de la plupart des modules de base même...
J'ai beaucoup souffert à déverminer des playbook qui avait fait l'objet de maintenance, qui pouvait run sur la machine de prod, mais était incapable de ré-installer une machine à partir de zéro... ou le contraire !
Bref perso je suis bien plus content de l'approche Docker pour le moment: rebâtir tout de zéro à chaque fois, sans arrêt ! (mais oui, ok, Docker ne va pas faire l'install du système sosu jacent, donc il faut un truc, mais je le limite au maximum)
Si je devais faire du déploiement automatisé je chercherais autre chose que Ansible, peut être pyinfra pour éviter le cauchemar des yaml imbriqués les uns dans les autres (et qui s'appellent tous "main.yml" ;-) ).
# Intéressant mais est-ce suffisant ?
Posté par Alex G. . En réponse à la dépêche Présentation de Monkeyble: Framework de test bout en bout pour Ansible. Évalué à 3.
Bravo pour votre projet. Monkeyble est sûrement tout à fait utile pour améliorer les playbook, mais ça ne me semble pas suffisant.
Perso ce qui m'a éloigné de Ansible c'est justement que cette phrase est fausse ! Rare sont les modules Ansible vraiment écrits comme ça.
(attention, mon expérience date un peu, si des choses ont changé c'est super)
Un des manques criant, par exemple, est le nettoyage des tâches supprimées (si j'enlève une tâche qui ajoute une ligne dans un fichier de conf, cette ligne restera là où elle a été mise), il faudrait plutôt que Ansible gère un état on/off.
Pour assurer sa maxime, Ansible devrait drastiquement limiter les modules à ceux capable de gérer ces cas là, mais ce n'est pas vrai de la plupart des modules de base même...
J'ai beaucoup souffert à déverminer des playbook qui avait fait l'objet de maintenance, qui pouvait run sur la machine de prod, mais était incapable de ré-installer une machine à partir de zéro... ou le contraire !
Bref perso je suis bien plus content de l'approche Docker pour le moment: rebâtir tout de zéro à chaque fois, sans arrêt ! (mais oui, ok, Docker ne va pas faire l'install du système sosu jacent, donc il faut un truc, mais je le limite au maximum)
Si je devais faire du déploiement automatisé je chercherais autre chose que Ansible, peut être pyinfra pour éviter le cauchemar des yaml imbriqués les uns dans les autres (et qui s'appellent tous "main.yml" ;-) ).