Es gibt viele Gründe, warum ein Problem beim Sammeln von Fakten auftreten kann. Bevor Sie jedoch fortfahren, finden Sie hier den ersten Test, den Sie in einer solchen Situation durchführen sollten:
ansible -m ping <hostname>
Dieser Test stellt nur eine Verbindung zum Host her und führt ausreichend Code aus, um Folgendes zurückzugeben:
<hostname> | SUCCESS => {
"changed": false,
"ping": "pong"
}
Wenn dies funktioniert, können Sie Setup- oder Konnektivitätsprobleme so gut wie ausschließen, da dies beweist, dass Sie den Hostnamen des Ziels auflösen, eine Verbindung herstellen, authentifizieren und ein ansprechbares Modul mit dem Remote-Python-Interpreter ausführen können.
Hier ist eine (nicht vollständige) Liste von Dingen, die am Anfang eines Spielbuchs schief gehen können:
Der von ansible ausgeführte Befehl wartet auf eine interaktive Eingabe
Ich kann mich daran erinnern, dass dies bei älteren Ansible-Versionen der Fall war, bei denen ein Befehl auf eine interaktive Eingabe wartete, die niemals eintrat, z. B. ein Sudo-Passwort (wenn Sie einen -KSchalter vergessen haben ) oder die Annahme eines neuen SSH-Host-Fingerabdrucks (für ein neues Ziel) Wirt).
Moderne Versionen von ansible behandeln beide Fälle problemlos und lösen in normalen Fällen sofort einen Fehler aus. Wenn Sie also nicht selbst ssh oder sudo aufrufen, sollten Sie diese Art von Problem nicht haben. Und selbst wenn Sie es taten, würde es sich nachträglich versammeln.
Dead SSH-Master-Verbindung
Es gibt einige sehr interessante Optionen, die dem ssh-Client im hier angegebenen Debug-Protokoll übergeben wurden:
ControlMaster=autoControlPersist=60sControlPath=/home/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r
Diese Optionen sind in man ssh_config dokumentiert .
Standardmäßig versucht ansible, die Verwendung der SSH-Verbindung zu optimieren. Anstatt für einen bestimmten Host eine neue Verbindung für jede einzelne Aufgabe im Spiel zu erstellen, wird diese einmal geöffnet und für das gesamte Spielbuch (und sogar für alle Spielbücher) geöffnet.
Das ist gut so, denn das Herstellen einer neuen Verbindung ist weitaus langsamer und rechenintensiver als das Verwenden einer bereits vorhandenen.
In der Praxis prüft jede SSH-Verbindung, ob ein Socket an vorhanden ist ~/.ansible/cp/some-host-specific-path. Die erste Verbindung kann es nicht finden, daher wird die Verbindung normal hergestellt und anschließend erstellt. Jede nachfolgende Verbindung wird dann nur diese Buchse verwenden, um die bereits hergestellte Verbindung zu durchlaufen.
Auch wenn die hergestellte Verbindung nach einer langen Zeitspanne abläuft und geschlossen wird, wird auch der Socket geschlossen, und wir kehren zum ersten Punkt zurück.
So weit, ist es gut.
Manchmal bricht die Verbindung jedoch tatsächlich ab, der ssh-Client betrachtet sie jedoch weiterhin als hergestellt. Dies passiert normalerweise, wenn Sie das Playbook von Ihrem Laptop aus ausführen und Ihre WLAN-Verbindung verlieren (oder von WLAN auf Ethernet usw. wechseln).
Dieses letzte Beispiel ist eine schreckliche Situation: Sie können mit einer Standard-ssh-Konfiguration ssh auf den Zielcomputer senden, aber solange Ihre vorherige Verbindung noch als aktiv angesehen wird, wird ansible nicht einmal versuchen, eine neue herzustellen.
An dieser Stelle wollen wir nur diesen alten Socket loswerden, und der einfachste Weg, dies zu tun, besteht darin, ihn zu entfernen:
# 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>
Dies ist ideal für eine einmalige Korrektur. Wenn dies jedoch zu häufig vorkommt, müssen Sie möglicherweise nach einer längerfristigen Korrektur suchen. Hier sind einige Hinweise, die zu diesem Ziel beitragen könnten:
- Starte Playbooks von einem Server (mit einer Netzwerkverbindung, die stabiler ist als die deines Laptops)
- Verwenden Sie eine anonyme Konfiguration oder direkt die ssh-Client-Konfiguration , um die Verbindungsfreigabe zu deaktivieren
- Verwenden Sie dieselben Ressourcen, aber zum Optimieren von Zeitüberschreitungen, sodass bei einem Absturz der Master-Verbindung das Zeitlimit schneller abläuft
Bitte beachten Sie, dass sich zum Zeitpunkt des Schreibens einige Optionen geändert haben (z. B. hat mir mein letzter Lauf gezeigt ControlPath=/home/toadjaune/.ansible/cp/871b533295), aber die allgemeine Idee ist immer noch gültig.
Das Sammeln von Fakten nimmt tatsächlich zu viel Zeit in Anspruch
Zu Beginn jedes Spiels sammelt ansible viele Informationen über das Zielsystem und fügt sie in Fakten ein . Dies sind Variablen, die Sie dann in Ihrem Playbook verwenden können und die normalerweise sehr nützlich sind. Manchmal kann es jedoch sehr lang sein, diese Informationen zu erhalten (schlechte Mount-Punkte, Festplatten mit hoher E / A-Rate, hoher Last…).
Abgesehen davon benötigen Sie nicht unbedingt Fakten, um ein Playbook zu erstellen, und mit ziemlicher Sicherheit nicht alle. Lassen Sie uns also versuchen, das zu deaktivieren, was wir nicht benötigen. Dafür gibt es mehrere Möglichkeiten:
Für Debugging-Zwecke ist es sehr praktisch, das Setup-Modul direkt über die Befehlszeile aufzurufen:
ansible -m setup <hostname>
Dieser letzte Befehl sollte ebenso wie Ihr Playbook hängen bleiben und eventuell eine Zeitüberschreitung (oder eine erfolgreiche Zeitüberschreitung) verursachen. Führen wir nun das Modul erneut aus und deaktivieren alles, was wir können:
ansible -m setup -a gather_subset='!all' <hostname>
Wenn dies immer noch nicht funktioniert, können Sie jederzeit versuchen, das Modul in Ihrem Spiel vollständig zu deaktivieren, aber es ist sehr wahrscheinlich, dass Ihr Problem an einer anderen Stelle auftritt.
Wenn es jedoch gut (und schnell) funktioniert, schauen Sie in die Dokumentation des Moduls . Sie haben zwei Möglichkeiten:
- Beschränken Sie das Sammeln von Fakten auf eine Teilmenge, mit Ausnahme dessen, was Sie nicht benötigen (siehe mögliche Werte für
gather_subset).
gather_timeout kann Ihnen auch dabei helfen, Ihr Problem zu beheben, indem Sie mehr Zeit einplanen (obwohl dies einen Timeout-Fehler und keinen Stillstand bedeuten würde).
Andere Probleme
Offensichtlich können andere Dinge schief gehen. Einige Hinweise zum Debuggen:
- Verwenden Sie eine maximale Ausführlichkeitsstufe (
-vvvv), da sie Ihnen jeden ausgeführten Befehl anzeigt
- Verwenden Sie
pingund setupModule direkt über die Befehlszeile, wie oben erläutert
- Versuchen Sie, manuell zu ssh, wenn
ansible -m pingdies nicht funktioniert
vagrant ssh, während des Hangs zu untersuchen, ob inpsund etwas Nützliches enthalten istnetstat? Einer der ersten Verdächtigen in Hangs ist DNS. Überprüfen Sie, ob DNS von der virtuellen Maschine aus aufgelöst wird.