Module Ansible Tutorial Teil 4

Die Module von Ansible habe ich schon mehrfach erwähnt, es ist Zeit, sie näher zu erklären.

Ansible Module  Logo (Quelle: Von Ansible/Red Hat – Wikipedia)
Ansible Logo (Quelle: Von Ansible/Red Hat – Wikipedia)
1Einführung
2Das Inventory
3Über Rollen und Tasks
4Die Module
5Playbooks
6Konfiguration
7gather_facts
8eigene Module

Module

Ein Modul stellt einfach gedacht, einen Arbeitsschritt dar, der auf dem Managed Node in einem Task ausgeführt werden soll.

Ansible liefert bei der Installation schon eine Menge Module mit, die in der ansible.builtin Collection organisiert sind. Du kannst über das ansible-galaxy Kommando auch noch zusätzliche benötigte Collections nachinstallieren. Allein mit Hilfe der builtin Module kannst du umfangreiche Playbooks erstellen, die dir die Administration der Managed Nodes stark vereinfachen.

Jedes Modul repräsentiert genau eine dedizierte Aufgabe. Üblicherweise nimmt es dafür eine ganze Menge an Parametern entgegen.

Ich kann in diesem Post unmöglich alle verfügbaren Module in allen Collections erklären, da diese Auflistung sehr dynamisch ist. Deshalb verweise ich dich auf diese Liste.

Ich stelle dir einfach exemplarisch ein paar vor, die ich häufig benutze

Arbeitsweise

Die Module liegen auf dem Control Node und werden per ssh auf jeden Managed Node hochgeladen und dort mit Python ausgeführt. Das Modul meldet dann zurück, ob es erfolgreich ausgeführt wurde „OK“, bei der Arbeit eine Änderung durchgeführt wurde „CHANGED“, ein Fehler wird mit „FAILURE“ gemeldet. Wurde das Modul aufgrund einer bestimmten Bedingung übersprungen, resultiert dies in einem „SKIPPED“.

Während Ansible ein Playbook abarbeitet werden per Default zwei parallele Verbindungen zu zwei verschiedenen Managed Nodes aufgebaut, wie du diesen Wert erhöhen kannst, zeige ich die später.

apt

Das apt Module ist das Pendant zum Kommandozeilen Kommando apt, das du schon zur Installation neuer Packages in Debian o.ä. kennst. Mit Hilfe dieses Moduls lassen sich ganze Raspberry Pi Farmen hervorragend auf einmal aktualisieren.

Im letzten Teil hatte ich dir das apt Modul schon mal kurz angespoilert. Ich zeige die das jetzt mal im Detail, was in dem Task steht.

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

Jeder Task wird mit einer Zeile - name: <name> eingeleitet. Der Name des Tasks kann von dir frei gewählt werden. Ich gebe dir aber nochmal den Tipp, da etwas aussagekräftiges einzutragen.

Die Zeile become: true konfiguriert für den gesamten Task, dass der Task im root Kontext laufen soll. Auf der Kommandozeile machst du das mit sudo.

In der Zeile darunter wird mit apt: festgelegt, welches Modul von diesem Task benutzt wird.

Die folgen vier eingerückten Zeilen stellen die Parameter dar, die dem apt Modul übergeben werden. Der Upgrade Modus ist dist , Der Cache soll aktualisiert werden, sofern dies in den letzten 120 Sekunden nicht geschehen ist (update_cache: yes und cache_valid_time: 120). Diesen Wert kannst du nach eigenem Belieben einstellen.

Dieser Ansible Task ist identisch mit dem Kommandozeilenaufruf

sudo apt update && sudo apt dist-upgrade

Wenn du dir überlegst, dass du dich sonst in jeden Raspberry Pi mit ssh einloggen musst um dann da den Upgrade Prozess zu starten, kannst du das mit diesem Task und dem apt Modul mit einem einzigen Kommando erledigen. Mit apt kannst du natürlich auch Pakete installieren oder entfernen.

Im nächsten Teil zeige ich dir, wie du den Task in einem Playbook verwendest und was passiert, wenn Ansible dieses ausführt.

file

Das file Modul kann eine ganze Reihe von Dateioperationen erledigen. Da unter Linux alles eine Datei ist, kannst du hiermit auch Directories bearbeiten.

Um bspw. ein bin Verzeichnis im eigenen /home anzulegen dient dieser Task

- name: create bin dir
  file:
    path: ~/bin
    state: directory
    mode: '0754'

Als Parameter übergibst du dem Modul lediglich den Namen der Datei ~/bin und den Status directory. Falls noch kein Verzeichnis dieses Namens existieren sollte, wird der Task es anlegen. Auch die Zugriffsrechte kannst du direkt mit angeben. Entweder in oktaler Schreibweise 0754 oder in lesbarer Form wie „u+rwx,g+rx,o+r

User

Alles, was du zur Manipulation der Userliste auf dem Managed Node benötigst, bietet dir das user Modul

- name: adding user pi to docker group
  become: true
  user:
    name: pi
    groups: docker

Dieser Task fügt den User pi der Gruppe docker dazu. Dies kann natürlich nur der Root User machen, daher steht become: true im Task. Du kannst hier auch mehrere Gruppen kommasepariert angeben.

Copy

Mit dem copy Modul kannst du eine Kopie einer Datei anlegen.

- name: backup keys file
  become: false
  ansible.builtin.copy:
    src: /home/pi/.ssh/authorized_keys
    dest: /home/pi/.ssh/authorized_keys.bak
    remote_src: yes
    owner: pi
    group: pi
    mode: '0644'

Du siehst hier eine etwas andere Schreibweise für den Modulnamen. Da auch in anderen Collections ein Modul mit diesem Namen enthalten sein könnte, gebe ich den Namen hier vollqualifiziert mit Collection an und vermeide so Missverständnisse.

Zum Abschluss

Ich kann unmöglich alle Module hier mit Beispiel vorstellen. Meiner Meinung nach sind die bei Ansible selbst sehr gut dokumentiert. Im nächsten Teil wird es etwas praktischer, wenn wir das erste Playbook schreiben und ausführen.

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