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.