Contactez-nous

Modules : les briques d'action

Découvrez les modules Ansible, les unités de travail qui exécutent des tâches spécifiques sur vos noeuds gérés. Apprenez comment ils fonctionnent, leur importance et comment trouver celui qu'il vous faut pour chaque action d'automatisation.

Les modules Ansible : les outils de votre caisse à outils d'automatisation

Si les playbooks sont les plans de votre projet d'automatisation, les modules Ansible en sont les outils et les briques de construction. Un module Ansible est une unité de code autonome et réutilisable qu'Ansible exécute sur un noeud géré pour effectuer une tâche spécifique. Que vous souhaitiez installer un paquet, copier un fichier, démarrer un service, créer un utilisateur, ou interagir avec une API cloud, il y a de fortes chances qu'un module Ansible existe déjà pour cela.

Ansible est livré avec une vaste bibliothèque de modules, couvrant un large éventail de tâches d'administration système, de gestion réseau, d'interaction avec des services cloud, et bien plus encore. Ces modules sont écrits en Python pour la plupart, mais peuvent théoriquement être écrits dans n'importe quel langage capable de retourner du JSON en sortie standard. Lorsqu'Ansible exécute une tâche, il transfère le code du module concerné sur le noeud géré (sauf pour certains modules comme `raw` ou `script`), l'exécute avec les paramètres que vous avez spécifiés, puis récupère le résultat (succès, échec, changements effectués, informations retournées).

La grande force des modules Ansible réside dans leur conception souvent idempotente. Comme nous l'avons vu, cela signifie qu'appliquer un module plusieurs fois avec les mêmes paramètres produira le même état final sans causer d'effets de bord si l'état est déjà atteint. Par exemple, le module `ansible.builtin.package` (ou ses alias comme `apt`, `yum`, `dnf`) s'assurera qu'un paquet est installé ; si le paquet est déjà là, il ne fera rien. Cette idempotence est la clé de la fiabilité des playbooks Ansible.

Utilisation des modules : syntaxe et paramètres

Dans un playbook Ansible, chaque tâche invoque un module. La syntaxe typique pour appeler un module au sein d'une tâche est la suivante :

- name: Assurer que Nginx est installé
  ansible.builtin.apt: # ou yum, dnf, package selon le système
    name: nginx
    state: present
    update_cache: yes
  become: yes

Dans cet exemple :

  • `name`: est une description de la tâche, lisible par l'humain.
  • `ansible.builtin.apt`: est le nom complet du module utilisé (FQCN - Fully Qualified Collection Name). `apt` est un alias courant.
  • `name: nginx`, `state: present`, `update_cache: yes`: sont les paramètres (ou arguments) passés au module `apt`. Chaque module a son propre ensemble de paramètres.
  • `become: yes`: indique à Ansible d'exécuter cette tâche avec des privilèges élevés (généralement root).

Les modules acceptent différents types de paramètres : des chaînes de caractères, des booléens (`yes`/`no`, `true`/`false`), des nombres, des listes, ou des dictionnaires. La documentation de chaque module (`ansible-doc nom_du_module`) détaille tous les paramètres disponibles, leur type, s'ils sont requis ou optionnels, et leur valeur par défaut.

Il existe une syntaxe alternative plus concise pour passer les paramètres, souvent utilisée lorsque le module a un paramètre principal bien défini (souvent appelé `_raw_params` ou `free_form` dans la documentation) :

- name: Pinguer tous les serveurs web
  ansible.builtin.ping: # Pas de paramètres explicites ici pour ping

- name: Copier un fichier de configuration
  ansible.builtin.copy: src=/srv/myfiles/foo.conf dest=/etc/foo.conf owner=foo group=foo mode='0644'

Dans le cas du module `copy`, les paramètres `src`, `dest`, `owner`, `group`, et `mode` sont passés sur une seule ligne. Ansible est capable d'interpréter cette forme pour de nombreux modules courants. Cependant, pour la clarté et pour les modules avec de nombreux paramètres, la forme indentée clé-valeur est souvent préférée.

Il est crucial de consulter la documentation d'un module avant de l'utiliser pour comprendre ses fonctionnalités exactes, les paramètres qu'il attend, et les valeurs qu'il peut retourner. La commande `ansible-doc` est votre meilleure amie pour cela :

ansible-doc ansible.builtin.service
ansible-doc yum # Fonctionne aussi avec les noms courts

Cette commande affiche une description complète du module, la liste de ses paramètres avec leurs options, et des exemples d'utilisation, ce qui est extrêmement utile lors de l'écriture de playbooks.

Catégories de modules et modules essentiels

Les modules Ansible sont généralement regroupés en catégories en fonction de leur domaine d'action. On trouve par exemple :

  • Modules Système : Pour la gestion des paquets (`package`, `apt`, `yum`, `dnf`), des services (`service`, `systemd`), des utilisateurs et groupes (`user`, `group`), des fichiers et répertoires (`file`, `copy`, `template`, `lineinfile`, `blockinfile`, `find`), des tâches planifiées (`cron`), du montage de systèmes de fichiers (`mount`), etc.
  • Modules Commandes : Pour exécuter des commandes arbitraires (`command`, `shell`, `script`, `raw`). A utiliser avec précaution car ils sont moins susceptibles d'être idempotents.
  • Modules Réseau : Pour configurer des équipements réseau (Cisco, Juniper, Arista, etc.) via des modules spécifiques à chaque constructeur (par exemple, `ios_config`, `junos_config`).
  • Modules Cloud : Pour interagir avec les API des fournisseurs de cloud (AWS, Azure, GCP, OpenStack, VMware) afin de provisionner et gérer des ressources (instances, réseaux, stockage, bases de données, etc.). Exemples : `ec2_instance`, `azure_rm_virtualmachine`, `gcp_compute_instance`.
  • Modules Base de données : Pour gérer des bases de données (MySQL, PostgreSQL, MongoDB, etc.), créer des utilisateurs, des bases, exécuter des requêtes. Exemples : `mysql_db`, `postgresql_user`.
  • Modules Notification : Pour envoyer des notifications via divers canaux (email, Slack, etc.).

Parmi les modules les plus fréquemment utilisés, on peut citer :

  • `ansible.builtin.ping`: Pour tester la connectivité et la capacité d'Ansible à exécuter du Python sur les noeuds gérés.
  • `ansible.builtin.debug`: Pour afficher des messages ou la valeur de variables pendant l'exécution d'un playbook.
  • `ansible.builtin.copy`: Pour copier des fichiers depuis le noeud de contrôle vers les noeuds gérés.
  • `ansible.builtin.template`: Similaire à `copy`, mais utilise le moteur de templating Jinja2 pour générer le contenu du fichier dynamiquement à partir de variables.
  • `ansible.builtin.file`: Pour gérer les attributs des fichiers et répertoires (existence, type, permissions, propriétaire, liens symboliques).
  • `ansible.builtin.service` ou `ansible.builtin.systemd`: Pour gérer l'état des services (démarré, arrêté, redémarré, activé/désactivé au démarrage).
  • `ansible.builtin.package` (ou `apt`, `yum`, `dnf`, etc.) : Pour installer, mettre à jour ou supprimer des paquets logiciels.
  • `ansible.builtin.lineinfile`: Pour s'assurer qu'une ligne spécifique est présente (ou absente) dans un fichier, ou pour la remplacer en utilisant une expression régulière.
  • `ansible.builtin.get_url`: Pour télécharger des fichiers depuis une URL.

La richesse de l'écosystème de modules est un des grands atouts d'Ansible. Si un module n'existe pas pour une tâche très spécifique, il est également possible de développer ses propres modules personnalisés.