Introduction aux modules clés

Les modules Ansible : les briques élémentaires de l'automatisation

Au coeur de la puissance et de la flexibilité d'Ansible se trouvent les modules. Un module Ansible est une unité de code autonome, réutilisable, que Ansible exécute sur un noeud géré pour effectuer une tâche spécifique. Pensez aux modules comme à des outils spécialisés dans une vaste boîte à outils : il y a un module pour copier des fichiers, un pour gérer des services, un pour installer des paquets, un pour interagir avec des API cloud, et des milliers d'autres.

Ansible est livré avec une vaste collection de modules intégrés, couvrant une large gamme de tâches d'administration système et d'orchestration. De plus, la communauté Ansible contribue activement à enrichir cet écosystème avec des modules pour de nouvelles technologies et des cas d'usage spécifiques, souvent distribués via les Collections Ansible.

Comprendre comment trouver, utiliser et interpréter la documentation des modules est une compétence fondamentale pour tout utilisateur d'Ansible. Dans ce chapitre, nous allons explorer l'outil ansible-doc, votre guide indispensable pour naviguer dans l'univers des modules, puis nous nous pencherons sur quelques-uns des modules les plus couramment utilisés pour la gestion de fichiers et de services.

Trouver de l'aide sur un module avec `ansible-doc`

Avec des milliers de modules disponibles, il est impossible de connaître par coeur les paramètres et les fonctionnalités de chacun. Heureusement, Ansible fournit l'outil en ligne de commande ansible-doc, qui vous donne accès à la documentation détaillée de n'importe quel module installé sur votre noeud de contrôle.

La syntaxe de base pour utiliser ansible-doc est :

ansible-doc 

Par exemple, pour obtenir la documentation du module copy :

ansible-doc copy

Cette commande affichera une description du module, la liste de tous ses paramètres (avec leur type, s'ils sont requis ou optionnels, leur valeur par défaut), des notes importantes sur son utilisation, des exemples concrets, et parfois des informations sur les valeurs de retour. C'est une ressource inestimable pour comprendre comment utiliser un module correctement.

Quelques options utiles de ansible-doc :

• -l ou --list : Liste tous les modules disponibles sur votre système. Vous pouvez combiner avec grep pour rechercher un module spécifique : ansible-doc -l | grep mysql.
• -s ou --snippet : Affiche un exemple de playbook (snippet) pour le module spécifié. Très pratique pour démarrer rapidement.
• -t ou --type : Permet de filtrer par type de plugin (module, lookup, callback, etc.). Par défaut, c'est module.

Exemple d'obtention d'un snippet pour le module file :

ansible-doc -s file

La sortie vous donnera un exemple de tâche de playbook utilisant le module file, que vous pouvez adapter à vos besoins :

- name: Change file ownership, group and permissions
  ansible.builtin.file:
    path: /etc/foo.conf
    owner: foo
    group: foo
    mode: '0644'

# ... autres exemples ...

Prendre l'habitude d'utiliser ansible-doc régulièrement vous rendra beaucoup plus autonome et efficace dans l'utilisation d'Ansible.

Module `copy` : transférer des fichiers vers les noeuds gérés

Le module copy est l'un des modules les plus fondamentaux et fréquemment utilisés. Son rôle principal est de copier des fichiers depuis le noeud de contrôle Ansible vers un ou plusieurs noeuds gérés. Il peut également être utilisé pour créer des fichiers avec un contenu statique directement défini dans le playbook ou la commande Ad-Hoc.

Principaux paramètres du module copy :

• src : Chemin du fichier sur le noeud de contrôle à copier. Si ce fichier n'est pas trouvé, la tâche échoue. Ce paramètre n'est pas requis si content est utilisé.
• dest : Chemin de destination sur le noeud géré où le fichier sera copié. Ce paramètre est toujours requis. Si le fichier de destination existe déjà, il est écrasé par défaut.
• content : Permet de définir le contenu du fichier directement. Utile pour créer de petits fichiers de configuration sans avoir à les stocker localement. Si content est utilisé, src ne doit pas l'être.
• owner : Nom de l'utilisateur propriétaire du fichier sur le noeud distant.
• group : Nom du groupe propriétaire du fichier sur le noeud distant.
• mode : Permissions du fichier sur le noeud distant (ex: 0644, u+x).
• backup : Si yes, une sauvegarde du fichier de destination original (s'il existe et est différent) sera créée avant d'être écrasé. Le nom de la sauvegarde inclut un timestamp.
• validate : Permet de spécifier une commande de validation à exécuter sur le noeud distant après la copie. Si la commande de validation retourne un code d'erreur non nul, la tâche échoue et le fichier de destination est restauré à son état original (s'il existait). Par exemple, validate: 'visudo -cf %s' pour valider un fichier sudoers. Le %s est remplacé par le chemin du fichier copié.

Exemple : Copier un fichier de configuration nginx.conf local vers les serveurs web.

ansible webservers -m copy -a "src=/local/path/to/nginx.conf dest=/etc/nginx/nginx.conf owner=root group=root mode=0644" -b

Exemple : Créer un petit fichier motd (message du jour) avec un contenu défini.

ansible all -m copy -a "content='Bienvenue sur ce serveur géré par Ansible\n' dest=/etc/motd mode=0644" -b

Le module copy est idempotent : si le fichier de destination existe déjà et que son contenu, son propriétaire, son groupe et ses permissions correspondent à ce qui est spécifié, Ansible ne fera aucune modification et rapportera ok. S'il y a une différence, le fichier sera mis à jour et l'état sera changed.

Module `file` : gérer les fichiers et répertoires (création, permissions, liens)

Alors que le module copy est spécialisé dans le transfert de contenu de fichiers, le module file est conçu pour gérer l'état des fichiers, des répertoires et des liens symboliques sur les noeuds gérés. Il ne transfère pas de contenu (sauf pour créer un fichier vide), mais il permet de s'assurer qu'un fichier ou un répertoire existe avec les bonnes permissions, qu'il est du bon type (fichier, répertoire, lien), ou qu'il est absent.

Principaux paramètres du module file :

• path (ou dest, name) : Chemin du fichier ou du répertoire à gérer sur le noeud distant. Requis.
• state : L'état désiré pour path. Valeurs courantes :
  • touch (défaut si path existe et est un fichier) : Crée un fichier vide s'il n'existe pas. Met à jour son timestamp s'il existe.
  • directory (défaut si path existe et est un répertoire) : S'assure que path est un répertoire. Le crée s'il n'existe pas.
  • file : S'assure que path est un fichier régulier. Crée un fichier vide s'il n'existe pas. Si path est un répertoire ou un lien, la tâche échouera.
  • link : S'assure que path est un lien symbolique pointant vers src.
  • hard : S'assure que path est un lien matériel pointant vers src.
  • absent : S'assure que path (fichier, répertoire ou lien) est supprimé.
• src : Utilisé avec state=link ou state=hard pour spécifier la cible du lien.
• owner, group, mode : Comme pour le module copy, pour définir le propriétaire, le groupe et les permissions.
• recurse : Booléen (yes/no). Si yes et state=directory, applique récursivement les permissions, propriétaire et groupe aux contenus du répertoire. Si state=absent et path est un répertoire, le supprime récursivement. Attention avec cette option !

Exemple : S'assurer qu'un répertoire /opt/myapp/logs existe avec les bonnes permissions.

ansible appservers -m file -a "path=/opt/myapp/logs state=directory owner=appuser group=appgroup mode=0755" -b

Exemple : Créer un fichier vide /tmp/lockfile.

ansible all -m file -a "path=/tmp/lockfile state=touch mode=0600"

Exemple : Créer un lien symbolique /usr/local/bin/mytool pointant vers /opt/mytool/bin/mytool-1.0.

ansible all -m file -a "src=/opt/mytool/bin/mytool-1.0 dest=/usr/local/bin/mytool state=link" -b

Exemple : Supprimer le répertoire /tmp/old_app_cache et tout son contenu.

ansible all -m file -a "path=/tmp/old_app_cache state=absent"

Le module file est également idempotent et est fondamental pour définir l'état désiré de la structure de fichiers et de répertoires sur vos systèmes.

Module `service` ou `systemd` : gérer l'état des services

La gestion des services (démons) est une tâche cruciale en administration système. Ansible fournit des modules pour interagir avec les différents systèmes d'initialisation (init systems) utilisés par les distributions Linux, tels que SystemV, Upstart et Systemd. Le module générique service tente de détecter le système d'init approprié et d'agir en conséquence. Pour les systèmes utilisant exclusivement Systemd (la majorité des distributions Linux modernes), le module systemd offre un contrôle plus fin et plus direct.

Principaux paramètres du module service (et souvent similaires pour systemd) :

• name : Nom du service à gérer (ex: nginx, sshd, apache2). Requis.
• state : L'état désiré du service. Valeurs courantes :
  • started : S'assure que le service est démarré.
  • stopped : S'assure que le service est arrêté.
  • restarted : Arrête puis démarre le service.
  • reloaded : Demande au service de recharger sa configuration sans s'arrêter (si le service le supporte).
• enabled : Booléen (yes/no). S'assure que le service est activé (yes) ou désactivé (no) au démarrage du système. Ce paramètre ne change pas l'état courant du service, seulement son comportement au prochain démarrage.
• arguments (ou args) : Arguments additionnels à passer à la commande de service (usage moins courant).

Le module systemd a des paramètres plus spécifiques à Systemd, comme daemon_reload (pour recharger la configuration de Systemd après avoir modifié un fichier unit), scope (pour gérer des unités non-service), masked (pour complètement désactiver une unité).

Exemple : S'assurer que le service nginx est démarré et activé au démarrage sur les serveurs web (en utilisant le module générique service).

ansible webservers -m service -a "name=nginx state=started enabled=yes" -b

Exemple : Redémarrer le service sshd sur un serveur spécifique (en utilisant le module systemd, si applicable).

ansible mon_serveur -m systemd -a "name=sshd state=restarted" -b

Exemple : Arrêter et désactiver le service bluetooth (module systemd).

ansible workstations -m systemd -a "name=bluetooth state=stopped enabled=no" -b

Ces modules sont idempotents. Si vous demandez de démarrer un service déjà démarré, Ansible ne fera rien. Ils sont essentiels pour garantir que les services critiques de vos applications sont dans l'état attendu. Pour les systèmes plus anciens n'utilisant pas Systemd, le module service reste le choix principal, tandis que pour les systèmes modernes, le module systemd est souvent préféré pour sa richesse fonctionnelle.