Ich habe mich entschieden, meinen Update-Prozess für Kundensysteme, die ich unterstütze, sowie für meine eigenen Linux-Geräte zu rationalisieren. Während mir eine Reihe komplexer Skripte lange Zeit gute Dienste geleistet haben, sind die Vorteile der Verwendung von Ansible für diese Aufgabe einfach zu zahlreich, um sie sich entgehen zu lassen.
In Teil eins dieser Artikelserie habe ich den eigentlichen Update-Prozess besprochen, die Struktur meines Playbooks festgelegt und Schlagworte und Kommentare präsentiert. Das Playbook enthält drei Stücke. Jedes Spiel verwaltet eine Kategorie von Systemen. Play 1 verwaltet mein Ansible Controller-Gerät (meine primäre Workstation), während Play 2 und 3 Server und alle verbleibenden Workstations verwalten.
Beginnen wir diesen zweiten Artikel mit der Untersuchung des zweiten Stücks.
Das zweite Stück
Hier ist das gesamte zweite Stück. Der Zweck dieses Spiels ist es, Updates auf der Firewall und dem Server durchzuführen.
Die Firewall muss betriebsbereit sein, während die Server – und alle anderen Hosts – aktualisiert werden, damit sie Zugriff auf das Internet haben, um die Aktualisierungspakete herunterzuladen. Der Server muss laufen, während die Firewall und andere Hosts aktualisiert werden, um DHCP- und Namensdienste bereitzustellen. Um dies zu erreichen, aktualisiert dieses Spiel diese beiden Hosts nacheinander.
Die Namen für diese beiden Hosts sind in [all_servers] enthalten Gruppe in /etc/ansible/hosts Bestandsdatei.
#######################################################################
#######################################################################
# Play 2 - Do servers
#######################################################################
#######################################################################
- name: Play 2 - Install updates for servers yorktown and wally
hosts: all_servers
serial: 1
remote_user: root
vars:
run: false
reboot: false
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
#######################################################################
# 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"
- name: Update the man database
command: mandb
when: run
- name: Reboot if necessary and reboot extra variable is true
reboot:
when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true" [ Das könnte Ihnen auch gefallen:Eine Einführung in Ansible Tower ]
Dieses gesamte zweite Spiel ist fast dasselbe wie das erste, mit Ausnahme von zwei Zeilen.
seriell :Diese zusätzliche Anweisung weist Ansible an, dieses Stück auf jeweils einem Host auszuführen, d. h. seriell und nicht parallel. Wenn die all_servers Gruppe im Inventar zehn Server enthielt, könnte ich ein höheres Limit verwenden, z. B. zwei, sodass dieses Spiel gegen zwei Server gleichzeitig ausgeführt würde. In diesem Fall brauche ich wally , die Firewall, betriebsbereit sein, damit yorktown Der Server hat Zugriff auf das Internet, um die aktualisierten Pakete herunterzuladen. Es spielt keine Rolle, in welcher Reihenfolge diese beiden Hosts aktualisiert werden, solange sie nicht beide gleichzeitig ausgeführt werden.
Neustart :Ansible hat eine eingebaute Neustartfunktion, sodass wir diese in diesem Stück anstelle des Linux-Poweroff-Befehls verwenden können. Das entscheidende Merkmal der Ansible-Neustartfunktion ist, dass sie überprüft, ob der Neustart erfolgreich war, der Remote-Host betriebsbereit ist und die SSH-Kommunikation wieder funktioniert. Das Standard-Timeout dafür beträgt 10 Minuten, danach gibt Ansible einen Fehler aus.
Das dritte Stück
Und hier ist das dritte Stück. Dieses Spiel aktualisiert alle verbleibenden Hosts in meinem Netzwerk. Die Namen für diese Hosts sind in [workstations] enthalten Gruppe der /etc/ansible/hosts Bestandsdatei.
#######################################################################
#######################################################################
# Play 3 - Do all workstations except david
#######################################################################
#######################################################################
- name: Play 3 - Install updates for all workstations except david
hosts: workstations
strategy: free
remote_user: root
vars:
run: false
reboot: false
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
#######################################################################
# 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"
- name: Reboot if necessary and reboot extra variable is true
reboot:
when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true" Es gibt nur eine Änderung in diesem Playbook außer der Liste der Hosts.
Strategie :Die freie Die Strategie weist Ansible an, die Aufgaben in diesem Stück frei auszuführen. Die Aufgaben in diesem Spiel werden auf jedem Host so schnell ausgeführt, wie der Host sie erledigen kann. Dies bedeutet, dass einige Hosts die letzte Aufgabe möglicherweise weit vor anderen, langsameren Hosts auch nur mit der ersten Aufgabe im Playbook abgeschlossen haben. Wenn Sie den STDOUT-Datenstrom lesen, kann es so aussehen, als wäre es ein Alleskönner.
Jede Strategie ist ein separates Plugin, und es gibt ein paar andere Plugins, die mit diesem Schlüsselwort verwendet werden können. Der Standardwert ist linear , die jede Aufgabe auf allen Hosts ausführt, bevor sie mit der nächsten Aufgabe fortfährt. Der host_pinned Plugin führt alle Aufgaben im Spiel auf jedem Host aus, bevor es zum nächsten Host weitergeht. Die Fehlerbehebung Plugin führt Aufgaben interaktiv aus, damit das Spiel debuggt werden kann.
Playbook ausführen
Ich führe dieses Playbook mit dem folgenden Befehl aus:
# ansible-playbook -e "run=true reboot=true" doUpdates.yml
Das -e Option steht für "zusätzliche Variablen". Hier gibt es Werte für die beiden Variablen an, die in jedem Spiel definiert sind. Setzen Sie in diesem Fall beide auf true ermöglicht die Durchführung der Updates und den Neustart (Poweroff), falls erforderlich.
Ich werde STDOUT nicht reproduzieren Datenstrom hier, weil er ziemlich lang ist.
Abschließende Gedanken
Mit ein paar Änderungen, um die Details Ihres Netzwerks widerzuspiegeln, kann dieses Playbook verwendet werden, um Ihre Aktualisierungsaufgaben zu automatisieren. Das Durchführen von Updates mit einem ähnlichen Playbook wie meinem ist ein guter Einstieg in die Verwendung von Ansible. Obwohl es mehrere Schlüsselwörter verwendet, die komplexe Aufgaben ausführen können, ist dies ein relativ einfaches Playbook. Ich begann mit nur dem ersten Spiel, um meine persönliche Workstation zu aktualisieren, und der Rest bestand hauptsächlich aus Kopieren und Einfügen, mit ein paar geringfügigen Änderungen, um den Bedürfnissen der verschiedenen Gruppen von Hosts gerecht zu werden.
Ja, es gibt andere Möglichkeiten, dies zu tun. Ich hätte wahrscheinlich andere Aufgaben mit Bedingungen innerhalb von ein oder zwei Spielen anstelle von drei Spielen verwenden können. Oder ich hätte Bedingungen und Blöcke verwenden können, um mit bestimmten Hosts anders umzugehen. Ich persönlich denke, dass einzelne Spiele dazu beitragen, die Logik so weit zu trennen, dass die Änderung der Aufgabenbehandlung in einem Spiel die anderen nicht beeinflusst. Meiner Meinung nach ist diese Trennung auch eleganter, da die Gesamtlogik einfacher zu schreiben, zu verstehen und einfacher zu verwalten ist.
[ Ein kostenloser Leitfaden von Red Hat:5 Schritte zur Automatisierung Ihres Unternehmens. ]
Ressourcen
Das vollständigste und nützlichste Dokument, das ich gefunden habe, ist das Ansible-Benutzerhandbuch auf der Ansible-Website. Dieses Dokument ist als Referenz und nicht als Anleitung oder Dokument für erste Schritte gedacht.
Opensource.com hat im Laufe der Jahre viele Artikel über Ansible veröffentlicht, und ich fand die meisten davon sehr hilfreich für meine Bedürfnisse. Die Red Hat Enable Sysadmin-Website enthält auch viele Ansible-Artikel, die ich als nützlich empfinde.
Es gibt auch einige gute, aber knappe Handbuchseiten.