Exemple 1 : Vérifier la connectivité avec le module `ping`

Le module `ping` : bien plus qu'un simple test réseau

Lorsque vous débutez avec Ansible ou que vous configurez de nouveaux hôtes, la première étape consiste souvent à vérifier que votre noeud de contrôle peut communiquer correctement avec les noeuds gérés. Pour cela, Ansible fournit le module ping. Contrairement à l'utilitaire ping standard du système d'exploitation qui teste la connectivité réseau via des paquets ICMP, le module ping d'Ansible effectue un test plus complet.

Le module ping d'Ansible vérifie trois aspects cruciaux :

• Connectivité SSH : Ansible peut-il établir une connexion SSH avec le noeud distant ?
• Authentification : Les informations d'authentification (clés SSH, mots de passe si utilisés) sont-elles correctes ?
• Interpréteur Python : Un interpréteur Python compatible est-il présent et accessible sur le noeud distant ? Ansible s'appuie sur Python pour exécuter la plupart de ses modules.

Si toutes ces conditions sont remplies, le module ping renvoie une réponse "pong", signifiant que l'hôte est prêt à être géré par Ansible. C'est donc un excellent premier test pour valider la configuration de base de votre environnement Ansible et de vos noeuds gérés.

Syntaxe de base pour utiliser le module `ping`

L'utilisation du module ping via une commande Ad-Hoc est très simple. Vous spécifiez le pattern d'hôte (quels serveurs cibler) et le module ping. Le module ping lui-même ne requiert généralement pas d'arguments spécifiques via l'option -a pour son fonctionnement de base.

La syntaxe générale est :

ansible  -m ping [options_connexion]

Où :

• : Le ou les hôtes à tester (par exemple, all, webservers, un_serveur_specifique).
• -m ping : Indique explicitement à Ansible d'utiliser le module ping.
• [options_connexion] : Options facultatives comme -i pour spécifier un fichier d'inventaire, -u pour l'utilisateur de connexion, etc., si elles ne sont pas déjà configurées par défaut ou dans l'inventaire.

Supposons que vous ayez un fichier d'inventaire nommé hosts.ini avec le contenu suivant :

# hosts.ini
[webservers]
web01 ansible_host=192.168.1.100
web02 ansible_host=192.168.1.101

[dbservers]
db01 ansible_host=192.168.1.200 ansible_user=admin

Pour tester la connectivité à tous les serveurs du groupe webservers :

ansible webservers -i hosts.ini -m ping

Pour tester un hôte spécifique, db01 (qui utilise un utilisateur de connexion différent) :

ansible db01 -i hosts.ini -m ping

Dans ce second cas, Ansible utilisera automatiquement l'utilisateur admin défini par ansible_user pour db01 dans l'inventaire.

Interpréter la sortie du module `ping`

La sortie du module ping est concise et informative. Une réponse réussie pour un hôte se présente généralement comme suit :

hostname | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Analysons cette sortie :

• hostname | SUCCESS : Indique que le test a réussi pour l'hôte spécifié (hostname sera remplacé par le nom réel de l'hôte).
• "ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"} : Montre que Ansible a trouvé un interpréteur Python (ici, /usr/bin/python3). C'est une information utile, car certains modules pourraient nécessiter une version spécifique de Python.
• "changed": false : Le module ping ne modifie jamais l'état du système, donc changed est toujours false.
• "ping": "pong" : C'est la confirmation que le test est réussi. Le "ping" a reçu un "pong".

Si le test échoue, la sortie sera différente et fournira des indices sur la cause du problème. Par exemple :

• Hôte non joignable (UNREACHABLE) :

hostname | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.168.1.105 port 22: Connection refused",
    "unreachable": true
}

Cela peut indiquer un problème réseau, un pare-feu bloquant la connexion, ou le service SSH non actif sur le noeud distant.

• Echec d'authentification (FAILED) :

hostname | FAILED! => {
    "msg": "Permission denied (publickey,password)."
}

Ceci signifie généralement que les clés SSH ne sont pas correctement configurées ou que le mot de passe fourni (si utilisé) est incorrect.

• Python manquant ou incompatible (FAILED) :

hostname | FAILED! => {
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
    "rc": 127,
    ...
}

Ce type d'erreur indique que l'interpréteur Python spécifié (ou celui découvert automatiquement) n'a pas été trouvé sur le noeud distant.

Utiliser l'option de verbosité (-v, -vv, ou -vvv) peut fournir plus de détails en cas d'échec, notamment sur les étapes de la connexion SSH.

Scénarios d'utilisation et dépannage avec `ping`

Le module ping est votre premier réflexe dans de nombreuses situations :

• Nouvelle installation d'Ansible : Pour vérifier que le noeud de contrôle est correctement configuré pour parler à vos serveurs.
• Ajout de nouveaux hôtes à l'inventaire : Pour s'assurer que les nouveaux serveurs sont accessibles et correctement préparés (SSH, Python).
• Dépannage de connectivité : Si un playbook échoue sur un hôte spécifique avec des erreurs de connexion, un ansible -m ping peut rapidement confirmer si le problème est au niveau de la communication de base.
• Vérification avant des opérations critiques : S'assurer que tous les hôtes cibles sont joignables avant de lancer un playbook qui effectue des modifications importantes.

En cas d'échec du ping, voici quelques pistes de dépannage courantes :

• Problèmes SSH : Vérifiez que le service SSH est actif sur le noeud distant (systemctl status sshd ou équivalent). Assurez-vous que le port SSH (par défaut 22) n'est pas bloqué par un pare-feu (local sur le noeud distant, sur le noeud de contrôle, ou un pare-feu réseau entre les deux).
• Authentification : Si vous utilisez des clés SSH (recommandé), vérifiez que la clé publique du noeud de contrôle est bien présente dans le fichier ~/.ssh/authorized_keys de l'utilisateur de connexion sur le noeud distant. Vérifiez les permissions de ce fichier et du répertoire ~/.ssh. Si vous utilisez ansible_user, assurez-vous que c'est le bon utilisateur.
• Python : Assurez-vous que Python (généralement Python 2.7+ ou Python 3.5+) est installé sur le noeud distant et que son chemin est accessible. Vous pouvez parfois avoir besoin de spécifier l'interpréteur Python exact via la variable d'inventaire ansible_python_interpreter pour un hôte ou un groupe si Ansible ne le découvre pas correctement. Par exemple : mon_serveur ansible_python_interpreter=/usr/bin/python3.
• Erreurs de frappe dans l'inventaire : Vérifiez que les noms d'hôtes, les adresses IP (ansible_host) et les utilisateurs (ansible_user) sont corrects dans votre fichier d'inventaire.

Le module ping, malgré sa simplicité apparente, est donc un outil de diagnostic fondamental qui vous fera gagner beaucoup de temps en validant rapidement la capacité d'Ansible à interagir avec votre infrastructure.