Après avoir vu la mise en route et les bases de ansible nous survolerons les possibiités plus avancés avec les playbooks et leur optimisation avec les variables, les fichiers jinja2, les headers et les roles… sans rentrer dans les détails d'expert!

On a vu que l'idempotence est le fait que une l'état final atteint, quelque soit le nombre de fois qu'on répète une tache les actions de cette tache ne seront pas rejouées sauf pour remettre l'état final attendu si celui-ci a été modifié entre temps.

C'est grace à cette capacité qu'il n'y a pas de risque de relancer x fois un playbook. Au contraire cela permet de recorriger l'état si une modification a été faite et qu'elle l'a modifie !

Ces 3 modules exécutent directement des coomandes système sur la cible. Ils sont utiles seulement si aucun module ne répond à vos besoins (ou si vous n'avez pas encore eu le temps de comprendre comment il marche). Ils ne doivent être envisagés qu'en dernier recours.

Le module RAW est le seul qui n'a pas besoin de python. Donc utile pour déployer python sur une nouvelle cibe ou gérer des commutateurs réseaux.

- name: Bootstrap a host without Python installed
  ansible.builtin.raw: apt install -y python3

- name: List user accounts on a Windows system
  ansible.builtin.raw: Get-WmiObject -Class Win32_UserAccount

Le module SHELL passe la commande à un interpréteur sur la cible, ce qui rend disponibles les tubes, les redirections et l'expansion de variables. Ansible ouvre l'interpréteur spécifié pour y executer les commandes demandées. Mais là il faudra gérer le retours des commandes ET du module qui ne sont pas toujours ce qu'on attend.

Le module COMMAND exécute un binaire directement, sans passer par un interpréteur. Une commande exécutée par le module ne connait pas les spécificités d'un environnement shell local. La conséquenc : $HOME, *, | et > ne sont pas interprétés, ils arrivent au programme sous forme de caractères littéraux. Donc plus sure.

Pas de shell = pas d'interprétation des $VAR, des |, des >. Plus sûr car pas d'injection possible via une variable Jinja mal échappée. Préféré à shell: chaque fois que c'est possible.

example dans un playbook

- name: Générer un certificat (sans pipe ni redirection)
  ansible.builtin.command:
    cmd: openssl req -x509 -newkey rsa:4096 -keyout /etc/ssl/key.pem -out /etc/ssl/cert.pem -days 365 -nodes -subj "/CN=db1.lab"
    creates: /etc/ssl/cert.pem

Aucun de ces modules ne gèrent l'idempotence ! Donc quelque soit le résultat ou l'état final de la cible, une action avec ces modules sera TOUJOURS exécutée.

information détaillé :

https://blog.stephane-robert.info/docs/infra-as-code/gestion-de-configuration/ansible/modules/complements/raw-command-shell/

Maintenant qu'on a vu les modules de “secours” voyons quelque modules qui peuvent etre sympa à connaitre et leur paramètres.