Il y a plusieurs raisons pour lesquelles ansible peut être suspendu lors de la collecte des faits, mais avant d'aller plus loin, voici le premier test que vous devriez faire dans une telle situation:
ansible -m ping <hostname>
Ce test se connecte simplement à l'hôte et exécute suffisamment de code pour renvoyer:
<hostname> | SUCCESS => {
"changed": false,
"ping": "pong"
}
Si cela fonctionne, vous pouvez à peu près éliminer tout problème de configuration ou de connectivité, car cela prouve que vous pouvez résoudre le nom d'hôte cible, ouvrir une connexion, vous authentifier et exécuter un module ansible avec l'interpréteur python distant.
Maintenant, voici une liste (non exhaustive) de problèmes pouvant survenir au début d’un livre de jeu:
La commande exécutée par ansible attend une entrée interactive
Je me souviens de ce qui se passait sur les versions antérieures d'ansible, où une commande attendait une entrée interactive qui ne viendrait jamais, telle qu'un mot de passe sudo (lorsque vous oubliez un -Kcommutateur), ou l'acceptation d'une nouvelle empreinte digitale d'hôte ssh (pour une nouvelle cible hôte).
Les versions modernes de ansible gèrent ces deux cas avec élégance et génèrent immédiatement une erreur pour les cas d'utilisation normaux. Par conséquent, à moins que vous n'appeliez vous-même ssh ou sudo, vous ne devriez pas avoir ce genre de problème. Et même si vous le faisiez, ce serait après la collecte des faits.
Connexion ssh maître mort
Il existe des options très intéressantes passées au client ssh, dans le journal de débogage donné ici:
ControlMaster=autoControlPersist=60sControlPath=/home/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r
Ces options sont documentées dans man ssh_config .
Par défaut, ansible essaiera d’être intelligent en ce qui concerne son utilisation de la connexion SSH. Pour un hôte donné, au lieu de créer une nouvelle connexion pour chaque tâche du jeu, il l'ouvrira une fois et le gardera ouvert pour tout le livre de jeu (et même entre les livres).
C'est une bonne chose, car établir une nouvelle connexion est beaucoup plus lent et demande beaucoup de temps de calcul que d'utiliser une connexion existante.
En pratique, chaque connexion ssh vérifiera l'existence d'un socket sur ~/.ansible/cp/some-host-specific-path. La première connexion ne peut pas la trouver, elle se connecte donc normalement, puis la crée. Chaque connexion ultérieure utilisera alors simplement cette prise pour passer par la connexion déjà établie.
Même si la connexion établie expire enfin et se ferme après une absence d'utilisation prolongée, le socket est également fermé et nous revenons à la case départ.
Jusqu'ici tout va bien.
Parfois, cependant, la connexion meurt, mais le client ssh considère toujours qu’elle est établie. Cela se produit généralement lorsque vous exécutez le Playbook à partir de votre ordinateur portable et que vous perdez votre connexion WiFi (ou passez de WiFi à Ethernet, etc.).
Ce dernier exemple est une situation terrible: vous pouvez ssh sur la machine cible avec une configuration ssh par défaut, mais tant que votre connexion précédente est toujours considérée comme active, ansible n'essayera même pas d'en établir une nouvelle.
À ce stade, nous voulons juste nous débarrasser de cette vieille prise, et le moyen le plus simple de le faire est de l'enlever:
# Delete all the current sockets (may disrupt currently running playbooks)
rm -r ~/.ansible/cp
# Delete only the affected socket (requires to know which one it is)
rm ~/.ansible/cp/<replace-by-your-socket>
C'est parfait pour une solution ponctuelle, mais si cela se produit trop souvent, vous devrez peut-être rechercher une solution à plus long terme. Voici quelques conseils qui pourraient aider à atteindre cet objectif:
- Lancez les livres de lecture depuis un serveur (avec une connexion réseau plus stable que celle de votre ordinateur portable)
- Utilisez la configuration ansible ou directement la configuration du client ssh pour désactiver le partage de connexion
- Utilisez les mêmes ressources, mais pour affiner les délais, de sorte qu'une panne de connexion principale expire plus rapidement
Veuillez noter qu’au moment de la rédaction de ce document, quelques options ont changé (par exemple, c’est ce que ma dernière course m’a donné ControlPath=/home/toadjaune/.ansible/cp/871b533295), mais l’idée générale est toujours valable.
La collecte de faits prend trop de temps
Au début de chaque jeu, ansible collecte de nombreuses informations sur le système cible et les intègre dans les faits . Ce sont des variables que vous pouvez ensuite utiliser dans votre Playbook, et qui sont généralement très utiles, mais parfois, obtenir cette information peut être très long (points de montage incorrects, disques avec une forte entrée / sortie, une charge élevée…)
Ceci étant dit, vous n'avez pas strictement besoin de faits pour gérer un livre de jeu, et presque certainement pas tous, alors essayons de désactiver ce dont nous n'avons pas besoin. Plusieurs options pour cela:
Pour le débogage, il est très pratique d’appeler le module de configuration directement à partir de la ligne de commande:
ansible -m setup <hostname>
Cette dernière commande devrait être suspendue aussi bien que votre livre de jeu et éventuellement expirer (ou réussir). Maintenant, exécutons à nouveau le module en désactivant tout ce que nous pouvons:
ansible -m setup -a gather_subset='!all' <hostname>
Si le problème persiste, vous pouvez toujours essayer de désactiver totalement le module de votre jeu, mais il est fort probable que votre problème se situe ailleurs.
Si, toutefois, cela fonctionne bien (et rapidement), consultez la documentation du module . Vous avez deux options:
- Limitez la collecte des faits à un sous-ensemble, en excluant ce dont vous n’avez pas besoin (voir les valeurs possibles pour
gather_subset)
gather_timeout peut également vous aider à résoudre votre problème en vous accordant plus de temps (bien que ce soit pour réparer une erreur de délai d'attente, pas un blocage)
Autres issues
Évidemment, d'autres choses peuvent mal se passer. Quelques conseils pour aider au débogage:
- Utilisez ansible maximum verbosity level (
-vvvv), car il vous montrera chaque commande exécutée
- Utilisation
pinget setupmodules directement à partir de la ligne de commande comme expliqué ci - dessus
- Essayez de ssh manuellement si
ansible -m pingcela ne fonctionne pas
vagrant sshenquêter pendant le blocage pour voir s’il y avait quelque chose d’utile danspsetnetstat? En outre, l'un des premiers suspects en attente est DNS - vérifiez si la résolution DNS est résolue depuis l'intérieur de la machine virtuelle.