Ansible subtasks Tutorial Teil 9

Ansible Logo (Quelle: Von Ansible/Red Hat – Wikipedia) subtasks
Ansible Logo (Quelle: Von Ansible/Red Hat – Wikipedia)

Ansible subtasks helfen uns, eine Ansible Rolle besser zu strukturieren und lesbarer zu machen.

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

Ansible subtasks

Bisher haben wir alle Abläufe für ein Playbook in eine einzige Datei, der main.yml hineingeschrieben. Das ist bis zu einem gewissen Umfang auch völlig in Ordnung. Aber spätestens ab 10 oder mehr Tasks mit ihren Parametern, wird diese Datei sehr lang und schlecht wartbar. Daher macht es Sinn, die große Gesamtdateien in einzelne Unteraufgaben (subtasks) zu zerlegen.

Beispiel: log2ram

In Teil 5 haben wir ein Playbook zur Installation von log2ram auf dem Raspberry Pi geschrieben. Das ist zwar nicht riesig komplex, eignet sich aber als Beispiel für das, was wir vorhaben:

Zur Erinnerung: Die roles/log2ram/tasks/main.yml sieht so aus:

- name: PI Update
  become: true
  apt:
    update_cache: yes
    upgrade: dist
- name: Key
  become: true
  apt_key:
    url: https://azlux.fr/repo.gpg.key
    state: present
- name: Paketquelle
  become: true
  apt_repository:
    repo:  'deb http://packages.azlux.fr/debian/ bookworm main'
    state: present
    filename: log2ram
    update_cache: yes
- name: log2ram installieren
  become: true
  apt:
    update_cache: yes
    name:
    - log2ram
- name: Neustart
  become: true
  reboot:

In der main.yml sind alle fünf Tasks untereinander geschrieben. Ähnlich dem import von Python können wir subtasks einfach mit dem include Task in die main.yml einbinden. Zunächst zerlegen wir die obige Datei in ihre einleben Tasks und legen sie unter roles/log2ram-st/tasks als subtasks an:

upgrade.yml

--- 
- name: PI Update
  become: true
  apt:
    update_cache: yes
    upgrade: dist

add_repo_key.yml

---
- name: Key
  become: true
  apt_key:
    url: https://azlux.fr/repo.gpg.key
    state: present

add_repo_source.yml

---
- name: Paketquelle
  become: true
  apt_repository:
    repo:  'deb http://packages.azlux.fr/debian/ bookworm main'
    state: present
    filename: log2ram
    update_cache: yes

install_log2ram.yml

---
- name: log2ram installieren
  become: true
  apt:
    update_cache: yes
    name:
    - log2ram

reboot.yml

--- 
- name: Neustart
  become: true
  reboot:

Wir haben jetzt die main.yml in die fünf atomaren subtasks zerlegt, von denen jeder nur eine einzige Aufgabe übernimmt.

Als nächstes ändern wir die main.yml wie folgt ab:

 - include: upgrade.yml
 - include: add_repo_key.yml
 - include: add_repo_source.yml
 - include: install_log2ram.yml
 - include: reboot.yml

Da die main.yml nur eine Abfolge von Tasks ist, können wir mit dem - include: Task einfach unsere Ansible subtasks in der Reihe einbinden, in der sie abarbeitet werden.

gemeinsame subtasks

subtasks sind meist so atomar, dass du sie für mehrere Rollen verwenden kannst, daher macht es Sinn, sie so abzulegen, dass jede Rolle darauf zugreifen kann.

Unter roles erzeuge ich ein Verzeichnis, um dort die subtasks abzulegen.

mkdir roles/subtasks

Da hinter dem -include: Task ein Dateiname steht, kann dort auch ein kompletter Verzeichnisname eingebaut werden. Zunächst verschiebe ich die subtasks roboot.yml und upgrade.yml in das eben angelegte Verzeichnis:

mv roles/log2ram-st/tasks/reboot.yml roles/subtasks
mv roles/log2ram-st/tasks/upgrade.yml roles/subtasks

Um diese jetzt zu referenzieren, schreiben wir unsere main.yml etwas um:

-  include: ../subtasks/upgrade.yml
 - include: add_repo_key.yml
 - include: add_repo_source.yml
 - include: install_log2ram.yml
 - include: ../subtasks/reboot.yml

Auf diese Weise kannst du die subtasks in jeder Rolle benutzen und der Wartungsaufwand beschränkt sich meist nur auf den subtask.

deprecated

Beim Test der subtasks mit Ansible Version 2.14.3 auf meinem Debian Rechner – gegenüber der Version 2.10.8 unter DietPi , erhielt ich die Warnung, dass der - include: Task jetzt einen deprecated Status besitzt und daher langfristig nicht mehr unterstützt wird. Als Ersatz bietet sich -include_tasks: an. Da wir zukunftsorientiert bleiben wollen, hab ich die main.yml nochmal angepasst:

---

- include_tasks: "../subtasks/upgrade.yml"
- include_tasks: ../subtasks/upgrade.yml
- include_tasks: add_repo_key.yml
- include_tasks: add_repo_source.yml
- include_tasks: install_log2ram.yml
- include_tasks: ../subtasks/reboot.yml

Jetzt kommt der Moment, unser Playbook mit Ansible subtasks gegen einen Raspberry Pi laufen zu lassen:

Ablauf des Playbooks, für die subtasks wird eine Meldung „included“ angezeigt.

Fazit

Einer der großen Vorteile der subtasks liegt darin, einen subtask in beliebig vielen Rollen benutzen zu können, ohne das Rad jedes mal zu erfinden zu müssen. Der andere Vorteil ergibt sich dadurch, das mehrere Teammitglieder gleichzeitig an verschiedenen subtasks arbeiten können, ohne sich dabei ins Gehege zu kommen.

Wie immer sind alle Beispieldateien im GIT abrufbar.

Schreibe einen Kommentar

Creative Commons License
Except where otherwise noted, the content on this site is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Olli Graf - raspithek.de
WordPress Cookie Hinweis von Real Cookie Banner