Playbooks complexes – Installation DokuWiki

Aujourd’hui nous allons voir le concept des rôles et des tags au travers d’un cas concret qui est l’installation de DokuWiki.

Ce que fait ce playbook :
– Il installe ou upgrade DokuWiki à la dernière version stable sur une Debian
– Il est une base saine pour arriver à un playbook LAMP, il faut très peu de choses pour passer du rôle nginx à un rôle apache (idem pour php). Il reste le rôle mysql. Ce sera évidemment mes prochains rôles, à voir si ça vous branche, je n’ai pas l’intention de vous pourrir d’articles Ansible
– Il est une base saine pour installer un paquet de services web ne nécessitant pas une base de données (PluXml, Shaarli, etc.)

Ce que ne fait pas ce playbook :
– Il ne fait pas le café
– Il ne fait pas la vaisselle
– J’ai fait un paquet de tests mais j’ai pu passer à côté de quelque chose donc si vous avez des erreurs, si l’upgrade ne fonctionne pas, merci de me le remonter
– Évidemment le but n’est pas de transformer votre installation existante Apache avec DokuWiki en Nginx avec DokuWiki. L’idée c’est de partir sur une installation neuve grâce à ce playbook et l’utiliser pour tous les upgrades pour les 10000 prochaines années
– Il faut modifier les variables à l’intérieur de install_dokuwiki.yml, ça ne se fait pas tout seul évidemment (attention à bien modifier les deux dokuwiki_folder). Par défaut, j’ai mis le dotdeb_repo à False mais chez moi, c’est en True. Méfiance si vous avez un LAMP sur votre machine car en activant dotdeb_repo, il va vous mettre PHP et MySQL à la dernière version
– Je vous invite à modifier les droits sur le dossier dokuwiki_folder dans le rôle dokuwiki
– Si vous activez les dépôts Dotdeb que vous lancez le playbook puis que vous les désactivez que vous relancez le playbook vous allez évidemment avoir des problèmes. Nginx ne sait pas passer d’une version plus récente à une version plus ancienne

Je suis parti de l’article fourni sur la documentation de DokuWiki :
– J’ai viré la task Deny access to install.php car je trouve particulièrement mauvais d’avoir un « mode d’emploi » pour installer le DokuWiki (c’est-à-dire penser à faire –skip-tags=after_installation sinon il vous vire le install.php donc vous ne pourrez pas installer DokuWiki)
– J’ai amélioré (templates et variables) et corrigé certaines choses
– Le fichier dokuwiki.j2 n’est pas du tout le même que celui fourni chez eux pour la simple et bonne raison qu’il ne fonctionne pas. Étant une quiche sur Nginx, je vous invite à fournir un meilleur que le mien (qui est fonctionnel tout de même et entièrement pompé ici)
– J’ai rajouté le rôle Dotdeb
– Il vous suffira ensuite d’aller sur http://SRV-NEW/install.php pour installer DokuWiki et penser ensuite à supprimer le fichier install.php !


Mais c’est quoi alors les rôles et les tags ?

Le concept de rôle est probablement la chose la plus importante d’Ansible. Le but est de vous fabriquer des playbooks modulaires. Par exemple ci-dessous nous avons les rôles dotdeb, dokuwiki, nginx, php5-fpm. Chaque rôle est réutilisable dans un autre playbook. Ainsi on pourrait très bien avoir les rôles dotdeb, pluxml, nginx, php5-fpm. Le but est de pouvoir mixer et réutiliser les rôles dans les playbooks.

Les tags permettent de jouer ou sauter des tasks aisément :
– ansible-playbook install_dokuwiki.yml -e ‘host=SRV-NEW’ -t dokuwiki ne lancera que les tasks taguées dokuwiki. Cela apporte encore plus de modularité et un gain de temps considérable pour débugger un playbook car cela évite de rejouer tout le playbook. On peut évidemment avoir à l’intérieur d’un même fichier main.yml, un tag soft_install, un autre soft_conf et un dernier soft_restart et ne lancer via –tags= (même chose que -t) qu’une seule task
– ansible-playbook install_dokuwiki.yml -e ‘host=SRV-NEW’ –skip-tags=dokuwiki jouera tout le playbook en sautant les tasks taguées dokuwiki. Toujours plus de modularité, on peut ainsi sauter des tasks posant problème ou prévoir une action spéciale. Voir l’exemple à la fin de page de l’article fourni sur la documentation de DokuWiki


Utilisation du playbook : ansible-playbook install_dokuwiki.yml -e ‘host=SRV-NEW’
Utilité du playbook : Installer ou upgrader DokuWiki à la dernière version stable
Playbook install_dokuwiki.yml

Explications : J’ai choisi une présentation en role invocation des variables car je n’ai pas d’intérêt à mettre mes variables ailleurs (pas un parc mirobolant) et parce qu’il n’y a que comme ça que les noms des tasks fonctionnent avec les variables. Le défaut c’est que pour chaque rôle il faut repréciser les variables, c’est pour cela que pour le rôle nginx et dokuwiki j’ai dokuwiki_folder.

Les variables à modifier sont dotdeb_repo (True vous activez les dépôts Dotdeb), dotdeb_repo_version (squeeze ou wheezy selon la version que vous souhaitez de Dotdeb), dokuwiki_folder qui contiendra le répertoire d’installation de votre Dokuwiki, vhost_file qui est le fichier de configuration de votre VirtualHost, vhost_name qui est le nom de votre VirtualHost.

Le fichier roles/dotdeb/tasks/main.yml (rôle dotdeb)

Explications : Remarquez le register qui enregistre le résultat de la task Add dotdeb repository puis après la condition que nous utilisons pour lancer une tâche ou pas (when: dotdeb_installed|changed). Ainsi si le dépôt Dotdeb n’est pas installé, les tasks Install dotdeb key et Update APT package cache ne seront pas jouées.

Le fichier roles/dokuwiki/tasks/main.yml (rôle dokuwiki)

Explications : Je pense que tout est compréhensible aisément si ce n’est pas le cas je vous invite à poser des questions dans les commentaires.

Le fichier roles/dokuwiki/templates/dokuwiki.j2 (template vhost dokuwiki)

Explications : Je nie toute responsabilité lol.

Le fichier roles/php5-fpm/tasks/main.yml (rôle php5-fpm)

Explications : RAS.

Le fichier roles/nginx/tasks/main.yml (rôle nginx)

Explications : Cela me paraît également simple à comprendre. Notez dans le nom des tâches les variables {{ vhost_name }} lors du déroulement du playbook les variables seront remplacées par leurs valeurs.

Le fichier roles/handlers/main.yml (handlers)

Explications : J’ai choisi un fichier principal pour les handlers. Une de mes principales motivations pour cela est que c’est de la mer** donc je vais très peu les utiliser et je les veux tous à un seul endroit pour ne pas les perdre de vue.


Bonus du jour, bonjour !

J’avoue c’est du rapide mais comme ça va vous donner des idées, je me pardonne (et je donne la source bien sûr).

Utilisation du playbook : ansible-playbook update_all.yml -e ‘host=prod’
Utilité du playbook : Mettre à jour la distribution peu importe que l’on soit sous Ubuntu, Debian ou CentOS, RHEL
Playbook update_all.yml

Les commentaires sont fermés.