DevOps-Enabler Ansible, Teil 4 AWX und Ansible Tower 3.2 einrichten und nutzen

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Nach der Installation von Ansible Tower werfen wir einen optionalen Blick auf die Installation von AWX, um uns dann mit Konzept und Arbeitsweise der grafischen Oberfläche für Ansible vertraut zu machen. Ab hier unterscheiden sich AWX und Ansible Tower kaum.

Anbieter zum Thema

Das Verständnis für die Objekt-Hierarchie von Ansible Tower ist wichtig für die Arbeit mit dem Berechtigungsmodell.
Das Verständnis für die Objekt-Hierarchie von Ansible Tower ist wichtig für die Arbeit mit dem Berechtigungsmodell.
(Bild: Ansible)

Eines muss dem Ansible-Nutzer auch bei Verwendung von Ansible Tower oder der Open-Source-Variante AWX in Bezug auf die grafische Oberfläche klar sein: diese hilft zwar beim Verwalten der einzelnen Systeme, im Gegensatz zu Chef oder Puppet unterstützen aber weder AWX noch Ansible beim Erstellen der Playbooks mit den jeweiligen konkreten Konfigurationsanweisungen.

Playbooks müssen auch bei AWS bzw. Ansible Tower manuell erstellt werden. Zudem müssen sie in einem Versionskontrollsystem abgelegt sein, wobei AWX zum Beispiel mit Subversion, Mercurial, Git sowie Red Had Insights als Repositories zusammenarbeitet. Bevor wir uns der Konfiguration und Navigation in und mit Tower/AWX zuwenden, noch ein paar Worte zum Installieren von AWX.

AWX installieren

Prinzipiell ist AWX für die Bereitstellung in einem bzw. mehreren Docker-Containern konzipiert. Zumindest ist dies die einfachste und schnellste Variante der Bereitstellung. Da der AWX-Container und Weitere im Verlauf der Installation automatisch erstellt werden, braucht man im Prinzip kein spezifisches Docker-Know-how.

Die Installation selbst ist im AWX Install Guide ausführlich beschrieben und bei Bedarf auch komplett ohne Containerisierung möglich. Ferner finden sich auch auf How-to-Forge-Anleitungen zur AWX-Installation unter CentOS 7 ohne Docker sowie mit Docker.

Der bereitgestellte Container lässt sich sowohl in einer reinen Docker-Umgebung als auch unter Red Hat OpenShift betreiben, allerdings funktioniert die Bereitstellung unter Docker schneller und soll im Folgenden nur kurz umrissen werden.

Wie bei Ansible Tower gilt auch bei AWX, dass Ansible (ab Version 2.4) bereits installiert sein muss. Im Falle AWX unter Docker braucht man natürlich Docker selbst in Form des Python-Moduls „docker.py“ sowie obligatorische Build-Werkzeuge wie GNU, make und Git. Sobald Ansible erfolgreich installiert wurde und der Docker-Daemon läuft, kann der Nutzer die aktuelle AWX-Version von GitHub herunterladen oder am besten gleich den aktuellen Stand in ein lokales Repository klonen:

git clone https://github.com/ansible/awx.git

Ist das geschehen, kann man bei Bedarf im Unterverzeichnis „Installer“ in der „inventory“-Datei mit dem Eintrag …

docker-hub_version=latest

…, der sicherstellt, dass die aktuellste AWS-Version verwendet wird, explizit seine Wunsch-Version erzwingen.

Auch die von AWX benötigte PostgreSQL-Datenbank wird automatisch in einem eigenen Docker-Container bereitgestellt, wobei die Datenbankinhalte per Default auf dem Host-System im Verzeichnis /tmp/pgdocker landen, was für ein Produktiv-Setup besser geändert werden sollte, da z. B. viele Distributionen bei einem Neustart das /tmp-Verzeichnis leeren. Auch die Datenbank-Konfiguration wird in der inventory-Datei im installer-Unterverzeichnis vorbereitet. Die zugehörige Zeile lautet „postgres_data_dir“.

Soll AWX eine bereits vorhandene Postgres-Datenbank verwenden, kann man die in der inventory-Datei vorbereiteten Zeilen „pg_username=awx“, „pg_password=awxpass“, „pg_database=awx“ und „pg_port=5432“ durchaus durch eigene Angaben ersetzen. Wer sich mit Docker auskennt, kann in der inventory-Datei auch noch weitere in der Dokumentation beschriebene Anpassungen vornehmen. Für einen ersten Test von AWX genügt es aber, die Voreinstellungen zu übernehmen und die eigentliche, Ansible-Playbook-gestützte Installation von AWX nun mit …

ansible-playbook -i inventory install.yml -vv

… anzuschieben. Nach einigen Minuten sollten bei unveränderter Default-Konfiguration fünf isolierte Container-Umgebungen „awx_task“, „awx_web“, „postgres“ „memcached“ und „rabbitmq“ entstehen, wobei „awx_web“ den AWX ausliefernden (NginX)-Webserver bereitstellt und „awx_task“ eine Reihe von vorbereiteten Tasks ausführt, wie z. B. das Einrichten der Datenbank. Die drei anderen Container hosten die gleichnamigen Dienste.

Hat alles geklappt, sollte AWX im Browser unter http://localhost erreichbar sein, sofern der Default-Port (80) in der inventory-Datei nicht geändert wurde. Damit AWX automatisch gestartet wird, muss der Admin nur noch dafür sorgen, dass der Docker-Daemon beim Booten automatisch startet, da dieser per Default so konfiguriert ist, dass er auch die Docker-Container startet, etwa mit „systemctl enable docker“.

Das Bereitstellen von Ansible Tower haben wir in Teil 2 dieser Beitragsreihe erläutert. Besonders schnell und komfortabel gelingt das Tower-Deployment als Cloud-Instanz in AWS. Der Vorgang ist in der AWS-Dokumentation sowie im Ansible Tower Quick Start Guide im Detail beschrieben.

Hinsichtlich der ersten Schritte an der grafischen Oberfläche unterscheiden sich AWX und Ansible Tower dann allerdings nicht mehr wesentlich. Die folgenden Abbildungen basieren auf Ansible Tower.

(ID:45381506)