39 Technischer Hintergrund zu Collections, Modulen und Plugins

39.1 Aufbau und Installation von Ansible Collections

Ansible Collections bestehen aus einer definierten Verzeichnisstruktur mit entpackten Python-Dateien und Metadaten. Eine Collection wird mit ansible-galaxy collection install heruntergeladen und lokal unter ~/.ansible/collections/ansible_collections/<namespace>/<collection> entpackt abgelegt. Alternativ kann auch /usr/share/ansible/collections/ansible_collections verwendet werden.

39.1.1 Verzeichnisstruktur von Collections

Die Struktur folgt dabei festen Konventionen:

• plugins/: Unterverzeichnisse wie modules/, filter/, lookup/, callback/ usw. enthalten Python-Plugins
• roles/: Enthält Rollen, falls vorhanden
• docs/, tests/, meta/, playbooks/: optionale Bestandteile
• galaxy.yml: Beschreibt Metadaten, Abhängigkeiten, Name und Version der Collection

Die Module und Plugins innerhalb einer Collection sind direkt lauffähige, entpackte Python-Dateien. Es handelt sich nicht um komprimierte oder byte-compilierte Artefakte. Die Struktur ist so ausgelegt, dass Module und Plugins versionierbar, testbar und unabhängig vom Ansible-Core sind.

39.2 Dynamische Pfadauflösung zur Laufzeit

Ansible verwendet eine dynamische Pfadauflösung zur Laufzeit. Collections werden aus Verzeichnissen geladen, die entweder den Standardpfaden entsprechen oder explizit über Konfiguration bekannt gemacht werden:

• Die Umgebungsvariable ANSIBLE_COLLECTIONS_PATHS kann zusätzliche Pfade angeben (doppelpunktsepariert)
• Alternativ kann derselbe Pfad in der ansible.cfg unter [defaults] → collections_paths konfiguriert werden

Sobald eine Collection eingebunden ist, erfolgt der Zugriff auf enthaltene Module und Plugins über die Namenskonvention namespace.collection.modulename. Intern wird ein Importpfad wie ansible_collections.<namespace>.<collection>.plugins.modules.<modulename> generiert. Die Importmechanismen basieren auf regulärem Python-Import, ergänzt um spezielle Plugin Loader, die im Ansible-Core über ansible.plugins.loader registriert sind.

39.2.1 Projektlokale Collections

Eigene Collections können projektlokal eingebunden werden. Dazu muss die Collection-Hierarchie im Projekt korrekt aufgebaut sein, etwa unter collections/ansible_collections/<namespace>/<collection>/. Die Pfadangabe in collections_paths muss dann auf das Verzeichnis collections zeigen. Wichtig ist die vollständige Einhaltung des Namespace-Konzepts, da andernfalls die Pfadauflösung fehlschlägt.

39.3 Entwicklung eigener Module

Ein eigenes Ansible-Modul ist ein ausführbares Python-Skript, das als Subprozess von Ansible gestartet wird. Der Standardmechanismus basiert auf der Hilfsklasse AnsibleModule, die aus ansible.module_utils.basic importiert wird. Ein Modul benötigt keine bestimmte Funktion oder Klassensignatur, sondern verarbeitet über stdin übergebene JSON-Daten und gibt über stdout ebenfalls JSON zurück.

39.3.1 Typischer Aufbau eines Moduls

• Import von AnsibleModule
• Definition eines Argument-Schemas
• Instanzierung von AnsibleModule
• Zugriff auf Parameter über module.params
• Rückgabe über module.exit_json() oder module.fail_json()

39.4 Plugin-Entwicklung und -Typen

Plugins hingegen werden direkt importiert und müssen daher eine klare Python-API bereitstellen. Je nach Plugintyp gelten folgende Vorgaben:

• Lookup-Plugins: Klasse, die von LookupBase erbt, mit Methode run(...)
• Filter-Plugins: einfache Funktionen, die über FilterModule().filters() als Dictionary registriert werden
• Callback-Plugins: Klasse, die von CallbackBase erbt und Ereignismethoden implementiert

Im Unterschied zu Modulen werden Plugins nicht als Subprozess ausgeführt, sondern innerhalb des Ansible-Prozesses geladen und verwendet. Dadurch benötigen sie saubere Klassendefinitionen, definierte Signaturen und gegebenenfalls objektorientierte Strukturen.

39.5 Zusammenfassung der Unterschiede

Ansible unterscheidet klar zwischen:

Module:

• Ausführung als Subprozess
• JSON-Ein- und Ausgabe über stdin/stdout
• Keine festen Funktionsnamen erforderlich
• Basieren auf AnsibleModule-Klasse

Plugins:

• Direkter Python-Import
• Klar definierte Interfaces und Vererbungsstrukturen
• Ausführung innerhalb des Ansible-Prozesses
• Typenspezifische Basisklassen

Beide werden über Collections organisiert und zur Laufzeit über dynamische Pfadauflösung bereitgestellt.