DevOps-Enabler Ansible, Teil 3 Installation von Ansible Tower

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

Manch ein IT-Spezialist arbeitet lieber mit Kommandozeilen, doch auch grafische Oberflächen können Vorteile bieten. Bei Ansible wird dies mit Red Hat Ansible Tower realisiert, im dritten Teil unseres Workshops befassen wir uns mit der Installation des Enterprise-Frontends.

Firmen zum Thema

Eine grafische Benutzerschnittstelle für Ansible wird mit dem auf AWX basierenden Ansible Tower realisiert.
Eine grafische Benutzerschnittstelle für Ansible wird mit dem auf AWX basierenden Ansible Tower realisiert.
(Bild: Augsten / Ansible.com)

Die Open-Source-Version von Ansible Tower hört auf den Namen AWX und wurde von Red Hat im Oktober 2017 freigegeben. Kurze Zeit später erblickte dann mit Ansible Tower 3.2 das – nach Ansible Tower 3.0 und 3.1 – dritte große Upgrade der ausschließlich unter der Regie von Red Hat verantworteten kommerziellen AWX-Version das Licht der Welt. Die Vorgängerversionen 1.4.x bis 2.4 des von Anfang an kommerziell vermarkteten Ansible-Frontends (ursprünglich unter der Bezeichnung „AWX Project“) waren noch von Ansible Inc. verantwortet.

Aktuell ist die Version 3.2.3 von Ansible Tower. Ansible Tower ist ein Frontend für Ansible, welches die Community-Version unter anderem mit einer graphischen Benutzeroberfläche ausstattet. Der Zugriff aus anderen Tools und Services wird über eine integrierte REST API ermöglicht. Ansible Tower ist in den Editionen Self-Support, Standard und Premium zu Preisen von 5.000 US-Dollar, 10.000 Dollar und 14.000 Dollar im Jahr und für bis zu 100 Nodes verfügbar.

Installationsvoraussetzungen

Ursprünglich ließ sich Ansible Tower nur unter der 64-Bit-Version von Red Hat Enterprise Linux 7.2 oder jünger sowie CentOS ab 7.2 installieren. Inzwischen unterstützt Red Hat aber auch Ubuntu 14.04 LTS, Ubuntu 16.04 LTS in der jeweiligen 64-Bit-Version. In allen Fällen ist das Vorhandensein von Ansible Core Pflicht.

Im Falle von Ansible Tower ist Red Hat zunächst einmal der Anbieter der Software. Da als Ziel-Betriebssystem neben RHEL auch Ubuntu und künftig womöglich andere Cloud-Betriebssysteme fungieren, ist Tower (anders als andere Red-Hat-Produkte) nicht nur im Red-Hat-Portal sondern auch über die Ansible-Tower-Produktseite verfügbar.

Zur Installation empfiehlt Red Hat, dass Tower als einzige Applikation exklusiv auf einer VM, Cloud-Instanz oder physikalischen Maschine zu installieren. Begründet wird dies damit, dass es sich bei Tower um eine komplex Software mit vielen Abhängigkeiten handelt, etwa zu PostgresQL, Apache, Django und vielem mehr.

Genau wie Ansible ist Tower in Python geschrieben, allerdings verwenden beide keine Standard-Python-Libraries. Deshalb lässt sich Tower nicht ohne Weiteres in einem Python-virtualenv, einem Docker-Container oder vergleichbaren Subsystemen betreiben. Beim Datenbank-Backend haben die AWX-Entwickler mit Fertigstellung der Version 3.0 von MongoDB zu PostgresQL (9.6) gewechselt, weil die benötigten Datentypen bei PGSQL ein Drittel weniger Platz beanspruchen, als eine JSON-formatierte Textdatei im Dokumenten-orientierten MongoDB.

Benötigte Hardware

Die Hardware-Voraussetzungen für Ansible Tower sind relativ überschaubar, mit Ausnahme der Arbeitsspeicher-Ausstattung. Diese hängt im Einzelfall von der Anzahl Hosts ab, die von Tower gleichzeitig verwaltet werden. Gesteuert wird das simultane Verwalten durch den Parameter „forks“ in der Konfigurationsdatei ansible.cfg. Ansible empfiehlt für je 100 forks 4 Gigabyte (GB) RAM zusätzlich zu den empfohlenen 4 GB (2 GB sind Mindestvoraussetzung) einzuplanen, um Ressourcen-Konflikte von Vorneherein zu vermeiden.

Beim Festplattenplatz genügen 20 GB, wobei zehn davon exklusiv für das /var-Verzeichnis verfügbar sein müssen, in dem Tower seine Dateien und Arbeits-Verzeichnisse ablegt. Mit einem Partitionsschema nach dem LVM-Verfahren (Logical Volume Manager) ist der Admin auf der sicheren Seite und kann /var bei Bedarf leicht vergrößern.

Ansible Tower lässt sich optional auf einer Cloud-Instanz in AWS installieren.
Ansible Tower lässt sich optional auf einer Cloud-Instanz in AWS installieren.
(Bild: AWS Germany GmbH)

Optional kann Tower auch auf einer Cloud-Instanz in AWS installiert werden. Ansible empfiehlt dazu den Instanz-Typ „m3.medium“ oder größer, falls mehr als 100 Hosts verwaltet werden sollen. Besonders schnell und einfach gelingt das bei Verwendung des exklusiv für das Testen von Ansible Tower bereitgestellte AMI (Amazon Machine Image).

Klickt man in der Ansible-Tower-Dokumentation beim Anfordern einer Trial-Version beispielsweise direkt auf den Link für das entsprechende Tower-AMI in AWS, so landet man – ein vorhandenen AWS-Konto vorausgesetzt – direkt im EC2-Dashboard. Ansible Tower ist dann – vorhandene VPCs, Security-Groups und Public Subnets ebenfalls vorausgesetzt – in weniger als zehn Minuten einsatzbereit. Der Zugriff auf die GUI ist dann über den Public-DNS-Namen der Instanz möglich.

Darüber hinaus beschreibt auch AWS selbst die manuelle Installation von Tower auf EC2 in seiner Dokumentation. Zusätzlich gibt es AWS-Market-Place-AMIs für Tower. Ebenso einfach gelingt ein Launch von Ansible Tower in Vagrant. Übrigens lässt sich auch Ansible (ohne Tower) auf AWS betreiben. Doch zurück zur manuellen Installation.

Software-Voraussetzungen

Die Software-seitigen Voraussetzungen von Ansible Tower sind ebenfalls überschaubar. Allerdings sollte man sich vor Augen halten, dass Ansible-Tower selbst anhand eines Ansible-Playbooks bereitgestellt wird. Das erfolgreiche Installieren von Tower setzt also das Vorhandensein einer stabilen Ansible-Version voraus.

Bis einschließlich Tower 2.3 sowie bei einer Installation unter Ubuntu musste man sich im Übrigen explizit darum kümmern. Seit Tower 3.0 besteht optional die Möglichkeit, dass die Ansible-Installation Teil des Installationsprozesses ist. Hierfür muss der Nutzer das „Setup-Bundle“ herunterladen, das sich automatisch um die vorherige Ansible-Installation sowie die Auflösung der Abhängigkeiten kümmert.

Möchte der Admin Ansible aber doch manuell installieren, muss er wie in Teil 2 beschrieben unter CentOS das Epl-Repository hinzufügen. Zudem wird die Paketquelle „extras“ bzw. „rhel-7-server-extras-rpms“ unter RHEL benötigt. Für das manuelle Installieren von Tower unter AWS-EC2 ist das Paket „rh-amazon-rhui-client“ erforderlich, um das optionale Repository „rhui-REGION-rhel-server-extras“ aktivieren zu können.

Achtung auch bei RHEL und SELinux: Tower unterstützt nur die SELinux-Policy „targeted“, die wahlweise auf „disabled“, „permissive“ oder „enforcing“ gesetzt werden muss. Sind die Voraussetzungen geklärt, gelingt die Ansible-Installation unter RHEL und CentOS mit:

yum install ansible

Unter Ubuntu muss der Admin für das Installieren von Ansible zunächst das Ansible-ppa aktivieren:

sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible

Danach kann Ansible mit …

sudo apt-get update

… und …

sudo apt-get install ansible

… installiert werden.

Betriebsmodi

Ansible Tower lässt sich in verschiedenen „Single Maschine“- Betriebsmodi oder im „Multi Machine Cluster (HA)“ betreiben.

  • In der Single-Machine-Betriebsart unterscheidet Red Hat zwischen dem „eingebetteten“ Modus mit Web Frontend, REST API Backend, und Datenbank auf der gleichen Maschine (Default) …
  • ... und einem Modus mit Remote-Datenbank-Anbindung. Hierbei konfiguriert der Admin Tower so, dass eine Kommunikation mit der gewünschten Remote-Instanz von PostgreSQL 9.4.X möglich ist. Diese kann auf einem externen Server (physisch oder VM) laufen. Optional unterstützt Tower auch Amazon RDS.
  • Tower lässt sich aber auch mit einer Playbook-basierten Installation eines Remote-PostgreSQL-Systems betreiben.
  • Tower im Cluster-Betrieb erfordert in jedem Fall eine externe Datenbank. Auch hier wird wieder zwischen Remote-Datenbank-Anbindung (Server, VM oder RDS) …
  • … und einer Playbook-basierten Installation des externen Datenbanksystems unterschieden.

Tower Setup

Da Tower wie beschrieben über ein Ansible-Playbooks installiert wird, besteht der nächste Schritt darin, das Installations-Werkzeug für Tower herunterzuladen und zu entpacken, welches das Setup-Skript „setup.sh“ enthält. Vor dessen Start sollte man das in Teil 2 erklärte Inventory-File im entpackten Playbook-Verzeichnis seinen Wünschen anpassen. Die zu verwaltenden Hosts – also auch der, auf dem Tower installiert wird – stehen im Bereich [alls:vars].

Im einfachsten Fall (Tower auf dem lokalen Ansible-Host) trägt man hier 127.0.0.1 ein. Bei einer Embedded-Installation gilt dies auch für „pg_host“. Ferner sind die Standard-Namen für Datenbank, Datenbank-User und die zugehörigen Passwörter den eigenen Bedürfnissen anzupassen. Beispielsweise ist „admin_password='' das Passwort des lokalen Tower-Admins. Das Passwort für die Postgres-Datenbank „pg_password“ steht normalerweise in „/etc/tower/conf.d/postgres.py“. Das Passwort für „rabbitmq_password='' kann man nach Belieben setzen.

Einfacher hingegen gelingt das Bundle-Setup, welches das Einspielen von Ansible einschließlich aller Abhängigkeiten gleich miterledigt. Hierzu lädt sich der Admin das Ansible Setup Bundle herunter, welches nur für Red Hat Enterprise Linux oder CentOS verfügbar ist, nicht aber für Ubuntu.

Im nächsten Teil befassen wir uns mit der grundlegenden Konfiguration und Bedienung von Tower.

(ID:45369681)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist