AWX und GitLab Webhooks

Tools wie AWX und Ansible Automation Platform sind mittlerweile in einer großen Organisation nicht mehr wegzudenken, um eine große Menge an Ansible-Projekten zu verwalten. Sie bieten die Möglichkeit, Ansible-Code aus verschiedenen Quellen zu beziehen, Jobs zu planen, Credentials und Rechte für verschiedene User in der Organisation zu verteilen und vieles mehr. Wir empfehlen, den Ansible-Code in einem Versionskontrollsystem zu verwalten, insbesondere Git. Für Funktionen jenseits der reinen Versionsverwaltung gibt es verschiedene Plattformen. Für diesen Artikel spielt GitLab eine zentrale Rolle.

Ansible-Schulung

Unsere Ansible-Schulungen sind ideal für alle, die mit Ansible beginnen möchten oder bereits über einige Erfahrung verfügen. “Ansible Fundamentals” eigent sich für Teilnehmende, die bisher keine oder nur wenig Erfahrung mit Ansible haben. Das “Advanced Training” richtet sich an alle, die bereits erste Erfahrungen mit Ansible gesammelt haben und ihr Wissen vertiefen möchten. Nach Abschluss des Kurses sind die Teilnehmenden in der Lage, Ansible selbst produktiv zu verwenden.

Mehr erfahren

Die Kombination von AWX/Ansible Automation Platform und GitLab bietet die zusätzliche Möglichkeit, mit Webhooks zu arbeiten, um den eigenen Workflow noch weiter zu automatisieren: Sobald man eine neuere Version des Codes pusht, triggern diese Webhooks AWX oder die Ansible Automation Platform, mit dem neuen Code zu arbeiten. Dies möchte ich in diesem Artikel ausführlich erklären. Die Beispiele gehen auf das Arbeiten mit Webhooks anhand von AWX ein, aber das lässt sich leicht auf das Enterprise-Produkt Ansible Automation Platform übertragen. Eine Einführung über beide Tools gibt es in unserem Blogeintrag dazu.

Die Grundeinheit in AWX bilden Projekte. Ein Projekt ist eine Sammlung von Ansible-Code. Als Quellen lässt AWX verschiedene Möglichkeiten zu: Zum Beispiel kann man den Code einfach direkt auf dem Rechner, auf dem AWX installiert ist, ablegen oder ein Archiv angeben, das man über das Internet erreichen kann.
Die weitaus bessere Option ist aber, den Code mit Git zu versionieren und direkt aus GitHub oder GitLab zu importieren. In diesem Fall kann man auch entscheiden, aus welchem Branch man den Code beziehen möchte und/oder welche Tags oder Commits man nutzen will. Nachdem ein solches AWX-Projekt erstellt ist, kann man davon ein AWX Job Template ableiten. Hierzu wählt man unter anderem ein Playbook aus, das im Projekt enthalten ist.

Bei einem Job Template gibt es auch die Möglichkeit, Webhooks zu aktivieren. Webhooks sind Callbacks, die beim Eintreten eines Ereignisses ausgerufen werden, um eine andere Anwendung mit einem HTTP POST Request zu informieren und eine Reaktion auszulösen. Dies hat den Vorteil, dass die Anwendung keine zyklische Abfrage tätigen muss, um das Ereignis mitzubekommen, wodurch die Kommunikation so knapp wie möglich gehalten wird.

Seinerseits kann GitLab Webhooks ansprechen. Das heißt, dass man zum Beispiel ein GitLab Repository so konfigurieren kann, dass AWX automatisch informiert wird, sobald neuer Code gepusht wird. Die neue Version des Codes wird dann auf einer Test-Node ausgeführt.

Das Einrichten solcher Webhooks muss sowohl auf der AWX- als auch auf der GitLab-Seite erfolgen.

Zuerst muss man bei dem Job, den man triggern möchte, die Box „Enable Webhook“ und GitLab als Webhook-Service auswählen. AWX füllt dann die „Webhook URL“ und den „Webhook Key“ automatisch aus. Wenn man will, dass AWX Statusupdates an GitLab zurücksendet, sollte man zusätzlich erst einen Personal Access Token für das entsprechende Repository in GitLab erzeugen, dann diesen als Credentials vom Typ GitLab Personal Access Token in AWX hinterlegen und ihn letztendlich als „Webhook Credentials“ für das Job Template angeben.

Auf der GitLab-Seite kann nun der Webhook eingerichtet werden. Dazu geht man unter Settings auf Webhooks und gibt die von AWX erhaltene URL und den URL Key an. Außerdem kann man entscheiden, welche Ereignisse den Webhook auslösen sollen: Push Events bieten sich bei einem typischen AWX Workflow an, es gibt aber noch viele andere Möglichkeiten.

Nach dem Speichern ist es dann soweit: Man kann etwas ins Repository pushen und beobachten, wie der Job automatisch in AWX startet. Zusätzlich enthält der Job Output alle Variablen, die durch den Webhook übergeben wurden, wie zum Beispiel event_type, repository und commits.