AWX/Ansible Tower

Viele Unternehmen rund um die Welt setzen Ansible ein und erarbeiten ihren eigenen Workflow. Demzufolge soll dieser Bericht eine Übersicht zu AWX/Tower schaffen und einige Vor- und Nachteile aufzeigen.

Der Ansible Tower wird als kostenpflichtiges Produkt von Red Hat verkauft und weiterentwickelt. Parallel dazu existiert ein quelloffenes Projekt namens AWX. Es stellt den Open Source Ableger des Ansible Towers dar. AWX erfüllt die Aufgabe, neue Features und Verbesserungen zu integrieren. Wenn sich die Anpassungen bewähren, fliessen diese zurück ins Enterprise Produkt Ansible Tower.

Die Applikation besteht aus folgenden Komponenten:

  • Django
  • Celery
  • RabbitMQ
  • Postgresql

Bei Django handelt es sich um ein Python Web Framework, welches das Userinterface und die Restful API des Produkts bereitstellt. Die Cluster Kommunikation wird durch RabbitMQ ermöglicht. Um die Ausführung von Ansible kümmern sich die Celery Worker, die Tasks über den Cluster verteilt ausführen. Die Konfiguration, Facts und das Reporting werden in die Postgesql Datenbank hinterlegt. Aufräum-Aufgaben erfüllen Tower interne Ansible Jobs.

Wie ist AWX/Tower zu verwenden ?

Wer Jobs ausführen will, muss erst Ressourcen erfassen.

Ressourcen werden aufgeteilt in:

  • Templates
  • Credentials
  • Projects
  • Inventories
  • Inventory Scripts

Ich gehe in diesem Blogpost auf die Templates ein. Es existieren zwei Arten von Templates. Ein Job-Template besteht aus Ressourcen, wie dem Inventar, Projekt und Credentials. Das Workflow-Template ist zum Verketten von Job-Templates gedacht. Projekte liefern Ansible Deklarationen aus Git/Mercurial/Subversion/RedHat Insights oder einem lokalen Verzeichnis. Das Erfassen und Ausführen der Ressourcen ist über die API wie auch das GUI möglich.

Beispiel eines Workflow-Templates zum Aufbau eines OpenShift-Techlabs

Jedem im Workflow hinzugefügten Job-Template können Parameter übergeben werden.

Ist es möglich „virtualenv“ zu verwenden ?

Ja, seit der Version 3.0. AWX/Tower installiert zwei Umgebungen. Eine für AWX/Tower und eine zum Ausführen von Ansible. Ab Version 3.5 sind custom Umgebungen für jedes Projekt möglich.

Wie sieht es mit Monitoring aus?

AWX/Tower stellt einen Metrics Endpoint über die API bereit, welche für Prometheus nützlich wäre.

Welche Python Version setzt Tower ein ?

Ab Relase 3.5 => Python 3.6

Wo liegen nun die Vor- und Nachteile von AWX/Tower ?

Vorteile:

  • Skalierbarkeit für grössere Umgebungen
  • Zentrale Ausführung von Ansible in Virtual Environments
  • Einfache Integration in CI/CD möglich
  • Role-based Access Control
  • Nicht-privilegierte User können selbständig Tasks ausführen
  • Ansible-Logs sind zentral verfügbar und ermöglichen somit die Untersuchung und Nachvollziehbarkeit von ausgeführten Aufgaben.

Nachteile:

  • Verwaltung von Tasks, Workflows, Workflow-Templates sind unübersichtlich und schwierig zu gruppieren. Mit einem nachhaltigen Namenskonzept kann dies aber etwas entschärft werden.

 

Nützliche Links:

Kommentare sind geschlossen.