In die Zukunft mit Ansible Collections

Der Ansible Contributor Summit 2020 fand nicht wie ursprünglich geplant in Göteborg statt, sondern wurde in den Cyberspace verlegt. René Moser war in seiner Funktion als Core Contributor mit dabei und hat uns mit den aktuellsten Informationen zur Zukunft von Ansible versorgt. (Die Talks sind auf Youtube zu finden). Ein wichtiger Teil dieser Zukunft werden die Ansible Collections sein.

Ansible Collections?

Ansible hat sich als IT-Orchestration und Config-Management-Tool durchgesetzt. Es gibt kaum ein Use case, der mit Ansible nicht abgedeckt und kaum eine Plattform, die nicht mit Ansible gemanaget werden kann. Unzählige verschiedene Module stellen den riesigen Funktionsumfang sicher. Mit Ansible Collections werden neu Teile der Funktionalität von Ansible ausgelagert. Bereits in der aktuellen Version 2.9 von Ansible sind Ansible Collections als Tech-Preview vorhanden. Mit Ansible 2.10 werden die Collections wohl ihren Status als Tech-Preview verlieren und definitiv fixer Teil von Ansible werden. Das Entwicklerteam peilt ein Release von Ansible 2.10 im August 2020 an.

Ansible 2.10 kommt als sogenannte ACD (Ansible Community Distribution) daher und besteht einerseits aus ansible-base und andererseits aus Collections die zusätzliche Funktionalität bereitstellen. ansible-base kann mit pip install ansible-base auch ohne zusätzliche Collections installiert werden und beinhaltet gegen 70 Core Plugins.

Grund für die Auslagerung von Funktionalitäten in Collections ist unter anderem, dass die hohe Anzahl an Modulen den Release-Zyklus strapazierte und neue Features in Plugins nur mit neuem Release von Ansible bereitgestellt wurde. Mehr zu den Gründen kann hier nachgelesen werden. Durch Collections können nun Plugins einen eigenen, schnelleren Releasezyklus haben.

Support für Ansible wird man neu auf verschiedene Ebenen erhalten. Red Hat supportet bei vorhandener Subscription die Collections hier. Zertifizierte Partner (z.B. Google, Azure etc.) bieten Support für ihre eigenen Collections an und Collections unter diesem Link werden von der Community gepflegt. Entscheidend dafür wie die Collection supportet wird, ist der Namespace (mehr dazu später). Die Organisation auf Github (z.B. https://github.com/ansible-collections) ist irrelevant.

Alle von der Community entwickelten Plugins werden in separaten Repositories gepflegt. Einige vom Ansible-Team migrierte Plugins finden sich hier. Bestehende Plugins befinden sich mehrheitlich in der Hauptcollection. Azure wiederum wurde bereits in ein eigenes Repository migriert, in welchem es von der Azure Working Group weiterentwickelt wird.

Höchste Zeit also, einen genauen Blick auf Ansible Collections zu werfen!

Was ist eine Collection?

Eine Collection kann verschiedene Komponenten von Ansible beinhalten, zum Beispiel Playbooks, Rollen, Module und auch Plugins. Dieser Inhalt kann mit dem Installieren einer Collection der eigenen Ansible-Umgebung zur Verfügung gestellt werden. Die Collection wird immer in der Form

<namespace>.<collectionname>

angesprochen. Namespaces verhindern Naming Collisions und können zur Zeit über Github Issue beantragt werden.

Namespaces bei Collections haben keine Relation zu Github Handles (im Gegensatz zu Role Namespaces). Collections werden gepackt (tarball) und gepushed auf Galaxy und können auf einem beliebigen Git Repository gehostet sein (private oder public). Der Namespace wird im Metafile galaxy.yml definiert, dazu später mehr.

Wie sieht eine Collection aus?

Eine Collection muss einer wohldefinierten Struktur entsprechen. Hier ein Beispiel:

$ ansible-galaxy collection init puzzle.puzzle_collection
- Collection puzzle.puzzle_collection was created successfully
$ tree
.
└── puzzle
       └── puzzle_collection
              ├── docs
              ├── galaxy.yml
              ├── plugins
              │   └── README.md
              ├── README.md
              └── roles

5 directories, 3 files

Eine Collection kann weitere Verzeichnisse und Dateien (z.B. für Modules oder Playbooks) enthalten. Mehr dazu gibt es hier nachzulesen.

Wo kriege ich eine Collection her?

Collections können von einem Tarball oder einem online Repository installiert werden. Der Pfad zu den lokalen Repositories können mittels dem Parameter collections_path in der Ansible Konfiguration ansible.cfg definiert werden, online Repositories werden in demselben File als Einträge unter [galaxy] definiert. Hier ein Beispiel:

[galaxy]
server_list = automation_hub, puzzle_hub, release_galaxy, test_galaxy

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token=<secret_token>

[galaxy_server.puzzle_hub]
url=https://hub.puzzle.ch/
username=<username>
password=<secret_password>
[galaxy_server.release_galaxy] url=https://galaxy.ansible.com/ token=<secret_token>
Blick auf den Inhalt des Automation Hubs, Quelle: https://www.ansible.com/products/automation-hub

Im Automation Hub von Red Hat werden Inhalte veröffentlicht, die bei vorhandener Subscription von Red Hat supportet werden. Im Screenshot oben sind Partner zu sehen welche Inhalte beisteuern. Puzzle_Hub ist ein Beispiel für ein privates Repository und Ansible Galaxy ist das bekannte frei verfügbare Repository der Ansible Community.

Collections können übrigens auch analog zu Roles mit einem Requirements-File installiert werden. Mehr dazu gibt es hier.

Wie installiere ich eine Collection?

Ähnlich wie bei Roles können Collections mit dem Befehl ansible-galaxy installiert werden. Wichtig ist hier ebenfalls, dass der Name der Collection mit dem Namespace des Anbieters der Collection prefixed ist:

ansible-galaxy collection install puzzle.puzzle_collection

Dieser Befehl installiert die Collection puzzle_collection im Verzeichnis welches in der ansible.cfg definiert wurde. Soll nun in einem Play eine Role aus dieser Collection verwendet werden kann das dem folgenden Beispiel entsprechend gemacht werden:

---
- hosts: puzzle_nodes collections: - puzzle.puzzle_collection tasks: - import_role: name: puzzle_clusternode - name: do some stuff ...

Mit ansible-galaxy kann auch eine bestimmte Version einer Collection installiert werden:

ansible-galaxy collection install puzzle.puzzle_collection:1.0.0

Damit lässt sich sicherstellen, dass neuere Versionen einer Collection nicht ungewollt bestehende Abhängigkeiten verletzen.

Wie erstelle ich eine Collection?

Der Befehl ansible-galaxy collection init namespace.collection_name ist ein guter Weg um ein Gerüst für die Collection zu erstellen. Die Collection muss in jedem Fall ein File galaxy.yml enthalten, welches Informationen zur Collection bereitstellt. Details zu diesen Informationen können hier nachgelesen werden. Nachdem der gewünschte Inhalt der Collection zugefügt wurde, kann die Collection analog dem folgenden Beispiel erstellt werden:

$ ansible-galaxy collection build puzzle_collection
Created collection for puzzle.puzzle_collection at
/home/pschmid/temp/puzzle/puzzle-puzzle_collection-1.0.0.tar.gz
$ ll
total 8.0K
drwxrwxr-x 5 pschmid pschmid 4.0K Apr 1 11:43 puzzle_collection
-rw-rw-r-- 1 pschmid pschmid 1.3K Apr 1 12:13 puzzle-puzzle_collection-1.0.0.tar.gz

Um die Collection auf dem im ansible.cfg definierten Server zu veröffentlichen, reicht folgender Befehl:

ansible-galaxy collection publish puzzle-puzzle_collection-1.0.0.tar.gz

Damit ist alles getan, um die Collection anderen zur Verfügung zu stellen.

Offene Punkte

Es gibt ein paar Fragen die zur Zeit noch offen sind. Wie werden Abhängigkeiten von Galaxy-Rollen auf Collections, die nicht in der ACD sind abgebildet? Wie kann man Collections einfach forken? Gibt es andere Wege als Collections über einen Galaxy-Server (public oder private) zu installieren?

An diesen und weiteren Punkten, wie die Integration von Collections in AWX / Ansible Tower, arbeiten die Ansible Contributors zur Zeit!

Wo finde ich mehr zum Lesen über Collections?

Kommentare sind geschlossen.