Table des matières

Ansible: playbook en mode avancé 2

Voyons quelques modules qui peuvent etre sympa à connaitre et leur paramètres.

Pour consulter l'aide si on ne précise pas l'espace de nom alors par défaut c'est ansible.builtin.xxxxx. Si on ne trouve rien essayer l'espace de nom community.general.xxxx

Si un module n'est pas présent dans votre installation (ansible-doc -l), il est possible de le chercher sur ansible galaxy et de l'installer avec:

par exemple les modules fournis par community.general (normalement déjà installé)

ansible-galaxy collection install community.general

Particularité des modules RAW, SHELL et COMMAND

Ces 3 modules exécutent directement des commandes 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/

Pour manipuler les fichiers

Pour configurer un service

Pour gérer le système