Playbooks Ansible Tutorial Teil 5

Mit den Playbooks werden wir heute nach so viel Theorie mal was praktisches bauen.

1	Einführung
2	Das Inventory
3	Über Rollen und Tasks
4	Die Module
5	Playbooks
6	Konfiguration
7	gather_facts
8	eigene Module

Playbooks

Playbooks sind bildlich gesprochen ein Drehbuch, dass definiert, in welchem festgelegt wird, welche Rollen und Aufgaben in einer bestimmten Reihenfolge abgearbeitet werden.

Ein Playbook wird in einer YAML Datei beschrieben. und liegen im Hauptverzeichnisses deines Ansible Projekts. In diesem Tutorialteil will ich dir zeigen, wie du ein Playbook zum Upgrade deiner Raspberry Pis erstellst. Dieses Playbook hat für mich die Wartungsarbeiten meiner Raspis enorm vereinfacht.

Zur Erinnerung nochmal der Task in der Rolle upgrade :

roles/upgrade/tasks/main.yml

- name: PIs aktualisieren
  become: true
  apt:
    upgrade: dist
    update_cache: yes
    cache_valid_time: 120
    autoremove: yes

Der Task definiert nur, was getan werden muss. Unser Playbook definiert die wer und wo es in welcher Reihenfolge tut.

Hier das Playbook

upgradepi.yml

- hosts: "{{ target }}"
  gather_facts: false
  remote_user: pi
  roles:
    - upgrade

Die erste Zeile gibt mit -hosts: "{{target}}" das wer an. Wie target gesetzt wird, siehst du gleich noch. Die Schreibweise mit den doppelten geschweiften Klammern kommt dir vielleicht aus dem Python Tutorial zu Flask bekannt vor. Sie sagt einfach, dass das zwischen den Klammern eine Variable ist, die mit einem konkreten Wert ersetzt werden soll. Das Target ist hier der Managed Node, auf dem das Playbook abgearbeitet werden soll.

Die zweite Zeile gather_facts: false schaltet das Sammeln von Systeminformationen auf dem Managed Node ab. Da dies nicht immer notwendig ist, spare ich mir die Ausführzeit dafür und mache das Playbook etwas schneller. Falls du aber Aufgaben abhängig vom OS auf dem Managed Node ausführen willst, muss dieser Wert auf true stehen. Was gather_facts genau tut, erkläre ich später noch.

Die dritte Zeile gibt mit remote_user: pi an, unter welchen User auf dem Managed Node gearbeitet werden soll und im Task wird dann mittels become: true in den Superuser Modus umgeschaltet.

Danach folgt eine Liste von roles:, die dieses Playbook abarbeiten soll. Da wir hier nur eine Rolle – upgrade haben, ist die Liste ziemlich kurz, weitere Rollen kannst du einfach mit einem einleitenden „-“ einfach zeilenweise darunter schreiben.

Jetzt ist der Zeitpunkt gekommen, das Playbook auszuführen.

ansible-playbook

ansible-playbook -i inventory.yml -e="target=stack4" upgradepi.yml

ansible-playbook ist das Kommando, das Playbooks abarbeitet und hier siehst du auch, wie die target Variable ihren Wert bekommt. Dieser wird einfach dem Kommando als Parameter übergeben. Hier kann der Name eines Managed Nodes stehen (oder mehrere durch Kommata getrennt) oder wie in diesem Fall der Name einer Gruppe. All das muss in der inventory.yml definiert sein. Den Dateinamen des Inventory immer mit angeben zu müssen, ist natürlich lästig. Wie du das vermeiden kannst, erkläre ich dir im Kapitel Konfiguration.

Ich habe hier mal auf die gesamte stack4 Group das upgradepi.yml Playbook laufen lassen und erhalte folgendes Ergebnis:

Olli Graf -raspithek.de

playbook-upgrade-run

Beim Abarbeiten des Playbooks baut Ansible eine ssh Verbindung zu jedem Managed Node auf, kopiert das Modul dorthin und führt es aus. Genau genommen baut Ansible defaultmäßig vier parallele Verbindungen zu vier verschiedenen Nodes auf. Ich kann nach Start des Playbooks bei allen vier Raspis Aktivität auf der MicroSD Karte sehen.

Während das Playbook läuft, wird dir angezeigt, auf welchen Managed Nodes eine Änderung durch den Task erfolgte (grün= keine Änderung, orange= Upgrade hat Pakete aktualisiert). In der Zusammenfassung erkennst du, dass quimby schon auf dem aktuellen Stand war und bei den anderen drei Nodes die neusten Paket Updates eingespielt wurden. Es kann durchaus vorkommen, dass ein Node auf unreachable geht und rot ausgewiesen wird. Das passiert mir relativ häufig, da nicht alle Raspis ständig in Betrieb sind.

weiteres Beispiel

Hier noch ein weiteres Beispiel aus meinem Ansible Fundus. Das Task dient dazu, einen Datenträger meines NAS auf allen Raspis per NFS zu mounten. Vorher wird auch noch der Mountpoint angelegt

roles/mountback/task/main.yml

- name: create mountpoint
  become: true
  file:
    path: /mnt/backup
    state: directory
- name: fstab updaten
  become: true
  lineinfile:
    line: 192.168.178.36:/mnt/md1/backup /mnt/backup   nfs  defaults,user,rw 1000 1000
    path: /etc/fstab
- name: mount /mnt/backup
  become: true
  mount:
    path: /mnt/backup
    src: 192.168.178.36:/mnt/md1/backup
    fstype: nfs
    state: mounted

Hier sind drei Tasks definiert. Der erste legt das Verzeichnis für den Mountpoint an. Der zweite trägt eine Zeile für das Laufwerk in /etc/fstab ein, damit auch nach einem Neustart das Laufwerk verfügbar ist. Der dritte mountet das Laufwerk.

Das Playbook dazu ist sehr simpel gehalten:

mountbackup.yml

- hosts: "{{ target }}"
  gather_facts: false
  remote_user: pi
  roles:
    - mountbackup

Im Repository habe ich dir noch ein Playbook abgelegt, das Log2Ram installiert. Hinweis: das ist bereits für Debian 12 ausgelegt.

Praxistipp

Wenn du eigene Playbooks schreibst, solltest du sie zunächst an einem Managed Node gut testen, bevor du es auf eine ganze Gruppe los lässt. Gerade bei Modulen mit sicherheitskritischen Aufgaben, könnte es passieren, dass du dich selbst aus deinem Raspberry Pi aussperrst.

Im nächsten Tutorialteil geht es dann um den Konfigurationsmechanismus von Ansible.