Ansible Automation Platform

Ansible ist bekanntermaßen eines der meistverbreiteten Automation Tools. Zurückzuführen ist das sicherlich auch auf das relativ einfache Setup und die Benutzung. Gerade in sehr großen Umgebungen, also bei einer großen Userzahl, stößt man aber mit einem reinen CLI-Setup schnell an Grenzen: Mandantenfähigkeit, Credential-Verwaltung, Scheduling sind nur einige der Punkte,die ein sehr genaues Hinsehen erfordern.

Mögliche Lösungsansätze kommen in verschiedenen Größen und Komplexitätslevel: Von reinen CI/CD Ansätzen mit Jenkins GitLab CI/CD, über die integrierte Verwaltung in Foreman-Varianten, wie beispielsweise orcharhino bis hin zur Automation Platform, einer eigenen Lösung von RedHat.

In diesem Blog-Post wollen wir die grundlegende Architektur und Funktionsweise der Ansible Automation Platform skizzieren. Grundsätzlich ist die Idee immer eine Teilung von Ansible Content und der ausführenden Schicht wie hier zu sehen:

Die ausführende Schicht ist dabei der Ansible Automation Controller. Dieser basiert auf dem Open-Source Projekt AWX.

AWX/Automation Controller

Grundsätzlich sind AWX und Automation Controller identisch, nur ist letzterer die Enterprise kompatible Downstream Variante. Intern benutzt AWX zunächst zwei Komponenten: ansible-runner, sowie Ansible Execution-Environments.

ansible-runner ist eine Open Source Python-Library die das automatisierte Ausführen von Playbooks gegenüber der Benutzung von ansible-playbook deutlich vereinfacht.Einerseits lässt sich damit eine Prozessisolierung und Parallelisierung von playbook runs erreichen, andererseits liefert ansible-runner auch einen deutlich besser verwertbaren Output als der Standard ansible-playbook Aufruf. Einfach gesprochen ist ansible-runner nichts als eine Runtime Execution für Ansible.

Um Ansible Jobs unabhängig von ihrer Umgebung konsistent durchzuführen gibt es darüber hinaus sog. Ansible-Execution Environments: Dabei handelt es sich um nichts anderes als OCI-kompatibel Container Images, innerhalb derer ein Playbook mit allen Abhängigkeiten ausgeführt werden kann.

Dazu werden Ansible-Collections, python libraries und Ansible-Base in einem Container zusammengefügt. Idealerweise kann dafür das Open Source Tool ansible-builder genutzt werden. Ein finales Execution Environment hat dann folgende Form:

Execution Environments können dann in AWX mittels ansible-runner benutzt werden.

Private Automation HUB aka Private Galaxy

AWX kommt mit vorgefertigten Execution Environments. Will man aber eigene Execution Environments erstellen und verwenden, so stellt sich die Frage, wo diese idealerweise abgelegt werden. Prinzipiell bietet sich zunächst jede beliebige OCI-kompatible Container-Registry an.

Will man jedoch mehrere Fliegen mit einer Klappe schlagen, so kann man über eine eigene Galaxy Installation nachdenken. Über die offizelle Ansible-Galaxy stolpert jeder Ansible-User früher oder später, ist sie doch der zentrale Community Hub für Ansible Inhalte aller Art. Das Ansible Automation Platform Enterprise Produkt liefert mit Private Automation Hub die Möglichkeit eine on-premises Installation von Ansible Galaxy vorzunehmen und somit eigene Inhalte verwalten zu können.

Aber auch nicht-Enterprise Kunden können in den Genuss einer solchen on-premises Installation kommen. Auch Private Automation Hub basiert auf einem Open Source Projekt – in diesem Fall handelt es sich um Pulp. Pulp ist Ihnen vielleicht bereits als Backend Komponente von Katello – im orcharhino/Foreman/Satellite Umfeld bekannt. Den Installationsweg der reinen Open Source Variante finden Sie bei GitHub oder auf YouTube.

Ob nun Enterprise Private Automation Hub oder Open Source Galaxy, am Ende kann die Komponente dann sowohl Execution Environments, als auch eigene Ansible Collections verwalten. AWX Nodes können diese Inhalte dann bei der Ausführung von Playbooks ziehen.

Automation Mesh

AWX/Automation Controller lässt sich darüber hinaus clustern, sodass Hochverfügbarkeit und höhere Parallelisierung erreicht werden. Dazu führt AWX das automation-mesh ein, das auf dem Open Source Framework receptor basiert.

Damit können verschiedene Nodes in einem AWX Cluster verschiedene Rollen einnehmen:

Controller Nodes bilden die sogenannten Control Plane. Diese Nodes kümmern sich um alle Management Aufgaben, wie zum Beispiel die Verteilung von Jobs oder den Sync von Ansible Content mit der Quelle, also meistens dem Git Repository.
Execution Nodes können lediglich Ansible-Jobs ausführen, die ihnen zugewiesen wurden.
Hybrid-Nodes sind – wie der Name bereits andeutet – sowohl Teil der Control Plane, als auch Execution Nodes.

Falls die Automation Platform Installation über mehrere Netzwerke hinausreichen, zum Beispiel über DMZ Grenzen hinweg, können zudem Hop-Nodes deployed werden. Diese dienen im receptor-Netzwerk lediglich als Forwarder. Wie im Bild angedeutet reicht es dann in der Firewall lediglich den Traffic zur Hop-Node zuzulassen.

Die modulare Bauweise und die Ausführung mittels Automation Controller erlaubt final ein sehr flexibles Deployment. Egal ob rein containerisiert in Kubernetes/OpenShift, als virtuelle Maschinen, bare-metal oder eine Mischung, der Kreativität sind kaum Grenzen gesetzt.

Melden Sie sich gerne bei uns um Ihren eigenen Usecase zu diskutieren oder entwerfen. Wir freuen uns auf Ihre Anfrage!

Ansible-Schulung

ATIX bietet Ansible-Schulungen für Anfänger:innen und Fortgeschrittene an, in denen Teilnehmer:innen lernen, wie man Ansible als Konfigurationsmanagement-Tool nutzt. So können sie ihre Infrastruktur mit Ansible-Rollen effizienter verwalten und finden heraus, wie sie Ansible-Rollen, Inventories und Playbooks bestmöglich erstellen, nutzen und pflegen.

Mehr erfahren