Vor einigen Wochen habe ich begonnen, Ansible zu verwenden, um die Verwaltungsaufgaben für die verschiedenen Organisationen, die ich unterstütze, zu vereinfachen. Außerdem wollte ich vor allem die Verwaltung meiner eigenen Flotte von acht oder neun Hosts vereinfachen (die genaue Anzahl ändert sich häufig). Ich habe meine gesamte Automatisierung mit Bash-Skripten durchgeführt, seit ich angefangen habe, Linux zu verwenden. Ich habe Skripte verwendet, um die Verteilung anderer Skripts zur Aktualisierungsautomatisierung, System- und Benutzerkonfigurationsdateien, Upgrades auf neuere Versionen von Fedora und Updates auf neue Fedora-Versionen zu automatisieren. Und das schließt all die kleinen Ad-hoc-Aufgaben nicht ein, die scheinbar stündlich anfallen.
Skripte werden weiterhin eine wesentliche Rolle in meiner Verwaltungsautomatisierung spielen. Ansible sieht jedoch so aus, als könne es viele Aufgaben übernehmen und sie weitaus besser erledigen als selbst komplexe Skripte. Es dreht sich alles um das Playbook , und in diesem Artikel erstelle ich eine, die eine Systemaktualisierung durchführen kann, während Systemunterschiede berücksichtigt werden.
Ich habe kürzlich über meinen ersten Tag der Verwendung von Ansible geschrieben. Wenn Sie diesen Artikel noch nicht gelesen haben, sollten Sie dies vielleicht tun, bevor Sie mit diesem fortfahren. Dieser Artikel geht davon aus, dass Sie mit der Verwendung von Ansible einige grundlegende Kenntnisse haben. Wenn Sie meinen Artikel unter dem obigen Link gelesen haben, sollten Sie diesem Text ohne Schwierigkeiten folgen können.
Dieser Artikel ist in zwei Teile geteilt, also lesen Sie unbedingt die zweite Hälfte. In diesem Abschnitt definieren wir einige wichtige Ansible-Konzepte und -Begriffe, diskutieren Kommentare und implementieren die erste Wiedergabe des Playbooks. Teil zwei fährt mit den beiden verbleibenden Stücken, einigen Folgeinformationen und meiner Ressourcenliste fort.
Das Playbook dieses Artikels erfordert keine Installation von Ansible-Modulen oder -Sammlungen, die über die standardmäßig integrierten Module hinausgehen. Dieses Playbook wurde mit Ansible 2.9.14 getestet.
[ Den Lesern gefiel auch: Add a repo and install a package the Ansible way ]
Was ist ein Playbook?
Während ich diesen Artikel schrieb, sah ich mir auch einige Sessions des diesjährigen virtuellen AnsibleFest an. Während ich zusah, entwickelte ich meine eigene Beschreibung eines Spielbuchs – eine, die für mich Sinn macht. Diese Beschreibung enthält Spielbuchweisheiten von mehreren Moderatoren sowie einige Bücher und Blogbeiträge, die ich gelesen habe.
Hier ist meine Definition:
Ein Ansible-Playbook ist eine von Menschen erstellte Beschreibung des gewünschten Zustands eines oder mehrerer Computer. Ansible liest das Playbook, vergleicht den tatsächlichen Zustand der Computer mit dem im Playbook angegebenen Zustand und führt die Aufgaben aus, die erforderlich sind, um diese Computer in den im Playbook beschriebenen Zustand zu versetzen.
Aktualisierungen
Das Installieren von Updates auf modernen Linux-Hosts ist eine nahezu ständige Aufgabe, die durch die Anzahl von Sicherheitsfixes und Funktionsverbesserungen, die kontinuierlich veröffentlicht werden, wichtig wird. Wenn bestimmte Software wie Kernel, glibc oder systemd aktualisiert wird, muss auch der Host neu gestartet werden. Außerdem müssen einige zusätzliche Aufgaben durchgeführt werden, wie z. B. das Aktualisieren der Manpage-Datenbank.
Obwohl ich Update-Installationen mit einem coolen Skript automatisiert habe, müssen einige meiner Hosts etwas anders behandelt werden als andere. Beispielsweise möchte ich meine Firewall und meinen E-Mail-/Web-/DHCP-/DNS-Server nicht gleichzeitig aktualisieren. Wenn der Server neu startet, kann die Firewall nicht die Informationen abrufen, die sie benötigt, um mit ihren eigenen Updates fortzufahren, und die anderen Hosts in meinem Netzwerk können dies auch nicht. Wenn die Firewall ausfällt, geht der Zugriff auf die externen Fedora-Repositories für meinen Server und alle anderen internen Hosts verloren. Das bedeutet, auf den Neustart dieser beiden Hosts zu warten, bevor Updates auf den anderen Hosts beginnen können.
Also habe ich diese Updates durchgeführt, indem ich die Skripte auf der Firewall gestartet und dann auf deren Ende gewartet habe, dann zum Server gegangen bin und auf die Beendigung gewartet habe, bevor ich ein kleines Befehlszeilenprogramm ausgeführt habe, um das Update-Skript nacheinander auszuführen der Rest meiner Gastgeber. Ich hätte diese Abhängigkeiten in meine Skripte schreiben können, aber meine ersten Tage mit Ansible haben mir gezeigt, dass es diese Fähigkeiten und viele mehr bereits hat, was meine Aufgabe viel einfacher machen würde. Wirklich – VIEL einfacher. Und insgesamt schneller, ohne Eingreifen meinerseits.
Die Ansible-Strategie
Ansible verwendet eine Hub-Strategie zum Verwalten von Hosts. Die Ansible-Software wird auf dem Host installiert, der als Controller fungiert. Clientseitige Ansible-Software ist nicht vorhanden, daher muss keine auf den Remote-Hosts installiert werden.
Ansible verwendet SSH, das bereits von fast jeder Linux-Distribution installiert ist, um mit entfernten Hosts zu kommunizieren. Obwohl Systemadministratoren Passwörter für den Fernzugriff auf Hosts verwenden können, verringert dies sicherlich die Effizienz und den Hands-Off-Charakter eines Tools wie Ansible. Daher verwende ich, wie die meisten anderen Administratoren, öffentliche/private Schlüsselpaare (PPKP), die als sicherer als Passwörter gelten und die Automatisierung von Aufgaben für einen bis zu Tausenden von Remote-Hosts ohne Eingreifen des Administrators ermöglichen.
Ansible sendet Befehle über SSH an die Remote-Hosts und verwendet die Ergebnisse, um den Erfolg des Befehls zu bestimmen. Es kann diese Ergebnisse auch verwenden, um die nächste Vorgehensweise mithilfe des bedingten wann zu bestimmen Aussagen.
Definition der Anforderungen
Wie jedes Programm, ob in C, Python, Bash oder einer anderen Sprache geschrieben, beginne ich immer mit einer Reihe von Anforderungen. Sie haben mein Buch The Linux Philosophy for SysAdmins gelesen, nicht wahr? Das gilt auch für Tools wie Ansible. Ich muss definieren, wohin ich gehe, damit ich erkennen kann, wann ich angekommen bin.
Dies sind die Anforderungen für mein Ansible-Playbook:
Play 1:Ansible-Controller
- Installieren Sie zuerst Updates auf dem Ansible-Steuerknoten.
- Manpage-Datenbank aktualisieren.
- Ausschalten, falls erforderlich. Dies ist für meinen Kontrollknoten anders als für die anderen Hosts, da ein seltsames Motherboard keinen ordnungsgemäßen Neustart durchführt.
- Melden Sie sich nach dem Neustart an und führen Sie das Playbook erneut aus. Da sich der Kontrollknoten bereits im gewünschten Zustand befindet, werden keine weiteren Aktionen ausgeführt und Play 2 beginnt.
Spiel 2:Server
- Installieren Sie Updates auf den Firewalls und Servern nacheinander, d. h. einzeln.
- Manpage-Datenbank aktualisieren.
- Neu starten, falls erforderlich.
- Warten Sie gegebenenfalls, bis der erste Host neu gestartet wurde, bevor Sie mit dem nächsten beginnen.
Play 3:Workstations
- Beginnen Sie nicht mit der Aktualisierung von Arbeitsstationen, bis die Server abgeschlossen sind.
- Installieren Sie Updates auf jedem Computer, der gleichzeitig parallel läuft.
- Manpage-Datenbank aktualisieren.
- Neu starten, falls erforderlich.
Ja, ich weiß, dass es andere Möglichkeiten gibt, dies zu tun. Ich habe daran gedacht, den Ansible-Controller zuletzt zu erstellen, damit ich mich nicht mit dem Neustart des Playbooks befassen muss, nachdem der Controller neu gestartet wurde. Aber ich mache die Dinge so, dass ich zuerst Updates auf meiner primären Workstation durchführe – die auch mein Ansible-Steuerknoten ist – und dann einige Tests durchführe, bevor ich den Rest der Systeme aktualisiere, also funktioniert diese Strategie perfekt dafür. Ihre Bedürfnisse werden sich wahrscheinlich von meinen unterscheiden, daher sollten Sie die Methode verwenden, die für Sie am besten geeignet ist. Das Besondere an Ansible ist, dass es flexibel genug ist, um unterschiedlichen Anforderungen gerecht zu werden.
Jetzt, da ich die Anforderungen für eine Aufgabe habe, kann ich mit dem Playbook beginnen.
Syntax
Ansible-Playbooks müssen der standardmäßigen YAML-Syntax und -Formatierung entsprechen. Die häufigsten Fehler, denen ich begegnet bin, waren meine eigenen Formatierungsfehler. Dies liegt normalerweise daran, dass ich führende Bindestriche wie erforderlich verwendet oder nicht verwendet habe oder dass ich die falsche Einrückung verwendet habe.
Die Spielnamen beginnen in Spalte eins des Spielbuchs, und jede folgende Aufgabe wird durch genau zwei Leerzeichen eingerückt . Genau zwei Leerzeichen rücken jede Aktion in einer Aufgabe ein, und Unteraufgaben werden um genau zwei Leerzeichen weiter eingerückt. Jede andere Anzahl von Leerzeichen oder die Verwendung von anderen Leerzeichen als Leerzeichen, wie z. B. Tabulatoren, führt zu einem Laufzeitfehler. Zusätzliche Leerzeichen am Ende einer Zeile erzeugen ebenfalls einen Fehler.
Sie werden Formatierungsfehler machen und schnell lernen, die Probleme zu sehen. Es gibt einige Tools, mit denen ich diese Fehler lokalisieren kann, bevor ich versuche, Playbooks auszuführen, und die auf lange Sicht viel Zeit sparen können.
Playbook starten
Beginnen wir also mit einem Playbook, das diese Aufgaben in der erforderlichen Reihenfolge ausführt. Playbooks sind einfach Sammlungen von Aufgaben die den gewünschten Zustand eines Hosts definieren. Ein Hostname oder eine Inventargruppe wird am Anfang des Playbooks angegeben und definiert die Hosts, auf denen Ansible das Playbook ausführt.
Unser Spielbuch enthält drei Spiele um jeden Hosttyp zu handhaben, den ich in der Anforderungserklärung identifiziert habe. Jedes Spiel hat eine etwas andere Logik, produziert aber das gleiche Ergebnis – ein oder mehrere Hosts mit allen installierten Updates.
Mein Playbook heißt doUpdates.yml und befindet sich im /root/ansible/Updates Verzeichnis, das ich für dieses Projekt erstellt habe. Das von den Plays in diesem Playbook installierte Bash-Programm befindet sich im Verzeichnis /root/ansible/Updates/files Verzeichnis.
Sehen wir uns dieses Playbook Abschnitt für Abschnitt an.
Als YAML-Datei definieren
Ich beginne meinen gesamten Code mit gut strukturierten Kommentaren, damit der Dateiname und eine kurze Beschreibung dieses Playbooks für mich oder einen anderen Systemadministrator in der Zukunft existieren. Playbooks können Kommentare enthalten, obwohl ich nur wenige Artikel oder Bücher gesehen habe, die dies erwähnen.
Als Systemadministrator, der daran glaubt, alles zu dokumentieren, finde ich, dass Kommentare sehr hilfreich sein können. Dabei geht es nicht so sehr darum, in den Kommentaren das Gleiche zu sagen wie im Aufgabennamen, sondern darum, den Zweck von Aufgabengruppen zu erkennen und dafür zu sorgen, dass ich meine Gründe festhalte, bestimmte Dinge auf eine bestimmte Art und Weise zu tun bzw Befehl. Dies kann zu einem späteren Zeitpunkt beim Debuggen von Problemen helfen, wenn ich meinen ursprünglichen Gedanken vergessen haben könnte. Wie in Bash beginnen Kommentare mit einem # .
Die Hauptfunktion dieses ersten Abschnitts sind die drei Bindestriche (--- ), die verwendet werden, um dies als YAML-Datei zu definieren. Die yml Die Erweiterung des Dateinamens steht für YAML. Ich habe ein paar Bedeutungen dafür gesehen, aber ich wette auf „Noch eine andere Auszeichnungssprache“, obwohl ich einige Behauptungen gesehen habe, dass YAML keine ist.
########################################################################
# doUpdates.yml
#------------------------------------------------------------------
# This playbook installs all available RPM updates on the inventory hosts.
#
#
#------------------------------------------------------------------
#
# Change History
# Date Name Version Description
# 2020/10/01 David Both 00.00 Started new code
# 2020/10/10 David Both 01.00 First release code finished
# 2020/10/18 David Both 01.01 Minor changes to sequence and
# fix a couple minor problems.
#
########################################################################
--- Das erste Stück
Dieser nächste Abschnitt definiert das erste Play im Playbook. Playbooks können einen oder mehrere Plays haben, und unseres hat drei:Einen für den Kontrollhost, auf dem Ansible ausgeführt wird, einen für die beiden Server in meinem Netzwerk und einen für die restlichen Workstations. Als Nächstes definiere ich das erste Spiel – schließlich ist dies ein Spielbuch.
Beachten Sie, dass die Wiedergabe in Spalte null beginnt und die verbleibenden Zeilen in der Wiedergabe streng eingerückt werden. Keine Aussage definiert den Beginn des Stücks. Ansible verwendet die starre YAML-Struktur, um zu bestimmen, wo jedes Spiel und jede Aufgabe beginnt.
########################################################################
#######################################################################
# Play 1 - Do updates for host david
########################################################################
########################################################################
- name: Play 1 - Install updates on david - the Ansible controler
hosts: david
remote_user: root
vars:
run: false
reboot: false Wir werden häufig auf verschiedene Schlüsselwörter stoßen, daher sind hier einige Erklärungen, die ich mir wünschte, als ich anfing, mit Ansible zu arbeiten.
Name :Diese Zeile ist der Name des Stücks, und der Name des Stücks wird im STDOUT-Datenstrom angezeigt. Dies macht es einfach, jedes Spiel zu identifizieren, das läuft, um den Überblick zu behalten, während ich den umgeleiteten Stream später anschaue oder ansehe. Das Schlüsselwort ist für jedes Spiel und jede Aufgabe erforderlich, aber der Textinhalt ist optional.
Gastgeber :Dies definiert die Hostnamen, auf denen das Spiel ausgeführt wird. Es kann eine durch Leerzeichen getrennte Liste von Hostnamen oder den Namen einer Gruppe von Hosts enthalten. Die Hostgruppe und die Namen aller aufgelisteten Hosts müssen in der Inventardatei erscheinen. Standardmäßig ist das /etc/ansible/hosts kann aber eine andere Datei sein, solange Sie das -i verwenden (--inventory ) Option, um die alternative Datei anzugeben.
remote_user :Diese Zeile ist nicht erforderlich, gibt aber den Benutzer an, als der Ansible auf dem Remote-Host agiert. Wenn der Benutzer auf dem Remote-Host mit dem Benutzer auf dem Localhost identisch ist, wird diese Zeile nicht benötigt. Standardmäßig verwendet Ansible dieselbe Benutzer-ID auf dem Remote-Host wie der Benutzer, der das Ansible-Playbook ausführt. Ich verwende es hier nur zu Informationszwecken. Ich führe die meisten Playbooks als root auf dem lokalen Host aus, also meldet sich Ansible beim Remote-Host als root an.
vars :Dieser Abschnitt kann verwendet werden, um eine oder mehrere Variablen zu definieren, die wie in jeder Programmiersprache verwendet werden können. In diesem Fall verwende ich sie in bedingten "when"-Anweisungen später im Playbook, um den Ausführungspfad zu steuern.
Der Gültigkeitsbereich von Variablen ist auf den Abschnitt beschränkt, in dem sie definiert sind. In diesem Fall werden sie in Play 1 definiert, also sind sie auf dieses Play beschränkt. Wenn ich sie in späteren Spielen verwenden möchte, muss ich sie in jedem Spiel, in dem sie benötigt werden, erneut einstellen. Wenn eine Variable in einer Aufgabe gesetzt wird, dann sind sie nur innerhalb dieser Aufgabe verfügbar und nicht im Rest dieses Spiels.
Variablenwerte können in der Befehlszeile mit -e überschrieben werden (--extra_variables ) Option, um einen anderen Wert anzugeben. Wir werden das sehen, wenn es an der Zeit ist, das Playbook auszuführen.
Die Aufgaben
Dies ist der Beginn des Aufgabenabschnitts für Play 1. Die Aufgabe :Schlüsselwort wird um genau zwei Leerzeichen eingerückt. Jede Aufgabe muss einen Namen haben Aussage, auch wenn kein Text für den Namen vorhanden ist. Der Text macht es einfacher, der Playbook-Logik zu folgen, und wird während der Ausführung auf dem Bildschirm angezeigt, um mir zu helfen, den Fortschritt in Echtzeit zu verfolgen.
tasks:
########################################################################
# Do some preliminary checking
########################################################################
- name: Install the latest version of the doUpdates script
copy:
src: /root/ansible/Updates/files/doUpdates
dest: /usr/local/bin
mode: 0774
owner: root
group: root
- name: Check for currently available updates
command: doUpdates -c
register: check
- debug: var=check.stdout_lines Dieser erste Abschnitt enthält drei Aufgaben. Die erste Aufgabe kopiert ein von mir geschriebenes Bash-Programm auf den Zielhost. Der zweite führt das gerade installierte Programm aus und weist – registriert – den STDOUT-Datenstrom aus den doUpdates zu Programm auf die Variable "check". Die dritte Aufgabe gibt alle STDOUT-Zeilen in der Prüfvariablen auf dem Bildschirm aus.
Sehen wir uns die neuen Schlüsselwörter etwas genauer an:
kopieren :Das Schlüsselwort copy definiert den Anfang einer Strophe, die eine oder mehrere Dateien von einem angegebenen Quellspeicherort kopieren kann (src ) an einen bestimmten Zielort (dest ). Die Schlüsselwörter in diesem Abschnitt definieren verschiedene Aspekte des Kopiervorgangs und den Endzustand der kopierten Datei.
Quelle :Dies ist der vollständig qualifizierte Pfad und Name der zu kopierenden Datei. In diesem Fall kopiere ich nur eine einzelne Datei, aber es ist einfach, alle Dateien in einem Verzeichnis zu kopieren oder nur diejenigen, die einem Datei-Glob-Muster entsprechen. Die Quelldatei wird normalerweise an einem Ort in der Ansible-Hub-Verzeichnisstruktur gespeichert. In diesem Fall befindet sich der vollständig qualifizierte Pfad zu meiner Quelldatei in /root/ansible/Updates/files/doUpdates .
Ziel :Dies ist der Zielpfad auf dem/den Zielhost(s), in den die Quelldatei kopiert wird.
Modus :Das Schlüsselwort mode definiert den Dateimodus, der auf die kopierte Datei angewendet wird. Unabhängig vom Dateimodus der Quelldatei setzt Ansible den Dateimodus auf den in dieser Anweisung angegebenen. Beispiel:rwxr_xr__ oder 0754 . Stellen Sie sicher, dass Sie alle vier Bytes verwenden, wenn Sie das Oktalformat verwenden.
Eigentümer :Dies ist das Eigentümerkonto, das auf die Datei angewendet wird.
Gruppe :Dies ist das Gruppenkonto, das auf die Datei angewendet wird.
Befehl :Alle Linux-Shell-Befehle, Shell-Skripts oder Befehlszeilenprogramme zusammen mit Optionen und Argumenten können mit diesem Schlüsselwort verwendet werden. Ich habe das gerade installierte Bash-Programm verwendet, um einige Informationen abzurufen, die mit den integrierten Ansible-Ins nicht ohne weiteres erhältlich sind, z. B. dnf .
registrieren :Dieses Schlüsselwort setzt die STDOUT des oben angegebenen Befehls in eine Variable namens "check". Das wann: Schlüsselwort kann den Inhalt dieser Variablen abfragen. Es wird dann als Bedingung verwendet, um zu bestimmen, ob die Aufgabe, von der es ein Teil ist, ausgeführt wird. Wir werden dies im nächsten Abschnitt sehen.
Fehlerbehebung :Gibt den Inhalt der angegebenen Variablen auf dem Bildschirm aus. Ich verwende dies häufig als Debug-Tool. Ich finde das hilfreich beim Debuggen. Hinweis, Hinweis.
Jetzt ein wenig über meine doUpdates Bash-Programm.
Ich habe dieses Bash-Programm ursprünglich geschrieben, um die Aktualisierungen durchzuführen, mit denen ich jetzt mit Ansible begonnen habe. Es enthält Code, der bestimmt, ob Updates verfügbar sind. Es bestimmt auch, ob der Kernel, systemd oder glibc aktualisiert wurden, von denen jeder einen Neustart erfordern sollte, um vollständig wirksam zu werden. Mein Programm gibt ein paar Zeilen an STDOUT aus, die ich in Ansible als Bedingung verwenden kann, um zu entscheiden, ob der Zielhost neu gestartet werden soll. Ich verwende das in diesem nächsten Abschnitt, der die eigentlichen Updates durchführt, und der folgende führt ein Ausschalten für meine primäre Workstation durch. Ein ähnlicher Code führt einen Neustart auf allen anderen Hosts durch, wie Sie sehen werden.
Das STDOUT dieses Programms wird mit -c verwendet Option sieht so aus, wenn Updates verfügbar sind, aber kein Neustart erforderlich ist. Ich kann einen regulären Ausdruck verwenden, um jeden Text in diesem Datenstrom nach Schlüsselzeichenfolgen zu durchsuchen, die in einem when verwendet werden können :Bedingt, um festzustellen, ob eine bestimmte Aufgabe ausgeführt wird.
TASK [debug] ******************************************************************************************************************************************
ok: [wally1] => {
"check.stdout_lines": [
"########## 48 updates ARE available for host wally1.both.org. ##########",
"########## Including: ##########",
"Last metadata expiration check: 1:47:12 ago on Tue 20 Oct 2020 01:50:07 PM EDT.",
"Updates Information Summary: available",
" 3 Security notice(s)",
" 2 Moderate Security notice(s)",
" 3 Bugfix notice(s)",
" 2 Enhancement notice(s)",
" 2 other notice(s)",
"########## A reboot will NOT be required after these updates are installed. ##########",
"Program terminated normally"
]
}
Dieser nächste Abschnitt unmittelbar darüber führt die eigentlichen Aktualisierungen durch, wenn alle Bedingungen in when enthalten sind :Aussage ist wahr. Dieser Abschnitt verwendet das integrierte Ansible dnf Paketmanager.
########################################################################
# Do the updates.
########################################################################
# Install all available updates
- name: Install all current updates
dnf:
name: "*"
state: latest
when: (check.stdout | regex_search('updates ARE available')) and run == "true"
dnf :Ruft das integrierte Ansible auf, das mit dem DNF-Paketmanager verbunden ist. Obwohl es in seinen Fähigkeiten etwas eingeschränkt ist, kann es Pakete installieren, entfernen und aktualisieren. Eine der Einschränkungen des DNF-Moduls besteht darin, dass es kein check-update hat Funktion. Daher verwende ich weiterhin mein Bash-Programm, um die Liste der zu aktualisierenden Pakete zu ermitteln und daraus zu bestimmen, ob ein Neustart (oder Ausschalten) durchgeführt werden muss. Ansible hat auch eingebaute YUM- und APT-Ins.
Name :Gibt den Namen des Pakets an, auf dem gearbeitet werden soll. In diesem Fall das Datei-Glob-Zeichen * bezeichnet alle installierten Pakete.
Zustand :Der Wert „latest“ für dieses Schlüsselwort gibt an, dass alle installierten Pakete auf die neueste Version gebracht werden sollen. Einige der anderen Statusoptionen sind „vorhanden“, was bedeutet, dass das Paket installiert ist, aber nicht unbedingt die neueste Version, und „abwesend“, was bedeutet, dass das Paket entfernt werden soll, wenn es installiert ist.
wann :Dieser Bedingungssatz gibt die Bedingungen an, die erfüllt sein müssen, damit diese Aufgabe ausgeführt wird. In diesem Fall werden die Updates nur installiert, wenn die im regulären Ausdruck definierte Textzeichenfolge in der zuvor registrierten Variablen „check“ vorhanden ist und die Variable „run“ auf „true“ gesetzt ist.
Jetzt, da die Updates durchgeführt wurden, muss ich möglicherweise neu starten, also mal sehen, wie ich damit umgehen kann. Die nächste Aufgabe erledigt das für uns.
Zunächst habe ich eine kleine Dokumentation über Kommentare, die beschreibt, dass ich diesen Host aufgrund eines potenziellen Hardwareproblems ausgeschaltet und nicht neu gestartet habe. Dies ist ein perfektes Beispiel dafür, warum wir Kommentare in unseren Code und unsere Playbooks aufnehmen sollten, weil sie erklären, warum dieses spezielle Spiel benötigt wird und warum es sich von den anderen unterscheidet. Es ist auch ein großartiges Beispiel dafür, wie ich einen Host anders behandeln kann als andere.
########################################################################
# Now poweroff host david because of MB problems that won't let it
# do a reboot without manual intervention. Need to see if I
# can figure out this problem and fix it but it is a hardware issue
# and this is just a temporary circumvention.
########################################################################
- name: Poweroff this host if necessary and reboot extra variable is true
command: poweroff
when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true"
In dieser Aufgabe sende ich den poweroff statt der bevorzugten Aktion des Neustarts des Computers. Ich tue dies aus dem in den Kommentaren angegebenen Grund:Weil das Motherboard auf meiner primären Workstation – die auch mein Ansible-Hub ist – nicht ordnungsgemäß neu gestartet wird. Dies liegt wahrscheinlich eher an einer Fehlkonfiguration meinerseits als an irgendeiner Art von Fehlfunktion. Ich habe den Grund dafür noch nicht entdeckt, weil ich finde, dass die Zeit, die ich bereits mit Suchen und BIOS-Konfigurationsänderungen verbracht habe, meine Toleranzgrenze überschritten hat und ich die Arbeit erledigen muss. Hin und wieder arbeite ich ein bisschen mehr daran, aber es ist die zusätzliche Zeit nicht mehr wert.
Die Ausführung des Playbooks stoppt nach dem Ausschalten (oder Neustart, wenn Ihr Ansible-Hub-Gerät ordnungsgemäß neu gestartet wird), sodass ich es neu starten muss, nachdem es schließlich wieder betriebsbereit ist. Da die Updates dieses Mal installiert wurden, erfolgt kein Ausschalten oder Neustart, und die nächste Wiedergabe wird ausgeführt.
Und damit endet das erste Stück.
[ Brauchen Sie mehr zu Ansible? Nehmen Sie an einem kostenlosen technischen Überblickskurs von Red Hat teil. Ansible Essentials:Einfachheit in der Automatisierung Technischer Überblick. ]
Abschluss
Wir haben hier viele Informationen abgedeckt und ich hoffe, dass eine solide Erklärung der Schlüsselwörter und Aufgaben hilfreich war. Klar ist auch, was ich von Kommentaren halte:Sie sind kritisch. Play 1 bringt unser Ansible-Playbook ins Rollen.
Im zweiten Teil dieses Artikels schließen wir das Playbook mit zwei zusätzlichen Spielen ab, um die Firewall und die Server und dann den Rest der Hosts im Netzwerk zu verwalten. Ich werde auch einige Folgedetails und Konzepte bereitstellen.