DevOps-Enabler Ansible, Teil 4

AWX und Ansible Tower 3.2 einrichten und nutzen

Seite: 2/2

Firmen zum Thema

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