J'ai quelques problèmes étranges avec ma boîte ansible (vagabond).

Tout a fonctionné hier et mon cahier a bien fonctionné.

Aujourd'hui, ansible dépend de "rassembler des faits"?

Voici la sortie commentée:

<5.xxx.xxx.xxx> ESTABLISH CONNECTION FOR USER: deploy
<5.xxx.xxx.xxx> REMOTE_MODULE setup
<5.xxx.xxx.xxx> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-
o', 'ControlPersist=60s', '-o', 'ControlPath=/home/vagrant/.ansible/cp/ansible-s
sh-%h-%p-%r', '-o', 'Port=2221', '-o', 'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o
', 'PasswordAuthentication=no', '-o', 'User=deploy', '-o', 'ConnectTimeout=10',
'5.xxx.xxx.xxx', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1411372677
.18-251130781588968 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1411372677.18-2
51130781588968 && echo $HOME/.ansible/tmp/ansible-tmp-1411372677.18-251130781588
968'"]

J'avais un problème similaire avec Ansible ping sur Vagrant, il est soudainement bloqué sans raison et a déjà fonctionné parfaitement. Contrairement à tout autre problème comme ssh ou un problème de connectivité, il meurt pour toujours sans délai.

Une chose que j'ai faite pour résoudre ce problème est de nettoyer le ~/.ansiblerépertoire et cela fonctionne à nouveau. Je ne peux pas savoir pourquoi, mais le problème a été résolu.

Si vous devez le modifier à nouveau, essayez de nettoyer le ~/.ansibledossier avant d’actualiser votre Vagrant.

Pour moi, le module du module de configuration était bloqué sur un montage NFS mort.

Si vous faites un "df" sur votre machine et que rien ne se passe, vous serez peut-être dans le même cas.

PS: si vous ne pouvez pas démonter le partage / point de montage NFS, envisagez d’utiliser le mauvais "umount -l".

Ansible peut se bloquer comme ceci pour plusieurs raisons, généralement à cause d'un problème de connexion ou du blocage du module de configuration. Voici comment réduire le problème pour le résoudre.

Ansible ne peut pas se connecter à l'hôte de destination

Problèmes de clé d'hôte (connus_hôtes)

1) Sur les anciennes versions d'Ansible (2.1 ou antérieures), Ansible ne vous dirait pas toujours si la clé de l'hôte pour la destination n'existe pas sur la source ou en cas de non concordance.

Solution: essayez d'ouvrir une connexion SSH avec les mêmes paramètres pour cette destination. Vous pouvez trouver les erreurs SSH que vous devez résoudre, puis la commande fonctionnera.

2) Parfois, Ansible affiche un message de connexion SSH pour vous au milieu d'autres états, ce qui provoque le "blocage" d'Ansible dans cette tâche:

Warning: the ECDSA host key for 'myhost' differs from the key for the IP address '10.10.1.10'
Offending key for IP in /etc/ssh/ssh_known_hosts:246
Matching host key in /etc/ssh/ssh_known_hosts:477
Are you sure you want to continue connecting (yes/no)?

Dans ce cas, il suffit de taper «oui» pour autant de questions SSH que l’on vous a demandé de poursuivre la partie. Ensuite, vous pouvez résoudre les problèmes connus de root_hosts.

Problèmes d'authentification par clé privée

Si vous utilisez une authentification à base de clé ou un mot de passe, les autres problèmes incluent:

• La clé privée peut ne pas être configurée correctement sur la destination
• La clé privée peut avoir des autorisations incorrectes localement (doit être lisible uniquement par l'utilisateur exécutant le travail Ansible)

Solution: essayez de vous lancer ansible -m ping <destination> -kcontre l'hôte à problème. Si cela ne fonctionne pas, essayez les solutions de problèmes de clé d'hôte ci-dessus.

Ansible ne peut pas rassembler rapidement les faits

Le setupmodule (lorsqu'il est exécuté automatiquement au début d'une ansible-playbookexécution ou manuellement ansible -m setup <host>) peut se bloquer lors de la collecte d'informations matérielles (par exemple, en obtenant des informations sur le disque des hôtes avec une E / S élevée, des entrées de montage incorrectes, etc.).

Solution: essayez de courir ansible -m setup -a gather_subset=!all <destination>. Si cela fonctionne, vous devriez envisager de définir cette ligne dans votre ansible.cfg:

gather_subset=!hardware

J'ai eu un problème similaire avec Ansible suspendu à Gathering Facts. J'ai réduit mon script à une invite sans tâches ni rôles, et celui-ci était toujours bloqué.

J'ai trouvé 12 processus bloqués dans ma liste de processus accumulés au cours de la journée.

/usr/bin/python /tmp/ansible_Jfv4PA/ansible_module_setup.py
/usr/bin/python /tmp/ansible_M2T10L/ansible_module_setup.py

Une fois que j'ai tué ceux-ci, ça a recommencé à fonctionner.

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=auto
• ControlPersist=60s
• ControlPath=/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:

• Désactiver complètement le module d'installation
• Modifiez la configuration du module d’installation pour n’en inclure que certaines parties.
  • Via des arguments de ligne de commande
  • Via les fichiers de configuration ansible

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

Dmytro est sur quelque chose!

Ansible utilise le nom de domaine complet de l'hôte. Si votre hôte ne peut pas être résolu par le DNS et que vous n'avez pas de mappage dans /etc/hostsansible, le délai d'attente du DNS sera expiré.

En ajoutant ::1 <fqdn>le fichier hôte des machines sur lesquelles vous vous connectez, Ansible obtiendra immédiatement le nom de domaine complet sans passer par DNS.

Notez que l'hôte doit rechercher des hôtes à partir de /etc/hosts. Il s'agit de la configuration par défaut pour la plupart des systèmes linux, si ce n'est tous, mais si votre modification /etc/nsswitch.confégalement pose un problème.

J'ai eu le même problème. Vous ne recevez aucune information utile en exécutant ansible en mode prolixe.

Le serveur a été réapprovisionné avant d'exécuter le playbook.

La suppression du serveur de la liste des hôtes connus a résolu ce problème à l'aide de la commande ci-dessous.

$ ssh-keygen -f "~/.ssh/known_hosts" -R <hostname>
$ ssh-keygen -f "~/.ssh/known_hosts" -R <ip_address>

Remarque: vous devez supprimer le nom d'hôte et l'adresse IP.

Je ne sais pas si vous utilisez un cahier sudo - mais moi, c'était suspendu au mot de passe Sudo.

De la documentation - vous pouvez tuer cela, puis utiliser -Kaussi bien.

Bonne chance.

L'empreinte digitale de votre système cible a peut-être changé, par exemple lorsque vous réinstallez le système d'exploitation du serveur. Vous devez supprimer les entrées dans known_hosts , ansible ne vous informera pas qu'une entrée non fiable pose problème, elle reste bloquée exactement comme vous le décrivez.

Il semble qu’ansible ne puisse pas s’authentifier ... utilisez donc -k pour lui permettre de demander le mot de passe du serveur .... comme indiqué ci-dessous:

ansible-playbook  -K -i hosts playbook.yml -vvvv

La non-concordance du nom de domaine complet (FQDN) et du nom d’hôte peut également provoquer un hangout ansible. J'ai utilisé le nom de domaine complet avec un domaine différent du domaine du nom d'hôte. Après avoir rendu les deux égaux , ansible fonctionne parfaitement. Vous pouvez éventuellement comparer le nom de domaine complet et le nom d'hôte avant d'exécuter des tâches sur un hôte distant. J'espère que ça aide!

J'ai résolu ce problème en ressaisissant la boîte de vagabond

vagrant destroy
vagrant up

Dans mon cas, ansible a cessé de travailler au milieu d'une tâche. La raison était que mon agent ssh a cessé de fonctionner ( ssh-add -lne renvoyait rien). J'ai tout redémarré et cela a encore fonctionné. Vérifiez donc si votre agent ssh fonctionne correctement ( ssh-add -lne doit pas rester bloqué).

La suppression ~/.ansibleseule ne l’a pas fait pour moi. Donc, pour vérifier ce qui est dans ce répertoire, je viens de faire un ctrl-z (mettre le processus en veille) et de vérifier, puis de continuer le processus ansible via fg. Je n'ai rien supprimé dans ce cas. mais après cela a juste continué. Donc, j'ai juste essayé le ctrl-z-> fgseul et cela a également fonctionné. On se croirait danser sous la pluie, mais si quelqu'un est coincé, essayez-le aussi.

J'ai corrigé la cause de ce problème en suivant les conseils de Pourquoi mon ansible-playbook se bloque dans «Rassembler les faits»? article de blog.

Il peut être simplifié pour:

1. Définir DEFAULT_KEEP_REMOTE_FILES=yespour conserver les commandes et activer-vvvv

2. Exécutez le playbook à nouveau.

3. Lorsque le jeu stucks copier la dernière commande shell imprimée (la partie après /bin/sh -c)

4. Connectez-vous sur le serveur via ssh.

5. Utilisez stracepour rejouer la dernière étape de la pièce. La commande step est copiée à partir de la -vvvsortie. Par exemple:strace -f /bin/sh -c "echo BECOME-SUCCESS-ltxvshvezrnmumzdprccoiekhjheuwxt; /usr/bin/python /home/user/.ansible/tmp/ansible-tmp-1527099315.31-224479822965785/setup.py"

6. Vérifiez sur quel appel l'étape "effacée" est bloquée et résolvez-la :)

Dans mon cas, c'était un lecteur réseau inaccessible ...

Le mot de passe de Sudo est le problème. Assurez-vous que (1) vous pouvez émettre 'sudo n'importe quoi ' sur un terminal nouvellement ouvert (où le mot de passe n'est pas mis en cache) sans indiquer à un (2) que la marionnette n'a pas annulé vos précédentes modifications manuelles 'sudoers'.