Große Versionssprünge in Ansible, was tun?

Ansible ist ein einfaches und beliebtes Automatisierungswerkzeug zur Konfiguration und Administration von Computern und Netzwerkkomponenten. Es wird von RedHat und einer aktiven Community entwickelt, sodass regelmäßig neue Versionen erscheinen. Seit der Version 2.9 hat sich am grundlegenden Aufbau einiges verändert. Neben der Integration von neuen und verbesserten Modulen, wurde die gesamte Versionierung und Paketierung neu strukturiert. Ab der Version 2.10 besteht Ansible nicht mehr aus einem großen Paket, welches die komplette Ansible-Basis inklusive aller Module enthält, sondern aus einem Paket namens ansible-base. Darin sind die Ansible-Runtime, Basismodule und weitere Plugins enthalten, die direkt von Ansible Inc. gepflegt werden. Zusätzliche Community- oder Drittanbieter-Module oder Plugins können durch Collections hinzugefügt werden. Mit der Ansible Version 4.0 wurde das Paket ansible-base in ansible-core umbenannt.

Die folgende Abbildung zeigt eine Übersicht der letzten Ansible-Versionen. Die Version 2.9 ist die letzte Version mit der bisherigen Struktur. In dieser sind Collections als Preview verfügbar. Ab Version 2.10 ist Ansible in das Paket ansible_base und Ansible Collections aufgeteilt. Die nachfolgende Version Ansible 3.0 setzt weiterhin auf ansible_base Version 2.10. und in der aktuellen Version Ansible 4.0 kommt ansible_core Version 2.11 zum Einsatz.

Collections

Während in früheren Versionen noch mehrere Tausend Module direkt mitgeliefert wurden, sind in dem Paket ansible-core (in Ansible 2.10 und 3.0 Community Package ansible-base) nur noch 69 Module enthalten. Der Vorteil dieser Trennung ist, dass nur die Module installiert werden müssen, die auch gebraucht werden und damit die Module übersichtlicher bleiben. Zusätzlich können die Module unabhängig von der Ansible-Version aktualisiert werden. Durch dieses Verfahren erreichen Aktualisierungen der Module schneller die Benutzer. Die Entwickler:innen von Ansible wollen weiterhin ca. alle 3 Wochen für Bugfixes eine voll abwärtskompatible Minor Version der aktuellen und vorigen Ansible-Version veröffentlichen.

Durch die Trennung der Module von der Ansible-Basis wird beim Aufruf der Module der Name des Moduls inklusive des vorangestellten Namespaces und der Collection angegeben. Beispielsweise sah ein Copy-Task bisher wie folgt aus:

copy:
  src: /srv/myfiles/foo.conf
  dest: /etc/foo.conf

Da das Copy-Modul in dem Namespace ansible und der Collecion builtin enthalten ist, sieht der Aufruf mit dem vorangestellten Namespace in Zukunft folgendermaßen aus:

ansible.builtin.copy:
  src: /srv/myfiles/foo.conf
  dest: /etc/foo.conf

Durch diese Aufteilung in verschiedene Collections müssen Modulnamen nur noch innerhalb einer Collection eindeutig sein. Damit vorhandene Playbooks weiter genutzt werden können, ist eine Abwärtskompatibilität gegeben. So können weiterhin Playbooks ausgeführt werden, die nur den Modulnamen enthalten, allerdings ist es bei der Entwicklung von neuen Playbooks empfohlen, den vollständigen Modulnamen inklusive Namespace und Collection anzugeben.

Installation/Upgrade:

Seit der Ansible-Version ansible-base-2.10 werden keine vorgefertigten RPM-Pakete mehr veröffentlicht. Diese müssen in späteren Versionen entweder selbst gebaut oder über den Python Paketmanager pip aktualisiert werden.

Die Community-Version Ansible 4.0, die aus ansible_coreVersion 2.11 und den Collections besteht, wird am einfachsten per pip installiert. Daher beziehen sich die folgenden Schritte nur auf die Installation per pip:

  pip install ansible

Ebenso kann stattdessen auch nur ansible-core (ohne Collections) installiert werden:

  pip install ansible-core

Generell ist es zu empfehlen, einen Blick in den Ansible Porting Guide der entsprechenden Version zu werfen (https://docs.ansible.com/ansible/devel/porting_guides/porting_guides.html), um schon frühzeitig mögliche Fehlerquellen zu entdecken.

Um von einer früheren Ansible-Version auf Ansible 4.0 upzugraden, wird zuerst die alte Version deinstalliert, um Abhängigkeitsprobleme zu vermeiden:

  pip uninstall ansible

Da sich der Name des Paketes von Ansible 3.0 zu 4.0 geändert hat, muss bei einem Upgrade von 3.0 auf 4.0 zwangsläufig das alte Paket ansible-base vorher deinstalliert werden.

Danach wird die neueste Community-Version von Ansible, wie im vorherigen Schritt beschrieben, installiert:

  pip install ansible

Alternativ wird die ansible-core-Version installiert, die keine Collections und zusätzliche Module enthält:

  pip install ansible-core

Die genauen Unterschiede zwischen ansible und ansible-core werden im nächsten Kapitel beschrieben.

Wenn ansible-base oder ansible-core eingesetzt werden, müssen gegebenenfalls weitere Module oder Collections installiert werden, da diese nur die Ansible-Basis und wenige grundlegende Module enthalten. Dieses Paket hat den Vorteil, dass der Anwender genau bestimmen kann, welche Collections installiert werden. Dies geschieht mit dem Kommandozeilentool ansible-galaxy, mit dem Rollen, Collections und Module über geteilte Repositories verwaltet werden. Um beispielsweise alle Module für Amazon AWS zu installieren, wird folgender Befehl ausgeführt:

  ansible-galaxy collection install amazon.aws

Ansible Community Package und ansible-core

Die folgende Tabelle zeigt den Zusammenhang und Unterschiede zwischen der Community-Version und ansible-core:

Weitere Neuerungen

Neben der geänderten Versionierung gibt es noch einige weitere Neuerungen bei Ansible. Mit dem neuen Connection Plug-in community.docker.docker_api können Tasks direkt in Docker-Containern ausgeführt werden. Ansible unterstützt seit Version 3.0 auch dynamische Inventories von Docker oder Proxmox Virtualisierungsumgebungen mit den Inventory-Plugins community.docker.docker_containers und community.general.proxmox. Mit dem neuen Lookup-Plug-in ansible.utils.validate können Daten und Variableninhalte zur Laufzeit eines Playbooks anhand von angegebenen Kriterien validiert werden.

Eine detaillierte Übersicht über alle Neuerungen ist im Changelog von Ansible 3.0 (https://github.com/ansible-community/ansible-build-data/blob/main/3/CHANGELOG-v3.rst) und Ansible 4.0 (https://github.com/ansible-community/ansible-build-data/blob/main/4/CHANGELOG-v4.rst) zu finden.