Ansible schreitet mit grossen Schritten in die Zukunft. Nachdem im letzten Jahr mit Ansible 2.10 und der Auslagerung von Funktionalität in Collections eine wichtige Design-Änderung erfolgte (hier sind die Details nachzulesen), stehen bereits die nächsten Erneuerungen an.
Ansible 2.10 / Ansible-Base
Mit der Einführung von Ansible 2.10 (als sogenannte Ansible Community Distribution) wurde das bekannte Ansible in Ansible-Base 2.10 und Collections aufgeteilt. Ansible-Base 2.10 kann auch ohne zusätzliche Collections mittels pip install ansible-base installiert werden und besteht aus ungefähr 70 Plugins, die die Core-Funktionalität von Ansible bereitstellen. Die Installation dieser Collections, welche Module, Plugins und weiteren Content beinhalten können, kann mit dem Befehl ansible-galaxy erfolgen. Wie das im Detail funktioniert, ist in diesem Blogpost ersichtlich. Ändern tut sich indes nicht viel: Installiert man auf einem Centos 8 Server Ansible 2.10 (Ansible Community Distribtion, nicht Ansible-Base 2.10!) mittels pip install ansible, so können Module wie gewohnt verwendet werden. Eine Angabe der verwendeten Collections oder des FQCN’s (Fully Qualified Collection Names) in den Playbooks und Taskfiles ist nicht nötig. Die Aufteilung in Ansible-Base und Collections erfolgt für den Benutzer transparent. Der User hat also die Möglichkeit, entweder Ansible 2.10 oder Ansible-Base 2.10 und allenfalls zusätzliche Collections zu verwenden.
Ansible 2.11 / Ansible-Core
Der Teil von Ansible, der die Core-Funktionalität bereitstellt, heisst neu Ansible-Core. Auf Ansible-Base 2.10 folgt also neu Ansible-Core 2.11. Das Konzept bleibt dasselbe: Plugins, welche die Core-Funktionaliät bereitstellen, kommen mit Ansible-Core daher. Zusätzliche Funktionalität kann mittels Collections eingebunden werden. Aber Achtung: Der Nachfolger von Ansible 2.10 (Community Distribution) ist nicht wie erwartet Ansible 2.11, sondern Ansible 3.0!
Ansible 3.0 / Ansible 4.0
Ansible 3.0 besteht aus über 85 von der Community gepflegten Collections und einer Abhängigkeit auf einen Version-Bereich von Ansible-Base. Richtig gelesen, zur Zeit ist dies immer noch Ansible-Base (2.10) und nicht Ansible-Core (2.11). Ansible 4.0 wiederum wird gemäss der aktuellen Planung eine Abhängigkeit auf Ansible-Core 2.11 beinhalten. Damit ergibt sich folgende Übersicht:
Update auf Ansible 3.0
Da Ansible 3.0 und Ansible 2.10 (Community Distribution) beide auf Ansible-Base 2.10 beruhen, kann ein Update zwischen diesen Versionen mit pip install --upgrade ansible erfolgen. Die Syntax der Playbooks bleibt gleich, da Ansible-Base immer noch in der Version 2.10 aufliegt. Da aber breaking Changes in Collections erlaubt sind, kann es beim Gebrauch von gewissen Modulen zu Inkompatibilität kommen.
Wo kriege ich Ansible 3.0 her?
Bemerkenswert ist, dass vom Ansible Projekt keine upstream RPM-Pakete mehr auf releases.ansible.com zur Verfügung gestellt werden. Als offizielle Quelle wird neu pypi.python.org dienen. Es ist anzunehmen, dass Fedora und EPEL RPM’s von Ansible 3.0 bereitstellen werden, aber eben nicht mehr offiziell vom Ansible Projekt. Auf Ubuntu wiederum wird das Ansible Projekt PPA’s (Personal Package Archive) in Ubuntu Launchpad einspielen. So sollten kommende Ansible-Versionen via den gewohnten Repositories verfügbar sein.
Mit dem Update auf Ansible 4.0 und der wechselnden Abhängigkeit von Ansible-Base auf Ansible-Core wird bei einem Update eine Deinstallation und Neuinstallation von Ansible nötig sein. Grundsätzlich gilt, dass Major-Releases (4.0, 5.0, etc) Breaking-Changes beinhalten können, nicht rückwärtskompatibel sein müssen und etwa alle sechs Monate erscheinen. Für die Minor-Releases (3.1, 3.2, etc) gilt aber, dass diese mit vorgängigen Versionen kompatibel sein werden und Updates gefahrlos erfolgen können.
Die nächste Ansible Major-Version 4.0 soll bereits am 18. Mai 2021 erscheinen. Es bleibt abzuwarten, ob das wirklich der Fall sein wird – Ansible 2.10 wurde auch mit etwas Verspätung released.
Und was ändert nun?
Noch nicht allzu viel. Da die Abhängigkeit von Ansible 3.0 immer noch auf Ansible-Base 2.10 zeigt, sind keine Änderungen der Syntax nötig. Bei Plugins und Modulen, die aus Collections bereitgestellt werden, kann es allerdings zu Unverträglichkeiten kommen. Hier wird sicher ein vorgängiges und ausgiebiges Testen der bestehenden Playbooks angezeigt sein.
Wann wiederum diese Änderungen Einzug in die Red Hat Automation Plattform halten werden, ist uns noch nicht bekannt. Die neuste verfügbare Version von Ansible-Tower (3.8.1) beinhaltet noch immer Ansible 2.9. Gemäss neusten Informationen von Red Hat ist mit grösseren Änderungen im Aufbau der Automation Platform zu rechnen. Unter anderem sollen vermehrt Teile (z.B. Python virtualenvs) in Container ausgelagert und der Aufbau modularisiert werden. Das ist aber eine Geschichte für einen anderen Tag…
… und wieso Kühe?
In den ersten Versionen von Ansible war in der Default-Konfiguration festgehalten, dass der Output jeweils durch das Programm cowsay erfolgte und somit in der Sprechblase einer Kuh erschien. Mittlerweile ist dies per Default deaktiviert, kann aber mit dem Setzen der entsprechenden Umgebungsvariablen (oder Konfiguration in ansible.cfg) eingeschaltet werden:
[pschmid@pschmid-puzzle]$ ANSIBLE_NOCOWS=0 ansible-playbook plays/site.yml
__________________
< PLAY [localhost] >
------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||