Ansible / Teil 7 – Installation und Ersteinrichtung von AWX

In einem meiner vorherigen Beiträge zum Thema Ansible, ging ich auf die Installation von Foreman ein, mit der es möglich ist, Ansible grafisch zu verwalten (https://derlinuxwikinger.de/ansible-teil-2-foreman-als-gui/).
Als weitere Option, Ansible eine GUI zu spendieren, steht AWX zur Verfügung. AWX ist die Open Source Variante des kostenpflichtigen Ansible-Tower. Wie die Installation und die erste Einrichtung aussieht, verrät der folgende Beitrag. Grundlage für meine Installation ist ein Ubuntu-Server 22.04.
Grundsätzlich gibt es 2 unterschiedliche Arten, AWX zu installieren: Mit Docker (bzw. Docker-Compose) und Kubernetes. Ich beschränke mich auf die Installation über Docker.

Installation von AWX

Installiert zunächst einige notwendige Pakete:

sudo apt install docker.io docker-compose ansible

Startet dann den Docker-Dienst und fügt ihn dem Autostart hinzu.

sudo systemctl enable docker
sudo systemctl start docker

Nun klonen wir uns AWX in der neuesten Version von Github.

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

An dieser Stelle ein kurzer Hinweis: AWX benutzt eine Postgres-Datenbank und legt dessen Daten persistent ab. Möchten wir eine solche bereits vorhandene Datenbank nutzen, können wir diese in der Inventory-Datei ./awx/tools/docker-compose/inventory anpassen. Hierfür stehen uns die Parameter pg_host, pg_hostname und pg_username zur Verfügung.
Soll jedoch eine neue Postgres-Datenbank erzeugt werden, überspringen wir diesen Schritt und wechseln in den Ordner awx/.

cd awx/

Von dort aus erstellen wir uns unser Image.

sudo make docker-compose-build

Falls euer System hinter einem Proxy steckt, sollte dieser im Vorfeld in die Docker Konfiguration übertragen werden.

sudo mkdir -p /etc/systemd/system/docker.service.d/
sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf

Fügt folgenden Inhalt in die Datei:

[Service]
Environment="HTTP_PROXY=http://<USERNAME>:<PASSWORD>@<PROXY-IP>:<PORT>"
Environment="HTTPS_PROXY=https://<USERNAME>:<PASSWORD>@<PROXY-IP>:<PORT>"

Ist der Prozess abgeschlossen, sollte das Image gelistet werden können:

sudo docker images

Nun können die Container für AWX, Postgres und Redis gestartet werden:

sudo make docker-compose

Bedenkt, dass sich der Befehlsaufruf nicht in den Hintergrund schiebt und die Kommandozeile dadurch belegt wird. Alternativ können wir den Befehl mit einem Kaufmännischen & abschließen, damit die Shell weiterhin nurtzbar bleibt.

Nun sind alle wichtigen Dienste eingerichtet und gestartet. Es fehlt nur noch die grafische Oberfläche die nun ebenfalls gestartet wird:

sudo docker exec tools_awx_1 make clean-ui ui-devel

Während dieses Aufrufs wird der NPM verwendet. Falls ein Proxy im Weg ist, gilt auch hier, diesen dem NPM innerhalb des Docker Containers bekannt zu machen. Dafür loggen wir uns in den Container ein und setzen ihn:

docker exec -it tools_awx_1
npm config set proxy http://username:password@host:port
npm config set https-proxy http://username:password@host:port

Anschließend rufen wir nochmals den vorherigen Befehl auf:

docker exec tools_awx_1 make clean-ui ui-devel

Ist alles gestartet, lässt sich die grafische Oberfläche unter der Adresse https://localhost:8043/ (oder wahlweise die IP oder den Hostnamen des Servers anstelle von localhost) erreichen.

Vor dem ersten Login wird noch ein Administrator-Konto angelegt:

sudo docker exec -ti tools_awx_1 awx-manage createsuperuser

Der darauf folgende Eingabeprompt verlangt von uns dann Benutzername und Passwort.
Nach erfolgter Eingabe lässt sich dieser Benutzer auch direkt benutzen um die Login-Maske zu überwinden:

Möchten wir AWX auch im Falle eines reboots des Server von alleine wieder starten lassen, legen wir uns hierfür ein Skript an. Beispielsweise unter /opt:

nano /opt/start_awx.sh
chmod +x /opt/start_awx.sh

### Inhalt der Datei /opt/start_awx.sh
#!/bin/bash
cd /<INSTALLATIONSPFAD_VON_AWX>/awx/ && make docker-compose

Passt den Ordner entsprechend eurem Setup an. Nun wird dieses Skript noch über den Cron-Dienst dem Autostart hinzugefügt.

crontab -e

### Fügt folgende Zeile ganz unten der Datei hinzu
@reboot /opt/start_awx.sh

Da die Container für die grafische Oberfläche bereits erstellt wurden, reicht ein make docker-compose als einziger Befehl aus, um AWX zu starten.

Hinzufügen von Hosts und das erste Playbook

Damit wäre die Grundinstallation erledigt und lauffähig. Um mit AWX nun etwas sinnvolles anzustellen, müssen die zu administrierenden Maschinen, mitsamt Playbooks natürlich noch in die Oberfläche überführt werden.
AWX ist in der Lage, mehrere Organisationen zu administrieren. Um eine solche zu erstellen, navigieren über das linke Menüband nach Organizations -> Add -> geben als Namen z.B. Ubuntu organization an und klicken auf Save.

Als nächstes wird ein Inventory erstellt. Diesmal navigieren wir über das linke Menüband nach Inventories -> Add -> Add inventory geben einen Namen z.B. Ubuntu inventory an und klicken wieder auf Save. Sinnvollerweise ließen sich die Hosts, die später diesem inventory hinzugefügt werden, beispielsweise auch nach Abteilungen benennen.

Als nächstes wird der erste Host hinzugefügt und zwar auch wieder über Inventories -> (dem eben erstellten ) Ubuntu inventory -> (über den Tab) Hosts -> Add. Hier kann nun als Name entweder die IP-Adresse oder der jeweilige Hostname angegeben werden.

Stets einzelne Hosts über die grafische Oberfläche einzugeben ist mühsam und dauert immens lange. Um diesen Prozess zu beschleunigen, lässt sich auch die Kommandozeile und das Tool awx-manage verwenden. Hierfür müssen wir uns lediglich Zutritt zum tool_awx_1-Container verschaffen und eine Liste mit den hinzuzufügenden Hosts anlegen.

### Um in den Container zu gelangen
docker exec -it tools_awx_1 /bin/bash

### Wir erstellen folgende Liste
vi ./hosts_add

### Inhalt dieser Liste
192.168.50.51
192.168.50.52

Wichtig ist, dass der Hostname oder die IP-Adressen innerhalb der Liste (in diesem Fall mit dem Namen hosts_add) untereinander geschrieben werden. Anschließend kann sie mit Hilfe des awx-manage Tools eingelesen und dem Inventory Ubuntu inventory hinzugefügt werden:

awx-manage inventory_import --inventory-name "Ubuntu inventory" --source hosts_add

Zurück auf der grafischen Oberfläche, erstellen wir für die neu angelegten Hosts nun noch eine Gruppe und navigieren hierfür über Inventories -> Ubuntu inventory -> dem Tab Groups -> Add -> geben hier als Namen z.B. Ubuntu group ein und klicken auf Save.
Um die Hosts noch dieser Gruppe hinzuzufügen, gehen wir über Inventories -> Ubuntu inventory -> Tab Groups -> (die neu erstellte Gruppe) Ubuntu group -> Hosts -> Add -> Add existing Host -> dann haken wir die gewünschten Hosts zum hinzufügen an und klicken auf Save.

Die Hosts sind sowohl einer Gruppe, als auch direkt dem Inventory zuordenbar.
Jetzt wird eine Verbindungsmethode festgelegt, mit der sich AWX bzw. Ansible auf die Maschinen anmelden soll um die Playbooks auszuführen. Dies legen wir über Credentials -> Add fest. Hier definieren wir einen Namen, beispielsweise SSH-Key, wählen die Organization aus und bestimmen den Credential Type. Da Ubuntu Maschinen standardmäßig keinen direkten root-Zugriff erlauben, müsste man hier mit einer privilege escalation arbeiten und sudo als Option angeben. Das ist prinzipiell möglich, hat in meinen Versuchen aber recht hakelig bzw. gar nicht funktioniert.
Deswegen möchte ich nun einen Verbindungsaufbau per SSH-Key durchführen. Dazu wählen wir als Credential Type Machine und als Benutzernamen root. Anschließend fehlt noch der SSH Private Key der im Vorfeld erstellt und auf die gewünschte Maschine ausgeliefert werden müsste. Ein Klick auf Save speichert auch diese Einstellung.

Damit AWX auch weiß, was ausgeführt werden soll, kümmern wir uns als nächstes um ein Playbook. Hierbei soll ein Playbook dienlich sein, welches Updates für den APT-Paketmanager einspielt.
Bevor wir im UI weiterarbeiten, wird das betreffende Playbook zunächst im Docker Container abgelegt.

### Login in den Docker Container
docker exec -it tools_awx_1 /bin/bash

### Einen Oberordner für die Playbooks erstellen
mkdir /var/lib/awx/projects/updates/

### Und das Playbook dort platzieren
vi /var/lib/awx/projects/updates/apt_update.yml

### Folgender Inhalt wird der Datei hinzugefügt
---
  - hosts: all
    ignore_errors: yes
    ignore_unreachable: yes

    tasks:
    - name: Update apt repositories and cache
      apt: update_cache=yes force_apt_get=yes cache_valid_time=3600

    - name: Update all apt packages
      apt: upgrade=dist force_apt_get=yes

    - name: Remove dependencies that are no longer required
      apt:
        autoremove: yes

Anschließend navigieren wir über Projects -> Add -> definieren einen Namen z.B. Push updates -> wählen die Organization und wählen als Source Control Type den Wert Manual aus. Alternativ lässt sich hier eine alternative Versionierungsmöglichkeit angeben. Als Playbook directory wird der zuvor erstellte Oberordner updates ausgewählt.

Um nun alles miteinander zu verknüpfen, wird ein Job template erstellt werden: Templates -> Add -> Add job template. Neben dem Namen wird als Job Type der Wert Run angegeben, das Inventory, SSH-Key als Authentifizierungsmethode, das eben erzeugte Projekt Push updates und das einzige dort abgelegte Playbook aus diesem Projekt apt_updates.yml.

Schlussendlich wird die Aufgabe über den Menüpunkt Templates gestartet. Dort taucht das eben erstellte Ubuntu template auf. Mit dem Raketensymbol rechts neben dem Namen lässt sich der Job starten.

Wir werden auf eine neue Seite navigiert die uns die Konsolen-Ausgabe präsentiert. Ist alles gut verlaufen, könnte die Ausgabe in etwa so aussehen:

Falls auch hier wieder ein Proxy das Leben schwer zu machen versucht und uns die Konsole mit Fehlermeldungen belästigt, muss der awx-ee Container manuell heruntergeladen werden. Hierfür loggen wir uns wieder auf den Container ein und führen mit Podman das entsprechend pull-Kommando aus:

### Wir loggen uns in den AWX-Container ein ...
docker exec -it tools_awx_1 /bin/bash

### ... und richten den awx-ee Container manuell ein
podman pull quay.io/ansible/awx-ee:latest

Anschließend ist das Template bereit für eine erneute Ausführung.
Damit wäre ein Setup mit den ersten Hosts, Jobs und Playbooks erstellt. Aufbauend darauf, lässt sich dieses Setup natürlich noch beliebig erweitern und automatisieren.