Ansible ist ein sehr leistungsstarkes Tool, mit dem Sie eine Vielzahl von Plattformen über Server, Clouds, Netzwerke, Container und mehr hinweg automatisieren können.
Oft können Sie das, was Sie möchten, automatisieren, indem Sie einfach vorhandene Rollen und Sammlungen wiederverwenden.
Und es stehen viele Module zur Auswahl, die Sie in Ihren Playbooks verwenden können.
Aber wenn Sie anfangen, komplexere Playbooks zu entwickeln und zu testen, werden Sie irgendwann einige Methoden zur Fehlerbehebung benötigen. Dinge wie:
- Überprüfen des Flusses der Ansible-Aufgaben.
- Bestätigung der Datentypen Ihrer Variablen.
- Sie können sogar an einem bestimmten Punkt pausieren, um ihre Werte zu überprüfen.
Einige der in diesem Artikel besprochenen Tipps gelten nur für die Ansible-Ausführung über die Befehlszeile. Andere sind auch gültig, wenn sie von Ansible Tower ausgeführt werden.
1. Ihre Ansible-Umgebung und -Parameter
Wenn Sie untersuchen müssen, warum sich etwas in Ihren Playbooks nicht wie erwartet verhält, ist es normalerweise gut, zunächst Ihre Ansible-Umgebung zu überprüfen.
Welche Versionen und Pfade der Ansible-Binärdateien und von Python verwenden Sie?
Wenn Sie Betriebssystempakete oder Python-Module hinzugefügt haben, die von Ihren Playbooks benötigt werden, „sieht“ der Ansible-Interpreter diese?
Sie können diese grundlegenden Informationen auf viele verschiedene Arten erhalten. Führen Sie in der Befehlszeile die ansible --version aus Befehl.
❯ ansible --version
ansible 2.9.10
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.6/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.6.8 (default, Mar 18 2021, 08:58:41) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]
Dieselben Informationen erhalten Sie, indem Sie andere Ansible-Befehle wie ansible-playbook ausführen oder ansible-config mit der --version Option.
In Ansible Tower werden diese Informationen angezeigt, wenn das Job-Template mit VERBOSITY 2 (More verbose) oder höher ausgeführt wird.
Neben den Versionen und dem Speicherort der Ansible- und Python-Binärdateien ist es immer gut, die für Module verwendeten Pfade zu überprüfen, einschließlich der Frage, ob die Ausführung eine ansible.cfg verwendet Datei, die nicht die Standarddatei ist (d. h. nicht /etc/ansible/ansible.cfg ).
Zum Untersuchen von Optionen aus einer benutzerdefinierten ansible.cfg Datei können Sie Folgendes von der Befehlszeile aus ausführen:
❯ ansible-config dump --only-changed
DEFAULT_BECOME(/home/admin/ansible/ansible.cfg) = True
DEFAULT_BECOME_USER(/home/admin/ansible/ansible.cfg) = root
DEFAULT_FORKS(/home/admin/ansible/ansible.cfg) = 10
DEFAULT_HOST_LIST(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/inventory']
DEFAULT_ROLES_PATH(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/roles']
HOST_KEY_CHECKING(/home/admin/ansible/ansible.cfg) = False Wie der Name schon sagt, werden hier die unterschiedlichen Parameter aufgelistet von den Standardeinstellungen.
2. Wird im ausführlichen Modus ausgeführt
Das Ausführen der Playbooks im Debug-Modus kann der nächste Schritt sein, um mehr Details darüber zu erhalten, was in den Tasks und Variablen passiert.
Von der Befehlszeile aus können Sie -v hinzufügen (oder -vv , -vvv , -vvvv , -vvvvv ). Die höchsten Ausführlichkeitsstufen können manchmal zu viele Informationen enthalten, daher ist es besser, schrittweise in mehreren Ausführungen zu erhöhen, bis Sie das erhalten, was Sie benötigen.
Stufe 4 kann bei der Behebung von Verbindungsproblemen helfen und Stufe 5 ist bei WinRM-Problemen nützlich.
Im Tower können Sie die VERBOSITY auswählen Ebene aus der Jobvorlagendefinition.
Hinweis :Denken Sie daran, den Debug-Modus zu deaktivieren, nachdem Sie das Problem behoben haben, da die detaillierten Informationen nur für die Fehlerbehebung nützlich sind.
Außerdem werden im Debug-Modus die Werte bestimmter Variablen (z. B. Passwörter) angezeigt, es sei denn, Sie verwenden no_log Option in der Aufgabe, also löschen Sie die Ausgaben, wenn Sie fertig sind.
3. Debug verwenden, um Variablen anzuzeigen
Wenn Sie eine gute Vorstellung davon haben, wo Die Probleme könnten darin bestehen, dass Sie einen chirurgischeren Ansatz verwenden können:Zeigen Sie nur die Variablen an, die Sie sehen müssen.
(...)
- name: Display the value of the counter
debug:
msg: "Counter={{ counter }} / Data type={{ counter | type_debug }}"
(...)
TASK [Display the value of the counter] ****************************************************************************
ok: [node1] => {
"msg": "Counter=42 / Data type=AnsibleUnicode"
}
Das Deshalb konnte ich den Zähler nicht erhöhen. Der Filter type_debug zeigt, dass der Datentyp Text ist und nicht int wie ich dachte.
[Das könnte Ihnen auch gefallen: Schnellstartanleitung für Ansible für Linux-Systemadministratoren]
4. Sicherstellen, dass Vars den richtigen Inhalt und Datentyp haben
Sie können das assert verwenden Modul, um zu bestätigen, dass die Variablen den erwarteten Inhalt/Typ haben, und bewirkt, dass die Aufgabe fehlschlägt, wenn etwas nicht stimmt.
Das folgende Playbook veranschaulicht dies:
---
- name: Assert examples
hosts: node1
gather_facts: no
vars:
var01: 13
tasks:
- debug:
msg: "Parameter 01 is {{ (param01 | type_debug) }}"
- name: Make sure that we have the right type of content before proceeding
assert:
that:
- "var01 is defined"
- "(var01 | type_debug) == 'int' "
- "param01 is defined "
- "(param01 | type_debug) == 'int' " Wenn ich das Playbook über die Befehlszeile ausführe, ohne Bereitstellen der Extra-Variablen:
❯ ansible-playbook xassert.yml
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is AnsibleUndefined"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "param01 is defined ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Wenn ich das Playbook über die Befehlszeile ausführe, mit die Extra-Variable:
❯ ansible-playbook xassert.yml -e "param01=99"
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is str"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "(param01 | type_debug) == 'int' ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Sehen Sie, dass der Datentyp als str kommt war eine Überraschung für mich, aber hier gibt es eine Erklärung und eine Lösung.
Wenn Sie dasselbe Playbook von Tower aus ausführen und den Parameter entweder als Extra-Vars oder als Feld aus einer Umfrage übergeben, ist der Datentyp des Parameters int .
Ja, es kann knifflig sein... aber wenn Sie wissen, worauf Sie achten müssen, werden diese "Features" kein Problem für Sie sein.
5. Abrufen einer Liste der Fakten und Variablen
Unabhängig davon, ob Sie Variablen in Ihrem Inventar (für Hosts und/oder Gruppen) definiert oder zusätzliche Variablen während der Ausführung Ihres Playbooks erstellt und zugewiesen haben, kann es irgendwann nützlich sein, ihre Werte zu überprüfen.
---
- name: vars
hosts: node1,node2
tasks:
- name: Dump vars
copy:
content: "{{ hostvars[inventory_hostname] | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_vars.txt"
delegate_to: control
- name: Dump facts
copy:
content: "{{ ansible_facts | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_facts.txt"
delegate_to: control Dadurch werden die Variablen und Fakten (wenn Sie Fakten sammeln) in einzelnen Dateien gespeichert, damit Sie sie analysieren können.
Für die Befehlszeilenausführung habe ich die Aufgabe an meinen Kontrollhost (localhost) delegiert, die Dateien lokal zu speichern, anstatt die Dateien in jedem Knoten separat zu speichern. Wenn Sie vom Turm aus laufen, müssen Sie auch einen auswählen Server, auf dem die Dateien gespeichert werden (es sei denn, Sie haben nur einen Zielknoten und haben nichts dagegen, die Datei dort zu analysieren).
6. Verwenden des Task-Debuggers zur Fehlersuche über die Befehlszeile
Sie können den Ansible-Debugger auch verwenden, um Playbooks schrittweise auszuführen und den Inhalt von Variablen und Argumenten interaktiv zu untersuchen.
Außerdem können Sie die Werte von Variablen auch spontan ändern und die Ausführung fortsetzen.
Der Debugger kann auf Aufgabenebene oder Wiedergabeebene aktiviert werden, wie im folgenden Beispiel:
---
- name: Example using debugger
hosts: localhost
gather_facts: no
vars:
radius: "5.3"
pi: "3.1415926535"
debugger: on_failed
tasks:
- name: Calculate the area of a circle
debug:
msg:
- "Radius.............: {{ radius }}"
- "pi................: {{ pi }}"
- "Area of the circle: {{ (pi * (radius * radius)) }}" Spoiler-Alarm:Ich habe die Variablen als Strings definiert, was offensichtlich einen Fehler verursacht, wenn ich versuche, die Berechnung durchzuführen.
❯ ansible-playbook xdebugger.yml
PLAY [Example using debugger] ****************************************************************************
TASK [Calculate the area of a circle] ****************************************************************************
fatal: [localhost]: FAILED! => {"msg": "Unexpected templating type error occurred on (Area of the circle: {{ (pi * (radius * radius)) }}): can't multiply sequence by non-int of type 'AnsibleUnicode'"}
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['pi']
'3.1415926535'
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
'5.3'
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['radius']=5.3
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
5.3
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> redo
ok: [localhost] => {
"msg": [
"Radius............: 5.3",
"pi................: 3.1415926535",
"Area of the circle: 88.247337636815"
]
}
PLAY RECAP ****************************************************************************
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Was ist hier passiert:
- Anfangs schlug die Aufgabe fehl und beschwerte sich über die Nicht-Int-Variablen.
- Der Debugger wurde aufgerufen.
- Ich habe den Druck (p ) Befehl, um die Werte der Variablen anzuzeigen.
- In diesem Fall wusste ich, dass das Problem im Datentyp lag, aber man könnte denken, dass die Werte korrekt sind (wenn man nicht auf die Anführungszeichen um die Werte achtet).
- Später habe ich den Inhalt der Variablen aktualisiert und ihnen Nummern zugewiesen.
- Dann habe ich das
redoverwendet Befehl, die Aufgabe mit den neuen Werten erneut auszuführen, und sie wurde erfolgreich abgeschlossen.
Dies war ein einfaches Szenario, da wir wissen, dass niemand würde wirklich Ansible verwenden, um die Fläche eines Kreises zu berechnen. Aber in einer komplexeren Situation könnte es nützlich sein, den Inhalt einer Variablen mitten in einer langen Playbook-Ausführung zu finden und von diesem Punkt aus fortfahren zu können, ohne von Grund auf neu zu beginnen.
[ Holen Sie sich dieses kostenlose E-Book:Verwalten Ihrer Kubernetes-Cluster für Dummies. ]
Abschluss
Die Einbeziehung eines guten Arsenals an Fehlerbehebungsoptionen kann Ihnen dabei helfen, Probleme in Ihren Ansible-Playbooks schneller zu identifizieren. Je nachdem, wo Sie in der Ermittlung stehen, sind bestimmte Methoden besser geeignet.
Zum Beispiel, wenn Sie nur versuchen, ein Gefühl dafür zu bekommen, was falsch sein könnte, und wo , möchten Sie vielleicht damit beginnen, den Debug-Level schrittweise zu erhöhen.
Sobald Sie eine bessere Vorstellung von der Stelle des Problems haben, kann es sinnvoll sein, den Debug-Level zu verringern (damit Sie weniger Ausgabe vor sich haben) und Optionen zu verwenden, die für die zu analysierende Aufgabe spezifisch sind.
Die Fehlerbehebung in Ansible kann schwierig sein, aber mit einem methodischen Ansatz in Kombination mit den integrierten Problemlösungstools können Sie es sich selbst viel leichter machen. Bestätigen Sie die Ansible-Umgebung und den Aufgabenablauf, suchen Sie dann nach den richtigen Datentypen und erwägen Sie schließlich, jede Aufgabe anzuhalten und schrittweise durchzugehen.