AWX

Seit einigen Jahren beschäftige mich mich mit Ansible, noch länger mit der Automatisierung. Im Laufe der Jahre habe ich sehr viele Lösungen für die Automatisierung in IT Infrastrukturen gesehen und genutzt. Viele hatten etwas gemeinsam: Eine GUI. Ich bin bei weitem kein Verfechter von grafischen Benutzeroberflächen, Ansible bietet eigentlich alles was man benötigt, solange man sich auf der Kommandozeile wohl fühlt. Aber ein Interface zur Steuerung von Ansible Playbook bzw. Jobs, hat mir immer gefehlt.

Es gibt mittlerweile viele Lösungen. RunDeck, oder Semaphore, um nur zwei Alternativen zu AWX für Ansible zu nennen. Aber AWX ist schließlich ein Upstream Projekt der Red Hat Ansible Automation Platform – genauer gesagt das, was was später der Ansible Controller im AAP ist. Warum also nicht direkt auf das „Original“ setzen. Schließlich stammt Ansible aus dem gleichen Haus.

Leider befindet sich das AWX Projekt derzeit in einer Art Freeze-Zustand. Der letzte Release (24.6.1) ist von Sommer 2024. Der Grund ist, dass das gesamte Projekt von Grund auf überarbeitet wird. Ich empfehle dennoch, zumindest noch, AWX als Alternative zum AAP, wenn Ansible im großen Stil in Infrastrukturen eingesetzt wird. Die Basis-Installation ist denkbar einfach (dank Operator und Container-Deployment) und ich glaube nicht, dass sich die Platform im Kern komplett verändern wird. Dafür ist die Lösung zu weit verbreitet.

AWX Operator

Die Installation auf Kubernetes erfolgt mittels des sogenannten Operator. Dieser führt das das Deployment von AWX auf Kubernetes aus. Hierbüber laufen auch Updates und Lifecyles. Genau wie AWX selbst, ist der letzte Release (2.19.1) von Sommer 2024.

Ich habe mich lange und viel zu viel damit auseinandergesetzt, wie man AWX mit HTTPS Zugriff installiert. Zudem habe ich mich in eine falsche Richtung bewegt (Spoiler: Die eigene Unwissenheit über K8s war der Grund). In den nächsten Artikeln werde ich darauf genauer eingehen. Hier und jetzt zeige ich nur, wie AWX simpel und einfach auf einer K8s Umgebung deployed werden kann. Einzige Besonderheit: Ich verwende einen bereits bestehenden dedizierten PostgreSQL Server. Dadurch ist das AWX Deployment schmaler und man benötigt keinen separates persistant volume.

Die Installation des Operators ist super simpel.

Das Git-Projekt klonen:

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

In das Verzeichnis wechseln und auf den Branch des letzten Release wechseln:

cd awx-operator  
git checkout 2.19.1

Den Operator bzw. die Pods deployen:

make deploy

Nach kurzer Zeit sollten zwei Operator Pods zu sehen sein:

Ab diesem Punkt ist man bereits in der Lage eine AWX Instanz zu installieren.

Einrichten der PosgreSQL Datenbank

Erstellen der Datenbank und des Users:

CREATE DATABASE awx;

CREATE USER awx WITH ENCRYPTED PASSWORD 'xyz';

GRANT ALL PRIVILEGES ON DATABASE awx TO awx;

ALTER DATABASE awx OWNER TO awx;

Listener Address für PostgreSQL anpassen (postgresql.conf):

Kann natürlich enstprechend der eigenen Bedürfnisse und Sicherheitsansprüche verändert werden.

Zugriffe auf den DBMS und die Datenbank erlauben (pg_hba.conf):

Auch hier gilt: Bitte entsprechend der eigenen Umgebung anpassen. In meinem Fall reicht diese Konfiguration vollkommen aus, da es sich um eine abgeschottete Testinfrastruktur handelt.

Damit die AWX Pods auf die PostgresSQL Datenbank zugreifen zu können, muss ein secret erstellt werden.

nano awx-postgres-secret.yml

apiVersion: v1
kind: Secret
metadata:
 name: sos-awx-postgres-configuration
 namespace: awx
data:
 host: xyz              # “IP of Host” (base64)
 port: NTQzMg==         # “5432” (base64)
 database: YXd4         # “awx” (base64)
 username: YXd4         # “awx” (base64)
 password: xyz          # “yourpassword” (base64)
 type: dW5tYW5hZ2Vk     # “unmanaged” (base64)
 sslmode: ZGlzYWJsZQ==  # “disable” (base64)
type: Opaque

Die Werte muss man entsprechend anpassen. Alle Werte sind base64 Strings.

Sytnax um einen base64 verschlüsselten String zu erstellen:

echo -n 'mystring' | base64

Secret erstellen:

kubectl apply -f awx-postgres-secret.yml

AWX Instanz Deployment

Damit sind bereits alle Vorbereitungen für ein AWX Deployment abgeschlossen. An dem folgenden Teil habe ich mir lange die Zähne ausgebissen, u.a. wegen LoadBalancern, Ingress, HTTPS uvm. Am Ende kann man aber sagen: Folgendes Manifest für das Deployment reicht vollkommen aus:

nano ansible-awx-ext-db.yml

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: ansible-awx
  namespace: awx
spec:
  service_type: nodeport
	nodeport_port: 30080
  postgres_configuration_secret: sos-awx-postgres-configuration

Im Grunde sagt das auch die Dokumentation.

Mehr benötigt man nicht. Der Typ, Name, Namespace und der Service Typ – in diesem Fall einfach als Nodeport. Was das bedeutet, sieht man gleich nach dem Deployment. Der Wert „postgres_configuration_secret“ gibt das secret an, welches für die Datenbank-Verbindung erstellt wurde.

AWX ausrollen:

kubectl apply -f ansible-awx-ext-db.yml

Nach einiger Zeit sollten drei Deployments mit mehreren Pods zu sehen sein:

Bei Bedarf, kann man sich die Logs des Deployments im Operator anschauen:

kubectl -n awx logs -f deployments/awx-operator-controller-manager

Der Operator hat jetzt aber nicht nur die Pods installiert, sondern auch einen neuen Service erstellt (vom Typ NodePort). Diesen kann man sich anzeigen lassen:

kubectl get svc -n awx

Hier sieht man, dass der Service auf Port 30080 nach außen und auf 80 nach innen (auf die Pods) läuft. So wie im Manifest angegeben.

Um herauszubekommen, wie man nun auf AWX zugreifen kann, muss man schauen, auf welchem K8s Worker-Node der entsprechende Pod (web) läuft:

kubectl get pods -n awx -o wide

In diesem Fall: kube02 – mein zweiter Worker-Node.

Der Aufruf kann also per

http://[IP kube02]:30080

erfolgen.

Das initiale Admin-Passwort erhält man folgendermaßen:

kubectl get secret ansible-awx-admin-password -o jsonpath="{.data.password}" -n awx | base64 --decode ; echo

Nach der Anmeldung lässt sich dies normal ändern.

That’s it 🙂 An dieser Stelle kann man AWX bereits vollumfänglich nutzen.

Da ich auch intern meine Services auf HTTPS laufen lasse, wollte ich AWX natürlich ebenso mit einem SSL Zertifikat austatten. Hierzu komme ich in einem nachfolgenden Artikel. Die Einrichtung von AWX (Repos, Projects usw.) folgt anschließend.