Et voici le dernier article de cette sĂ©rie consacrĂ©e Ă  l’outil de dĂ©ploiement Ansible. Vous y trouverez essentiellement des ressources utiles, bonnes pratiques acquises avec l’expĂ©rience, etc.

Bonnes pratiques et ressources

Quelques bonnes pratiques

La documentation officielle Ansible en propose une très bonne liste. Nous allons en reprendre quelques unes ici. J’ajouterai Ă©galement celles apprises avec l’expĂ©rience.

Organisation de l’arborescence

Ansible recommande deux versions, personnellement j’applique celle-ci :

./
    inventories/
        production/
            hosts # le fichier d'inventaire
            group_vars/
                group1.yml
                group2.yml
            hosts_vars/
                host1.yml
                host2.yml
        preprod/
            hosts # le fichier d'inventaire
            group_vars/
                group1.yml
                group2.yml
            hosts_vars/
                host1.yml
                host2.yml
    playbook1.yml
    playbook2.yml
    roles/
        role1/
        role2/
        role3/

Cette proposition rĂ©pond aussi Ă  la question frĂ©quente qui se demande comment diffĂ©rencier les hosts de production des preproductions : l’idĂ©al est de crĂ©er des inventaires sĂ©parĂ©s. Ceci vous permet aussi de gĂ©rer des variables spĂ©cifiques via le group_vars/host_vars.

Les handlers pour les actions post

On l’a vu dans l’article sur les playbooks, lorsqu’une action doit ĂŞtre dĂ©clenchĂ©e après une tâche, il convient d’utiliser l’instruction notify dans la tâche avec le nom d’un handler tel que dĂ©fini dans handlers/main.yml.

Par exemple nous modifions la configuration d’Apache HTTPD et rechargeons le service pour prise en compte.

Dans le fichier tasks/main.yml du rĂ´le :

- name: "deploy httpd.conf"
  template:
    src: etc_httpd_conf_httpd.conf.j2
    dest: /etc/httpd/conf/httpd.conf
  notify: reload apache

Dans handlers/main.yml

- name: reload apache
  service:
    name: httpd
    state: reloaded

Il est toujours possible de tester le rĂ©sultat d’une tâche pour en dĂ©clencher une autre, mais cela n’est pas recommandĂ© par l’outil.

Les rôles sont réutilisables, les playbooks jetables

Un playbook peut ĂŞtre Ă©crit pour un besoin donnĂ© et ĂŞtre jetĂ© lorsqu’il n’est plus nĂ©cessaire. Si le code est prĂ©vu pour ĂŞtre rĂ©utilisĂ©, il convient de l’Ă©crire sous la forme d’un rĂ´le pour pouvoir l’appeler dans diverses playbooks sans avoir Ă  tout rĂ©Ă©crire.

Organiser son inventaire et grouper

Comme dit dans l’article sur l’inventaire, l’organisation de celui-ci va conditionner comment vous Ă©crirez votre code. Essayez de schĂ©matiser votre infrasture par type de serveur, rĂ´le applicatif, ou encore par localisation. Cela vous permettra des exĂ©cutions ciblĂ©es faciles et Ă©vitera de retoucher le code si un cas de figure n’a pas Ă©tĂ© prĂ©vu.

Assurez-vous de la compatibilité OS

Les distributions Linux peuvent avoir des diffĂ©rences entre elles, pensez Ă  tester en premier lieu avec le module assert que l’environnement attaquĂ© est compatible avec votre rĂ´le. (exemple : yum versus apt pour la gestion de paquets, ou encore le nommage de paquets qui peut diverger)

Toujours nommer ses tâches

L’instruction name est vitale pour s’y retrouver dans le code !

Faire simple

Un code facile a maintenir c’est un code simple, n’essayez pas de faire des choses complexes inutilement. Si quelque chose devient trop compliquĂ©, ça peut ĂŞtre l’occasion de le simplifier. Un code trop complexe risque aussi d’entraĂ®ner une perte de maĂ®trise et la peur de l’exĂ©cuter parce qu’on ne sait pas ce qu’il va faire. C’est tout l’opposĂ© de ce pourquoi Ansible a Ă©tĂ© construit : avoir toujours le mĂŞme rĂ©sultat.

Ne pas penser shell

Les modules Ansible font nativement des contrĂ´les et des actions prĂ© et post : inutile de leur en faire faire en plus. N’abusez-pas non plus du module shell par facilitĂ©, demandez-vous toujours si un module existe pour l’action que vous attendez. Le code shell arbitraire nĂ©cessite de gĂ©rer l’idempotence soit-mĂŞme lĂ  oĂą Ansible est nativement conçu pour le faire.

Versionner le code

Le code Ansible est comme n’importe quel autre programme, il convient de versionner son code avec un gestionnaire de sources tel que Git. Ce combo vous permettra notamment de rentrer dans une approche GitOps oĂą un commit sur un inventaire peut dĂ©clencher un dĂ©ploiement automatisĂ© via l’outillage appropriĂ©.

Respecter l’idempotence

Comme expliquĂ© dans l’introduction, Ansible est nativement idempotent : c’est Ă  dire que le rĂ©sultat sera toujours le mĂŞme, et que l’action ne sera pas refaite si elle l’a dĂ©jĂ  Ă©tĂ© (exemple : il vĂ©rifira les permissions d’un fichier avant de bĂŞtement appliquer celles demandĂ©es par le code). Assurez-vous que votre utilisation des modules respecte ce principe pour justifier l’Ă©tat “changed” d’une tâche.

Exemples :

  • Une tâche shell qui exĂ©cute un rapide ensemble de commandes pour alimenter une variable est-elle rĂ©ellement un changement ?
  • Une tâche qui exĂ©cute une requĂŞte en base de donnĂ©es doit ĂŞtre aussi capable d’alimenter les contrĂ´les de statut changed_when et failed_when. (compter le nombre d’enregs touchĂ©s par un update, vĂ©rifier si l’insert est possible avant de le faire, etc)

Un principe essentiel Ă  retenir est que le rĂ©capitulatif Ă  la fin d’une exĂ©cution Ansible doit ĂŞtre reprĂ©sentatif de ce qui a vraiment Ă©tĂ© changĂ© ou non.

Nommage des templates et fichiers

Une pratique que j’ai rapidement apprise, je nomme toujours les fichiers Ă  dĂ©ployer ou les templates selon l’emplacement oĂą ils devront aller.

Ainsi, le fichier de config Apache HTTPD sous forme de template sera nommĂ© : etc_httpd_conf_httpd.conf.j2; pour ĂŞtre dĂ©ployĂ© dans /etc/httpd/conf/httpd.conf. Cela permet de savoir au premier coup d’oeil oĂą sera dĂ©ployĂ© votre template.

Ansible Lint pour contrĂ´ler son code

Ansible Lint est un outil complĂ©mentaire proposĂ© dans le cadre du repository Ansible Galaxy pour contrĂ´ler la qualitĂ© du code et proposer des axes d’amĂ©lioration ou de bonnes pratiques.

Cet outil peut ĂŞtre activĂ© comme Ă©tape de pre-commit lorsque le code est versionnĂ© par Git qui lancera le contrĂ´le avant d’appliquer le commit. Je vous recommande vivement de l’utiliser, c’est un excellent outil pour apprendre Ă  avoir de bons rĂ©flexes.

Mitogen pour accélérer Ansible

Mitogen est une bibliothèque Python qui permet d’optimiser les programmes utilisant l’auto rĂ©plication comme Ansible. En effet, l’un des soucis d’Ansible est qu’il peut donner l’impression d’ĂŞtre lent car il va ouvrir et fermer une connexion SSH Ă  chaque tâche. Le plugin Mitogen permet de maintenir la session et accĂ©lère grandement les dĂ©ploiements rĂ©alisĂ©s avec ce dernier. Il permet Ă©galement de rĂ©duire la consommation CPU lors de l’exĂ©cution, rendant un dĂ©ploiement plus transparent d’un point de vue utilisation de ressources.

Conclusion

VoilĂ  qui termine cette sĂ©rie de billets dĂ©diĂ©e Ă  Ansible. J’espère que cela vous aura permis de dĂ©couvrir cet outil ou d’approfondir celles-ci. Si vous voyez d’autres bonnes pratiques ou astuces Ă  partager, n’hĂ©sitez-pas.