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.

Firmen 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.

Erste Schritte mit Tower und Docker

Ansible Tower bietet im Unterschied zu Ansible eine rollenbasierte Zugriffkontrolle, ein effizientes Job-Scheduling sowie einen Portal-Modus und zeichnet sich durch die bereits beschriebene Cloud-Integration aus. So lässt sich Tower nicht nur unter AWS EC2, sondern auch unter Azure und Rackspace bereitstellen.

Kernstück von Tower und AWX ist die grafische Oberfläche mit dem „Ansible Dashboard“, über das man zunächst die initiale Konfiguration im Bereich „Setup / Users / admin“ anstößt. Hier können Tower-Admins die Eigenschaften der einzelnen Tower-User bearbeiten und zu jedem User dessen „Activity-Stream“ einsehen. Auch die meisten anderen „Ansichten“ in Tower haben eine „Activity Stream“-Schaltfläche, um zum Activity-Stream des jeweiligen Objektes zu kommen.

Unter „Organizations“ versteht man im Tower-Kontext eine logische Gruppierung von Teams, Usern, Projekten und Inventaren.
Unter „Organizations“ versteht man im Tower-Kontext eine logische Gruppierung von Teams, Usern, Projekten und Inventaren.
(Bild: Ansible)

Der Tower-Admin kann zudem jedem Tower-User-Konto „Credentials“ zuweisen oder die Berechtigungsart für das Inventory, bzw. Nutzer auf „read“, „write“ oder „admin“ setzen. Außerdem können Tower-Admins „Organizations“ und „Organization-Admins“ anzeigen und steuern, welchem Team der jeweilige User angehört. Unter einer „Organisation“ versteht man im Tower-Kontext eine logische Gruppierung von Teams, Usern, Projekten und Inventaren.

Das Berechtigungssystem von Ansible Tower erlaubt das Erstellen von Benutzern und Teams.
Das Berechtigungssystem von Ansible Tower erlaubt das Erstellen von Benutzern und Teams.
(Bild: Ansible)

Die Rollen-basierte Zugriffskontrolle von Tower erlaubt das Erstellen eigener User und Teams, welche je nach konfiguriertem Authentication-Provider wahlweise im Active Directory (Tower unterstützt Azure AD, Radius und SAML) oder im Zusammenhang mit einer Enterprise-Level-Lizenz im LDAP abgelegt sind.

Zum Bearbeiten und Ausführen eines Ansible-Jobs benötigt man allerdings sowohl Rechte am zugehörigen (Tower)-Projekt, als auch für die verwendeten Objekte wie z. B. die Inventory-Module. Diese mit Version 3.0 eingeführte Vereinheitlichung der Rechteverwaltung erlaubt es, auf Job-Ebene sicherzustellen, dass die eingerichteten Gruppen und Nutzer die Ihnen zugewiesenen Aufgaben problemlos durchführen können.

Unabhängig davon ist es aber auch in Tower immer noch möglich, explizit Rechte für einzelne Ansible-Projekte wie z. B. Playbooks zu vergeben. Unter „Projekten“ versteht man im Ansible-Kontext Playbooks oder Job-Templates. Um mit dem Berechtigungsmodell von Ansible-Tower flüssig zu arbeiten, sollte man mit der Objekt-Hierarchie und dem Modellierungsschema von Ansible (Projects, Playbooks) und Ansible Tower vertraut sein.

Objekthierarchie in Ansible Tower

Organizations: „Organisationen“ sind die oberste Ebene der Objekt-Hierarchie in Tower. Jede Organisation besteht aus Inventaren, Teams, Projekten und Jobs. Da Tower Tenant-fähig ist, kann die Software mehrere Organisationen verwalten.

Inventories: Mit „Inventaren“ können Admins im Inventory-File Hosts-Gruppen definieren, um Hosts innerhalb dieser Gruppen einfacher konfigurieren zu können, z. B. durch Zuordnen hostspezifischer oder Inventarspezifische Variablen.

Groups: „Gruppen“ ermöglichen es, ähnliche Hosts innerhalb eines Inventars zu gruppieren, um auf diese ein Playbook anzuwenden.

Hosts: Sie definieren die IP-Adresse, bzw. den Hostnamen des jeweiligen Knotens und eine Reihe von Host-Variablen.

Teams: Mit Teams lassen sich Organisationen weiter unterteilen, wenn etwa Netzwerk- oder Entwickler-Teams über eigene Server verfügen sollen, damit jedes Team seiner Server ohne Kenntnis des jeweils anderen Teams verwalten kann. Auch dazu können Tower-Admins für jedes Team eigene Credentials, Permissions und User definieren.

Credentials: „Anmeldeinformationen“ sind entweder Passwörter und/oder Zugriffsschlüssel, die es Tower erlauben, via SSH eine Verbindung zu einem Knoten herzustellen. Beispiele für durch Tower verwaltete Credentials sind ein SSH Password (für Passwort-basierten SSH-Login), ein SSH Private Key (für Schlüssel-basierte SSH Authentication), eine Kombination von SSH Private Key / Passphrase (für per Passphrase geschützte Private-Keys), ein sudo Password oder AWS Credentials, bzw. Rackspace Credentials. Tower speichert übrigens Access Keys und Secret Keys für AWS sicher in seiner Datenbank, ebenso wie Username und Secret Key für Rackspace oder SCM Credentials.

Teams-Permissions: Die Team-Berechtigungen binden Teams an Inventare und Jobs.

Users: Die eigentlichen Login-Entitäten für Tower sind schließlich die Benutzer. Sie werden entweder manuell erstellt oder von LDAP abgebildet. Benutzer besitzen Eigenschaften (Name, E-Mail, Benutzername, etc.) und Users-Credentials (Anmeldeinformationen), um eine Verbindung zu Diensten und Servern aufzubauen sowie User-Permissions, mit deren Hilfe User Rollen-basierte Zugriffskontrolle auf Organisationen (deren Mitglieder sie sind), Inventare, Teams, Projekte und Jobs.) erlangen.

Darüber hinaus kennt Tower „Inventory Policies“. Solche Inventar-Berechtigungen erlauben es Benutzern oder Teams, Inventare, Gruppen und Hosts zu ändern. Derweil geben Deployment-Berechtigungen Benutzern und Teams die Möglichkeit, Aufträge zu starten, Änderungen vorzunehmen, Jobs auszuführen oder Aufträge zu starten, die den Status der Jobs prüfen.

Im letzten Teil unserer Ansible-Reihe werden wir uns mit dem Portal-Modus, Workflows, Logging-Providern und schließlich den Job-Definitionen befassen.

(ID:45381506)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist