Ansible : Voyage au bout de la nuit

J’ai fait un gros crackage avec l’article précédent. Le sujet n’était d’ailleurs pas Ansible mais le nécessaire recul que doit avoir toute personne travaillant dans l’informatique pour « sentir » le prochain virage que prendra l’IT.

J’ai eu tout de même l’intelligence de ne pas placer ce billet dans la série Ansible for the win car il n’avait rien à y faire. Le présent article est dans la série Ansible for the win, j’ai donc la prétention de vous en apprendre un peu plus sur Ansible.

Mais d’abord je vais rendre hommage à quelqu’un : Cabernet138. Cabernet138 est un casse-couille fini. Cabernet, c’est quelqu’un que j’apprécie, vraiment. C’est un casse-couille et c’est la définition qu’utilisera la majorité pour le caractériser (et moi-même). C’est un Don Quichotte des temps modernes qui pourfend les erreurs, mensonges, contre-vérités. Le genre de personnes qui vient vous pourrir et qui ne vous lâche plus. Le genre de personnes dont il faut s’entourer car il ne vous fera pas de cadeaux, pas de pitié, pas de repos. C’est un gros travail d’assumer un mec comme ça, beaucoup de patience, beaucoup de travail mais à la fin il vous poussera à dire toute la vérité, à aller au bout de votre réflexion. Il vous rendra meilleur parce qu’il vous aura pousser dans vos derniers retranchements sans aucune concession. Si vous ne craquez pas avant. C’est la limite. La limite de son fonctionnement c’est notre propre patience, notre propre travail sur soi. Ça ne l’empêche pas d’avoir tort, ça ne l’empêche pas d’être de mauvaise foi mais il force à être honnête, il force à être dans le vrai.


J’ai passé 3 jours complets sur Ansible, entre 20 et 25h, c’est énorme, gigantesque. Je suis convaincu par ce nouvel usage l’automatisation, la gestion de configuration. Il se trouve que l’outil qui me convient (selon mes goûts et mes besoins) c’est Ansible. Alors j’ai affronté mon moulin, mes contradictions. Je me suis planté bien droit devant la montagne pour savoir si oui ou non, Ansible était digne d’être dans ma trousse à outils. Oui, il l’est. Partons maintenant au bout de la nuit.

J’ai trouvé un prétexte qui en est un sans en être un. J’ai décidé d’écrire un playbook de l’installation d’un DokuWiki. En soi, ça ne sert pas à grand-chose. Cependant, pour moi, la documentation c’est sacré et DokuWiki est l’outil principal de documentation au sein de mon entreprise. Et puis l’installation d’un DokuWiki, c’est une étape. La ligne d’arrivée, c’est à partir de ce premier playbook, arriver à la restauration d’un DokuWiki par Ansible. Qui dit restauration, dit tests possibles sur la prod et là on arrive à l’intérêt principal d’un outil comme Ansible, l’automatisation, la gestion de configuration. Réessayer à l’infini, des logiciels différents, des réglages différents. Là c’est plus sexy.

Voici ce que j’ai appris sur les bonnes et les mauvaises choses d’Ansible, croyez moi vous allez apprendre et comprendre des trucs si vous prenez le temps…


1) Le DokuWiki en prod actuellement est sur Apache avec les dépôts Dotdeb activés. Je suis parti sur Nginx pour mon playbook pour me mettre en danger, tester. J’ai appris que VirtualHost c’était un terme Apache. Pour Nginx, il faut dire Server Blocks. Étant donné que même dans leur documentation, ils utilisent le mot VirtualHost, je l’utiliserai aussi hi, hi, hi. Mais je trouve intéressant que vous le sachiez car jamais entendu parlé de ce terme.

2) notify (les handlers) sont probablement ce qui m’a fait le plus perdre mon temps. Ce sont des faux amis et pour moi (je parle donc en mon nom unique), c’est de la merde. Ce qu’il faut en retenir (source) :
a) Regardless of how many things notify a handler, it will run only once, after all of the tasks complete in a particular play
b) Handlers are best used to restart services and trigger reboots. You probably won’t need them for much else

Rendons à César ce qui est à César, j’ai sollicité et posé des questions à Deimos que je remercie particulièrement pour m’avoir fait cogiter et comprendre des trucs. Je me suis notamment basé sur son playbook Dotdeb sur lequel j’ai trouvé des erreurs et des incohérences que je lui ai remonté. Il voulait absolument un handler pour lancer le apt-get update. Ça n’a jamais voulu fonctionner dans mon playbook, ça ne fonctionnera jamais comme dit dans la doc, ça ne s’exécute qu’une seule fois et à la fin du playbook (voir point a). J’ai d’ailleurs vu des exemples sur le net mettant un notify derrière chaque task ou presque, ça ne sert à rien car peu importe le nombre de fois où vous l’appelez ça ne s’exécutera qu’une seule fois.

3) C’est noté noir sur blanc dans la documentation sur les bonnes pratiques, écrivez vos playbooks comme vous le voulez mais avec des rôles ainsi ce sera réutilisable via d’autres playbooks. Et faites simple.

4) On peut mettre des variables dans le nom des tasks (c’est-à-dire un truc comme name: Create {{ vhost_name }} vhost) mais ça ne fonctionne pas tout le temps. Le meilleur lien que j’ai trouvé comme explication : http://grokbase.com/t/gg/ansible-project/149g4mkqnk/having-variables-in-task-names. Je ne suis cependant pas d’accord avec ce qui est dit, d’après mes tests il n’y a que le role invocation qui fonctionne.

5) C’est sur le rôle dotdeb que j’ai perdu le plus de temps notamment à cause de notify mais également à cause de success et changed. Il y a 4 états principaux sur le when : success, changed, skipped, failed (source)

6) Sur le rôle nginx, quelle est la différence entre state=latest et state=present ? C’est simple à comprendre mais il faut un exemple.
a) On renseigne state=present dans la task Install Nginx (roles/nginx/tasks/main.yml) et dotdeb_repo: False dans install_dokuwiki.yml. On lance le playbook. Sans les dépôts Dotdeb vous allez avoir Nginx en version 1.2.1. Maintenant vous faites dotdeb_repo: True dans install_dokuwiki.yml puis vous relancez le playbook. Nginx est toujours en version 1.2.1, normal le paquet doit juste être présent (state=present)
b) On renseigne state=latest dans la task Install Nginx (roles/nginx/tasks/main.yml),et dotdeb_repo: False dans install_dokuwiki.yml. On lance le playbook. Sans les dépôts Dotdeb vous allez avoir Nginx en version 1.2.1. Maintenant vous faites dotdeb_repo: True dans install_dokuwiki.yml puis vous relancez le playbook. Nginx passe alors en version 1.6.1, la dernière version (latest) de Nginx.

7) Une erreur qui est revenue souvent et j’ai cru avoir atteint un problème sur Ansible concerne le rôle dotdeb. Insultes en rouge de Ansible car pas possible de faire un apt: update_cache=yes (un apt-get update quoi). Travaillant avec une VM de tests que je rebootais à chaque fois, je me suis rendu compte qu’elle lançait un apt-get update toute seule quelques minutes après démarrage. La VM verrouillait donc le update car elle était déjà en train d’en faire un.

ansible_001

8) Par rapport au point précédent et ne comprenant pas ce qui se passait, j’ai cherché et trouvé une méthode pour savoir quand était fait le dernier apt-get update sur une Debian et bien il semble qu’il n’y ait pas de commande pour cela. La seule réponse fiable et fonctionnelle c’est de regarder avec ls la date de modification du fichier /var/cache/apt/pkgcache.bin (source). Si quelqu’un a mieux je suis preneur, j’ai trouvé d’autres pistes mais toutes fausses.

9) Une grande satisfaction intellectuelle pour moi a été ce lien.
Avant je faisais ça.

Maintenant je fais ça.

10) Grâce à Deimos, j’ai compris qu’on pouvait écrire when: dotdeb_repo qui est la même chose que when: dotdeb_repo == True

11) Je ne suis pas arrivé à prendre Ansible une seule fois en défaut. Les fois où il m’insultait étaient des erreurs de mon fait : variables oubliées ou avec une faute, rôles avec des erreurs etc. De mon point de vue, c’est un logiciel parfaitement stable et robuste. Le plus gros point noir pour moi, ce sont les résultats d’un playbook avec -v (verbose) et -vvv (more verbose) :
– Ça aide très peu à trouver son erreur
– C’est très illisible et peu compréhensible
– Spéciale dédicace au -vvv police bleue foncée sur fond noir, on ne voit rien !

Vous avez dit incompréhensible ?

ansible_002

ansible_003

Mon Bilan :
– Que l’on se comprenne bien, je n’ai pas mis plus de 20h à pondre ce playbook et ces rôles, j’ai mis 20h à tester dans tous les sens Ansible : rôles, tasks, vars, messages d’erreur, améliorations, limites, tests. Pour faire simple, je suis rentré dans l’outil, je l’ai mis à l’épreuve
– Mon chef m’invite souvent à faire des labos c’est-à-dire à tester une idée, un proof of concept en montant un pc ou quelques VM. C’est ce que j’ai fait ici, je vous invite à faire de même, il n’y a qu’en testant qu’on peut confronter son idée à la réalité. Je peux dire maintenant de manière sûre et publique que Ansible fait dorénavant partie de ma trousse à outils
– La veille informatique c’est bien mais si on ne s’arrête pas 20 mn pour tester ou participer, on n’en retire pas grand-chose
– Le seul vrai point noir qui est très important de mon point de vue, c’est que le debug (-v et -vvv) est particulièrement mauvais, illisible, peu compréhensible
– S’enfoncer dans un projet ou une idée, ça permet aussi de se remettre en cause et de faire des recherches qu’on aurait pas entreprises autrement, de découvrir de nouvelles choses. J’ai découvert les Server Blocks, ma nouvelle commande tar, la date du dernier update sur une Debian, j’ai envoyé des mails à Deimos (que je remercie encore une fois) bref j’ai ouvert une boîte de Pandore. Le bilan est donc extrêmement positif


Je vous mets une bonne fois pour toute, le résultat d’un ansible localhost -m setup afin de bien voir les variables avec lesquelles vous pouvez jouer directement. C’est sur un pc portable Xubuntu.

Les commentaires sont fermés.