AWX auf Kubernetes
Auf Kubernetes installiert sich AWX sehr einfach mithilfe eines Kubernetes-Operators. Der hat Stand Version 0.12.0 nur einen kleinen Fehler im Setup. Das Operator-Setup installiert den benötigten Service-Account "awx-Operator" im Namespace "default". Das mag vielleicht in einer kleinen Minikube-Umgebung oder MicroK8s funktionieren, wo "default" als einziger Namespace zum Einsatz kommt. Wer in einer professionellen Rancher-, CDK-, OpenShift- oder OKD-Umgebung tätig ist, wird seinen AWX-Operator aber nicht in "default", sondern einem anderen Namespace wie "awx" laufen lassen.

Der Operator sucht in diesem Namespace nach dem Serviceaccount und scheitert, wenn der Account unter "default" statt in "awx" liegt. Daher müssen Sie die Datei "awx-operator.yml" vor dem Rollout ändern und an zwei Stellen (ClusterRoleBinding & ServiceAccount) den "namespace" passend zu seiner Umgebung ändern.

Die AWX-Dokumentation definiert für den eigentlichen Applikations-Rollout dann auch eine Host-Route, wie sie nur bei kleinen Demo-Setups mit Minikube oder MicoK8s funktioniert. Für professionelle Umgebungen müssen Sie eine passende Route deklarieren. Hier eine beispielhafte "awx-demo.yml", um eine AWX-Instanz auf OKD/OpenShift zu starten, nachdem der Operator angelaufen ist:

---
apiVersion: awx.ansible.com/v1beta1 kind: AWX
metadata:
   name: awx-demo
kind: Route apiVersion: route.openshift.io/v1 metadata:
   name: awx1-web-svc
spec:
   host: awx.apps.<Openshift FQDN> to:
      kind: Service
      name: awx-demo-service
      weight: 100
   port:
      targetPort: http
wildcardPolicy: None

Dann erstellen Sie entsprechend via oc create -f die Datei "awx-demo.yml" innerhalb des gewünschten Namespaces und starten diese.

AWX via Docker Compose
Die Installation via Docker-Compose bietet ein paar mehr Überraschungen. Dazu gehört, dass AWX innerhalb eines Docker-Containers andere Container via Podman startet. Das mag bizarr erscheinen, ist aber aufgrund der Architektur nicht anders möglich. Schließlich will der AWX-Container ja weitere Runner-Container dynamisch starten können, was bei einer Kubernetes-Umgebung kein Problem darstellt. Aber auf Docker geht das nicht so einfach und so behilft sich AWX damit, dass es Runner innerhalb des Docker-AWX-Containers per Podman startet. Daher verweist das AWX-Team auch dringend darauf, dass AWX auf Docker nur für Tests und Development taugt.

Die Installation verläuft in zwei Stufen: Der erste Schritt generiert einen Build-Container, der aus den AWX-Sourcen erst einmal das aktuelle AWX-Container-Image baut und in der lokalen Registry ablegt. Der zweite Schritt startet via Compose die Umgebung mit einem Redis-, einem Postgres- und dem zuvor gebauten AWX-Container. Der für den Artikel verwendete AWX-Build 19.2.2 kommt mit zwei Deploy-Bugs daher, die sich beide im laufenden Container "tools_awx_1" beheben lassen.

Mit docker exec -ti tools_awx_1 bash gelangen Sie in den Container. In "/etc/ passwd" fehlt der Benutzer "nginx", weswegen der nginx-Reverse-Proxy nicht startet. Legen sie einfach einen nginx-User an, dann lässt sich nginx starten. Alternativ können Sie vor dem Start via Docker Compose das Makefile im AWXGit ändern. Suchen Sie nach den Zeilen:

nginx:
   nginx -g "daemon off;

Und ändern Sie den Eintrag zu:

nginx:
   useradd -g nginx nginx nginx -g "daemon off;

Zudem erscheint spätestens, wenn Sie das erste Projekt per Git synchronisieren möchten, die Fehlermeldung, dass der AWX-Container kein Overlay mounten kann. Hier fügen Sie einfach innerhalb des "tools_awx_1"-Containers in die Datei "/etc/containers/storage.conf " nach dem Divider "[storage.options]" die folgende Zeile ein:

mount_program = "/usr/bin/ fuse-overlayfs"

Beide Bugs sind dem AWX-Team bekannt und möglicherweise bis zum Erscheinen dieses Artikels bereits behoben.

Playbooks für AWX anpassen
Bevor Sie mit AWX beginnen, müssen Sie Ihre bestehenden Playbooks anpassen und in einem oder mehreren Git-Repositories anlegen. Am Anfang werden Sie mit einem Git-Repository, das alle Rollen und Playbooks enthält, gut zurechtkommen. Später verteilen Sie Ihre Automatisierung auf mehrere Repos und Projekte. Entfernen Sie Variablendeklarationen aus den Playbooks, sowohl die "vars:"-Statements als auch "Includes" über "vars_file:". Das gilt vor allem für Passwörter und Secrets.

Wenn Sie Module verwenden, die Zugriff auf Secrets benötigen, schlagen Sie in der Online-Dokumentation nach, wie das jeweilige Modul seine Secrets aus einem Vault bezieht, und passen Sie den Code entsprechend an. Bei Cloud-Rollout- Playbooks beispielsweise für AWS, die Google-Cloud oder vSphere reicht es für gewöhnlich, die Authentisierungs-Schlüsselworte im Playbook einfach wegzulassen. AWX exportiert die Secrets hier als Environment-Variablen und die Module für AWS, Google Cloud oder vSphere greifen automatisch auf das Environment zurück, falls die Authentisierungsdaten nicht in Ansible-Variablen vorliegen.

In AWX arbeiten Sie zudem überwiegend mit dynamischen Inventories, was Sie in Ihren Playbooks und Templates berücksichtigen müssen. Es gibt viele Beispiele für Ansible auf der CLI, die aus Return-Values oder dynamischen Inventories statische Inventory-Dateien schreiben. In AWX nutzen Sie stattdessen eine Variablenübersetzung im Template. In den Extra-Variablen eines Templates weisen Sie dabei cloudunabhängigen Variablen den jeweiligen Wert eines dynamischen Inventories zu.

Für einen Application-Roullout, der sowohl auf AWS und der Google-Cloud funktioniert, definieren Sie in AWX dann zwei Templates, die zwar auf das gleiche Playbook verweisen, aber in den "Extra-Vars" andere Deklarationen nutzen. Ein Beispiel: Im Playbook verwenden Sie die unabhängige Variable "vm_ip" für die externe Adresse der Cloud-VM. Das Template für die Google-Cloud definiert in den "Extra-Vars" des Templates dann

vm_ip: "{{ gce_public_ip }}"

während das Template für AWS auf das gleiche Playbook verweist, in den Extra-Vars aber die Variable anders deklariert:

vm_ip: "{{ public_ip_address }}"

ln/dr/Andreas Stolzenberger

Im dritten Teil der Workshopserie geben wir einige praktische Hinweise zur Automatisierung und werfen einen Blick auf die Tools The Foreman, Katello und Manage IQ. Im ersten Teil gingen wir auf die Vorzüge und die Installation von AWX ein.