Seite wählen

NETWAYS Blog

Ansible und Terraform: Die Hochzeit des Jahrzentes?

Ansible und Terraform sind wichtige Werkzeuge im DevOps-Werkzeugkasten und gehören genauso zusammen wie der Hammer und der Schraubendreher.

Was sind Ansible und Terraform überhaupt?

Ansible ist ein Open-Source-Tool zur Automatisierung von IT-Aufgaben wie Konfigurationsmanagement und Anwendungsbereitstellung. Über sogenannte Playbooks können Aufgaben definiert werden, die den gewünschten Zustand von Systemen beschreiben. Es nutzt SSH-Verbindungen (für Linux), um diese Zustände umzusetzen, und erfordert keine Installation von Agenten auf den Zielhosts, was die Einrichtung und Verwendung von Ansible sehr einfach macht.

Im Gegensatz dazu ist Terraform ein Open-Source-Tool, das zur Bereitstellung und Verwaltung von Infrastruktur as Code (IaC) verwendet wird. Entwickler- und Administratorenteams können mit Terraform Infrastrukturressourcen wie VMs, Netzwerkkonfigurationen und Speicherressourcen in verschiedenen Cloud- und On-Premises-Umgebungen definieren, konfigurieren und verwalten. Ähnlich wie Ansible verwendet Terraform einen deklarativen Ansatz, um den gewünschten Zustand der Umgebung zu beschreiben. Anschließend kümmert sich Terraform darum, diesen Zustand zu erstellen, indem die erforderlichen Komponenten bereitgestellt oder aktualisiert werden.

Ähnlich, aber nicht gleich

Es gibt wichtige Unterschiede zwischen den beiden Tools:

  • Ansible ist hauptsächlich ein Konfigurationsmanagement-Tool. Es automatisiert die Bereitstellung von Softwareanwendungen, Konfigurationen und Systemzuständen auf vorhandenen Infrastrukturressourcen.
  • Terraform hingegen ist spezialisiert auf die Bereitstellung und Verwaltung von Infrastrukturressourcen selbst. Es fokussiert sich darauf Cloud-Dienste zu konfigurieren und zu verwalten.

In anderen Worten: Terraform konzentriert sich auf die Bereitstellung und Verwaltung der Infrastruktur, während Ansible sich um die Konfiguration bestimmter Infrastruktur komponeten kümmert.

Da beide Tools unterschiedliche Bereiche automatisieren, die jedoch eng miteinander verbunden sind, ist es wichtig zu wissen, wie man sie optimal gemeinsam einsetzen kann. Dazu gibt es mehrere Ansätze:

Der Manuelle Weg

Ein bisschen paradox, dass ich die ganze Zeit von Automatisierung rede und jetzt einen Manuellen Weg vorstelle, nicht wahr? Deswegen dient dieser Absatz nur der Vollständigkeit und ich würde jedem raten, sich für einen der anderen Ansätze zu entscheiden.

Dennoch ist es natürlich klar, dass man Terraform und Ansible auch per Hand verheiraten kann. Das sieht dann ungefähr so aus:

  • Man schreibt ein Terraform-Skript. Hier habe ich jetzt ein kleines Beispiel (welches ich auch in den anderen Beispielen als Grundlage verwenden werde), um einen virtuellen Server bei [DigitalOcean](https://www.digitalocean.com/) (Droplet) zu erstellen:
terraform {
  required_providers {
    digitalocean = {
    source = "digitalocean/digitalocean"
    version = "~> 2.0"
    }
  }
}

resource "digitalocean_droplet" "test" {
  image = "debian-12-x64"
  name = "manual-way"
  ...
}

Ich habe hier mithilfe des Digital Ocean Providers sehr einfach meinen SSH-Key ablegen können. Die meisten Provider haben entweder ein SSH-Key-Attribut oder bieten Cloud-Init an (Das Attribut heißt dafür oft `user_data`). Es macht Sinn, den SSH-Key, mit dem man dann Ansible verwendet, direkt hier mitzugeben. So spart man sich einen manuellen Schritt. Es macht allerdings nicht so viel Sinn, darüber alle SSH-Keys zu verwalten, da das Ändern dieses Attributes oft zur Neuinstallation des Servers führt.

  • Anschließend provisioniert man die Infrastruktur mittels folgenden Terraform-Befehlen – terraform init, terraform plan, terraform apply.
  • Nun müssen wir darauf warten, dass die Infrastruktur bereitgestellt ist, Terraform, je nach Provider dauert das unterschiedlich lang.
  • Anschließend ermitteln wir die IP-Adresse des Servers. Dies kann entweder über einen Terraform-Output erfolgen oder durch Überprüfen der API oder der Oberfläche von Digital Ocean.
  • Mit dieser IP-Adresse erstellen wir nun ein Inventar. Alternativ können wir zuvor einen DNS-Eintrag für diese IP-Adresse setzen oder die IP-Adresse direkt verwenden.

Inventory.yml:

---
all:
  hosts:
    manual-ansible.netways.de:

Ich habe einen DNS-Eintrag verwendet (den kann ich bei einigen DNS-Providern auch per Terraform erstellen!).

Jetzt müssen wir das Playbook schreiben und auf das neue Inventory ausführen.

Playbook.yml:

---
- name: Lets see what we can do
  hosts: all
  tasks:
    - name: Lets run an apt update / apt upgrade task
      ansible.builtin.apt:
        upgrade: True
        update_cache: True
ansible-playbook -i inventory.yml playbook.yml

Output:

PLAY [Lets see what we can do] ****************

TASK [Gathering Facts] ****************
ok: [manual-ansible.netways.de]

TASK [Lets run an apt update / apt upgrade task] ****************
changed: [manual-ansible.netways.de]

PLAY RECAP ****************
manual-ansible.netways.de : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Das war ganz schön viel Arbeit. Aber wie geht es einfacher? Und welche Möglichkeiten gibt es, die beiden Tools zu verheiraten?

Ansible Provider und Terraform Plugin

Mithilfe des Ansible-Providers von Terraform und der cloud.terraform-Collection für Ansible kann man aus Terraform-Skripten dynamische Inventories erstellen.

Dazu erweitern wir das Terraform-Skript aus dem manuellen Beispiel:

terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
    ansible = {
      version = "~> 1.2.0"
      source  = "ansible/ansible"
    }
  }
}

resource "digitalocean_droplet" "web" {
  image  = "debian-12-x64"
  name   = "married-way"
  ...
}

resource "ansible_host" "web" {
  name = digitalocean_droplet.web.ipv4_address
  groups = ["web"]
  variables = {
    ansible_user = "root"
  }
}

Dank des Ansible Providers ist es möglich, die IP-Adresse des gerade erstellten Droplets direkt zu nutzen. Der Ansible-Provider generiert ein Inventar, das es ermöglicht, Hosts direkt Gruppen zuzuweisen und Host-Variablen festzulegen.

Wenn wir nun in die Terraform-State-Datei schauen, sehen wir folgende Resource:

"resources": [
    {
      "mode": "managed",
      "type": "ansible_host",
      "name": "web",
      "provider": "provider[\"registry.terraform.io/ansible/ansible\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "groups": [
              "web"
            ],
            "id": "10.0.0.1",
            "name": "10.0.0.1",
            "variables": {
              "ansible_user": "root"
            }
          },
          ...
        }
      ]
    },

Um das Inventory zu erstellen, müssen wir die cloud.terraform-Collection installieren:

ansible-galaxy collection install cloud.terraform

Dann können wir ein Inventory-File erstellen, das wie folgt aussieht:

---
plugin: cloud.terraform.terraform_provider
project_path: ../terraform

Jetzt können wir uns das Inventory ansehen, das Ansible verwenden würde:

$ ansible-inventory -i inventory.yml --graph --vars
@all:
  |--@ungrouped:
  |--@web:
  |  |--10.0.0.1
  |  |  |--{ansible_user = root}

Jetzt können wir unser Beispiel-Playbook wieder ausführen:

$ ansible-playbook -i inventory.yml playbook.yml 

PLAY [Let's see what we can do] ***************

TASK [Gathering Facts] ***************
ok: [10.0.0.1]

TASK [Lets run an apt update / apt upgrade task] ***************
changed: [10.0.0.1]

PLAY RECAP ***************
10.0.0.1               : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Vorteile:

  • Wir müssen das Inventory nicht manuell anpassen.
  • Wir können die Parameter aus Terraform direkt an das Inventory übergeben.

Nachteile:

  • Alle Ressourcen in Terraform müssen doppelt angelegt werden.
  • Das Inventory-Plugin unterstützt keine Remote-States, was das Arbeiten im Team erschwert.

Terraform-Modul

Mithilfe des Terraform-Moduls für Ansible kann man Terraform-Skripte ausführen. Das Terraform-Skript in diesem Beispiel ist das gleiche wie im manuellen Beispiel.

Das Playbook:

- name: Deploy a DigitalOcean Droplet
  hosts: localhost
  tasks:
    - name: Deploy
      community.general.terraform:
        project_path: ../terraform
        state: present
$ ansible-playbook playbook.yml 
PLAY [Deploy a DigitalOcean Droplet] ***************

TASK [Gathering Facts] ***************
ok: [localhost]

TASK [Deploy] ***************
changed: [localhost]

PLAY RECAP ***************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Und…. jetzt?
Jetzt ist die VM da, aber wir müssen die VM bzw. den Hostnamen wieder herausfinden. Eigentlich hat dieses Plugin einen anderen Anwendungsfall. Es macht Sinn, es zu verwenden, wenn ich Cloud-Services, die keine weitere Konfiguration durch Ansible benötigen, anlegen und diese in meiner Ansible-Struktur abbilden möchte.

Ein Terraform-Destroy sieht hier übrigens so aus:

- name: Destroy a DigitalOcean Droplet
  hosts: localhost
  tasks:
    - name: Destroy
      community.general.terraform:
        project_path: ../terraform
        state: absent

Fazit

So richtig zufrieden bin ich mit den Möglichkeiten, die es bisher gibt, nicht. Ein dynamisches Inventory aus dem Terraform-State zu erstellen, ist schon mal die richtige Richtung, aber alle Ressourcen doppelt erstellen zu müssen, widerspricht ein wenig der Idee von Terraform. Außerdem sorgt es für eine hohe Korrelation zwischen den beiden Tools. Wenn man jetzt zum Beispiel Ansible durch Puppet austauscht, muss man die gesamte Terraform-Struktur anpassen.

Dennoch sollten wir nicht vergessen, wo die Stärken und Schwächen der einzelnen Tools liegen. Vielleicht hat ja jemand von euch jetzt die Idee, wie wir Ansible und Terraform am besten verheiraten können. Und wenn ihr es geschafft habt, ladet mich doch bitte zur Hochzeit ein!

Lucy Siemer
Lucy Siemer
Consultant

Lucy ist seit Mai 2023 bei NETWAYS als Consultant tätig, nachdem sie im Jahr 2022 ihre Ausbildung zur Fachinformatikerin für Systemintegration erfolgreich abgeschlossen hat. Ihre Schwerpunkte liegen auf den Bereichen Kubernetes, Infrastructure as Code und Monitoring. Neben ihrer Arbeit bei NETWAYS betreut Lucy auch privat ihre eigene Infrastruktur auf Kubernetes. Darüber hinaus ist sie leidenschaftlich daran interessiert, eigene Kleider zu nähen und individuelle Designs zu kreieren.

NETWAYS stellt sich vor – Lucy Siemer

This entry is part 57 of 64 in the series NETWAYS stellt sich vor

Name: Lucy Siemer

Alter: 23

Studium/Ausbildung: Fachinformatikerin für Systemintegration

Position bei NETWAYS: Consultant

Bei NETWAYS seit: Mai 2023

 

 

Wie bist Du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich?

Nach der OSMC 2022 bin ich mit ein paar NETWAYS Kolleg:Innen in Kontakt geblieben. Diese haben mir viel von der NETWAYS-Kultur und -Arbeitsweise erzählt, die mir sofort gefallen hat. Da ich sowieso auf Jobsuche war, hab ich mich einfach mal beworben. Und siehe da, It’s a match!

Die Kollegen haben mich direkt am Anfang in eine Elasticstack-Schulung gesteckt, das Thema hat mir gut gefallen, deswegen unterstütze ich dort bereits einige Kunden. Auch bei den Themen Kubernetes, Docker und Infrastructure-as-Code Lösungen mit Ansible und Terraform stehe ich mit Rat und Tat zur Seite.

Des Weiteren halte ich auch die ein oder andere Schulung, was mir sehr viel Spaß macht.

 

Welche größeren, besonders interessanten Projekte stehen künftig an?

Gerade überarbeite ich zusammen mit den anderen Trainern die Elasticstack-Schulung, die ich demnächst auch halten werde. Auch auf der bevorstehenden stackconf werde ich tiefer involviert sein, da gilt es aber noch herauszufinden, was ich genau machen darf.

 

Wie gefällt es Dir bisher bei NETWAYS?

Wunderbar! Am besten gefallen mir bisher, ganz klar, die Leute. Meine Kolleg:Innen sind die nettesten Menschen, mit denen ich je gearbeitet habe. Die Aufgaben sind spannend und abwechslungsreich, und trotzdem wird mir genug Zeit eingeräumt, um mich weiter zu bilden.

 

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Reisen – eins meiner Lebensziele ist es, so viel von der Welt zu sehen, wie ich kann! Wenn ich mal Zuhause bin, nutze ich meine kreative Energie, um schöne Kleider zu schneidern. Vielleicht traue ich mich demnächst auch an kompliziertere Kleidungsstücke.

Ansonsten ist die IT natürlich nicht nur Beruf, sondern auch Hobby. Ich verwalte ein kleines Kubernetes-Cluster mit einigen Tools, die mal mehr, mal weniger Liebe benötigen. Als nächstes installiere ich einen AWX, um meine Playbooks kontinuierlich gegen das Cluster laufen zu lassen. Der nächste Schritt sind dann automatisierte Tests, um das Cluster und die Tools später automatisiert updaten zu können!

 

Wie geht es in Zukunft bei Dir weiter?

Ach, wer weiß das schon. Ich hoffe, mich mehr in Richtung Infrastructure as Code zu bilden, um Kunden auch bei architekturellen Fragen zur Seite stehen zu können, und um größere Umgebungen zu automatisieren.

Außerdem würde ich gern den ein oder anderen Talk halten, vielleicht ja auf der stackconf oder der OSMC 2024? Wir werden sehen.

Lucy Siemer
Lucy Siemer
Consultant

Lucy ist seit Mai 2023 bei NETWAYS als Consultant tätig, nachdem sie im Jahr 2022 ihre Ausbildung zur Fachinformatikerin für Systemintegration erfolgreich abgeschlossen hat. Ihre Schwerpunkte liegen auf den Bereichen Kubernetes, Infrastructure as Code und Monitoring. Neben ihrer Arbeit bei NETWAYS betreut Lucy auch privat ihre eigene Infrastruktur auf Kubernetes. Darüber hinaus ist sie leidenschaftlich daran interessiert, eigene Kleider zu nähen und individuelle Designs zu kreieren.

Semaphore, Rundeck oder AWX – Welches Tool eignet sich als Ansible-GUI?

Rundeck, AWX und Ansible Semaphore sind nützliche Tools zur Arbeit mit Ansible. Als Ansible-GUI lösen lösen sie die Arbeit mit Ansible von der Konsole und geben auch Fans grafischer Optionen die Möglichkeit Ansible voll auszukosten.
In meinem ersten Blogpost für NETWAYS habe ich dir bereits Ansible Semaphore vorgestellt. Dabei sind jedoch einige Fragen offen geblieben oder mir erst bei der Arbeit am Artikel gekommen:

  • Wofür ist Semaphore es das richtige Tool?
  • Was sind die Alternativen?
  • Welches Tool eignet sich am besten als Ansible-GUI

Um diese Fragen zu beantworten, werfe ich in diesem Blogpost einen Blick auf die Semaphore Alternativen Rundeck und AWX, gehe auf (aus meiner Sicht) Vor- und Nachteile ein und gebe dir am Ende mein persönliches Fazit.

Grafische Ansible Automatisierung mit Rundeck

Was ist Rundeck?

Rundeck ist eine Open-Source-Automatisierungsplattform, die dir hilft deine Automatisierungen zu verwalten und zu planen. Rundeck kann jedoch noch viel mehr als nur das Ausführen von Ansible-Playbooks, zum Beispiel das Ausführen von Remote-Befehlen oder Skripten.

Um Rundeck zu installieren stehen dir verschiedene Möglichkeiten zur Verfügung:

  • Docker-Container
  • RPM- / DEB-Paket
  • WAR-Datei auf Windows

Bei der RPM- / DEB-Installation gibt es zudem einen weiteren Punkt der beachtet werden muss: du musst den Service als initd-Skript starten.
Neben den verschiedenen Installationsmöglichkeiten verfügt Rundeck auch über einen Terraform-Provider. Damit kannst du zusätzlich deine Projekte, Jobs, ACL-Policies und SSH-Keys verwalten.

Um Ansible-Playbooks mit Rundeck auszuführen, muss Ansible auf dem Server installiert sein. Anschließend kannst du Inventories importieren und Playbooks ausführen. Vergiss dabei aber nicht, dass die Dateien die du ausführen willst lokal auf auf dem Server liegen müssen.

Versionen von Rundeck

Rundeck ist als Community-Version, Enterprise-Version und Cloud-Version verfügbar.
Bei der Cloud-Version handelt es sich um eine gemanagte SaaS-Lösung mit allen Funktionen der Enterprise-Version. Die Rundeck Enterprise-Version bietet unter Anderem die Möglichkeit zur Verwendung der Single-Sign-On-Authentifizierung, während die kostenlose Version LDAP– und PAM-Integration bietet.
High Availability durch Cluster-Betrieb und ACL-Management über die Benutzeroberfläche ist ebenfalls nur in der Enterprise-Version verfügbar.

Was gibt es sonst noch?

Zusätzlich zu Ansible bietet Rundeck weitere sogenannte „Node Executioners„, die die Remote-Konfiguration ermöglichen, z. B. einen WinRM/Powershell Executioner, mit dem PowerShell-Skripte remote ausgeführt werden können.
Oder den AWS Elastic Container Service (ECS) Node Executor (in der Enterprise-Version), der Befehle auf Amazon ECS-Containern ausführen kann.

Die Konfiguration, um Ansible verwenden zu können, war für mich relativ aufwändig. Ich hatte Probleme mich in der Benutzeroberfläche zurechtzufinden, denn das Anlegen von Nodes ist beispielsweise relativ versteckt, während das Anlegen von Jobs einfach im Job-Tab möglich ist. Dadurch hat es mich ein wenig Zeit gekostet bis ich „Nodes“ (Hosts) und „Jobs“ (die auszuführenden Playbooks) anlegen konnte.

Das gesagt, kommen wir zu meinen persönlichen Vor- und Nachteilen von Rundeck:

Vorteile von Rundeck

  • Einfache Installation
  • Kann viel mehr als nur Ansible
  • Teilweise über Terraform verwaltbar

Nachteile von Rundeck

  • Unübersichtliche und unintuitive Benutzeroberfläche

Grafische Ansible Automatisierung mit AWX

Was ist AWX?

AWX ist ein Open-Source-Projekt, das ein grafisches Interface und eine REST-API bereitstellt, die auf Ansible aufbauen. Das Projekt wird von Red Hat mitfinanziert und ist eines der Upstream-Projekte für die Red Hat Ansible Automation Platform.

AWX muss in einem Kubernetes-Cluster installiert werden. Es besteht zwar die Möglichkeit, es mit Docker Compose zu installieren, dies wird jedoch nur zu Testzwecken empfohlen.

Die Konfiguration erfolgt entweder über die Benutzeroberfläche oder mithilfe der AWX Ansible Collection.

Wie AWX funktioniert

Ansible Playbooks und Inventories können aus Git-Repositories (öffentlich und privat) eingelesen oder lokal auf dem Rechner abgelegt werden. Inventories können klassisch als INI- oder YAML-Datei oder aus verschiedenen Quellen als dynamische Inventories (z. B. OpenStack, AWS EC2 usw.) importiert werden.
Dynamische Inventories, für die es Plugins gibt, die AWX jedoch noch nicht nativ unterstützt, können als normale Inventory-Dateien eingebunden werden.

Für die Authentifizierung bietet AWX folgende Methoden:

  • GitHub OAuth
  • Google OAuth 2
  • LDAP
  • SAML
  • Generic OIDC

Persönlich finde ich, dass die Benutzeroberfläche von recht intuitiv zu bedienen ist und im Gegensatz zu anderen GUIs nicht überladen wirkt. Damit kommen wir zu den Vor- und Nachteilen von AWX:

Vorteile von AWX

  • Wird größtenteils von der Ansible-Community entwickelt und ist daher sehr eng mit Ansible verbunden
  • Bietet die gängigsten Authentifizierungsmethoden
  • Relativ einfach zu bedienen
  • Ist als Code konfigurierbar

Nachteile von AWX

  • Das Betreiben von AWX in einem Kubernetes-Cluster kann überwältigend sein, wenn man noch keine Erfahrung mit Kubernetes hat

Fazit

Nun habe ich dir in meinen beiden Blogbeiträgen einen groben Überblick über Semaphore, Rundeck und AWX gegeben. Jetzt bleibt mir nur noch übrig die Fragen vom Anfang zu beantworten!

Wofür ist Ansible Semaphore das richtige Tool?
Ich würde dir Semaphore empfehlen, wenn du eine Benutzeroberfläche möchtest, auf der du regelmäßig Playbooks ausführen willst. Die Infrastruktur die du damit verwalten willst sollte jedoch noch nicht allzu groß sein, da es sonst unübersichtlich werden könnte.

Für wen eigenet sich Rundeck?
Rundeck
bietet dir zwar mehr Möglichkeiten als Ansible, ist aber relativ unübersichtlich.
Rundeck ist die richtige Plattform für dich, wenn deine zu verwaltende Infrastruktur so vielfältig ist, dass neben Playbooks auch Skripte und Befehle verwaltet und geplant werden sollen.

Und was ist mit AWX?
AWX
ist aufgrund der Nähe zu Ansible und der verbesserten Konfigurationsmöglichkeiten (Konfiguration als Code durch Ansible) die Plattform der Wahl.
Besonders wenn du größere Infrastrukturen mit Hilfe von Ansible verwalten willst oder in deiner Infrastruktur bereits ein Kubernetes im Einsatz ist.

 

Ich hoffe dass ich dir mit meinen beiden Blogposts eine kleine Entscheidungshilfe geben konnte, wenn du vor der Frage stehst, welches GUI-Tool für Ansible du nutzen willst.
Wenn du darüber hinaus Hilfe bei Themen rund um Ansible, Automatisierung oder andere spannende Open Source Themen suchst, freuen ich und meine Kolleg:innen uns auf deine Nachricht!

Lucy Siemer
Lucy Siemer
Consultant

Lucy ist seit Mai 2023 bei NETWAYS als Consultant tätig, nachdem sie im Jahr 2022 ihre Ausbildung zur Fachinformatikerin für Systemintegration erfolgreich abgeschlossen hat. Ihre Schwerpunkte liegen auf den Bereichen Kubernetes, Infrastructure as Code und Monitoring. Neben ihrer Arbeit bei NETWAYS betreut Lucy auch privat ihre eigene Infrastruktur auf Kubernetes. Darüber hinaus ist sie leidenschaftlich daran interessiert, eigene Kleider zu nähen und individuelle Designs zu kreieren.

Was ist Ansible Semaphore?

Als Open Source Consultants müssen meine Kolleg:innen und ich uns regelmäßig mit neuen Technologien, Tools oder anderen Neuerungen auseinandersetzen. Dabei testen wir besonders neue Software die uns und unseren Kund:innen das Leben potenziell leichter machen können oder Tools, die gerade einen Hype erfahren. Dadurch können wir qualifiziert entscheiden, was wir in unsere tägliche Arbeit einfließen lassen und was nicht. Das Tool mit dem ich in den letzten Tagen beschäftigt habe ist Ansible Semaphore, das ich euch in meinem ersten Blogbeitrag für NETWAYS vorstellen darf.

Was ist Ansible Semaphore?

Semaphore ist eine Web-UI, in der Ansible-Playbooks ausgeführt und geplant werden können. Es bietet eine Übersicht über vorhandene Playbooks und Inventories sowie eine Funktion zur Planung von regelmäßigen Tasks. Außerdem werden auf dem Dashboard Informationen angezeigt, wann welche Tasks zuletzt ausgeführt wurden und ob sie erfolgreich waren. Um dir einen Überblick über Semaphore zu geben, gehe ich im Folgenden auf die wichtigsten Elemente ein stelle sie dir vor.

Installation von Semaphore

Semaphore ist als Snap, Deb oder RPM Paket verfügbar. Damit bedienen die Entwickler:innen alle gängigen Betriebssysteme. Zudem stellt Semaphore eine Docker-Compose-Datei bereit, um es als Docker-Container zu installieren. Die einzelnen Schritte für jede Installationsform in diesem Blogpost zu veröffentlichen würde den geplanten Rahmen sprengen. Deshalb verweise ich hier sehr gerne auf die offizielle Ansible Semaphore Installationsanleitung.

Ansible Semaphore konfigurieren

Nach der Installation kann Semaphore hast du zwei Optionen dein neues Tool zu konfigurieren:

  • Über die Kommandozeile
  • Über eine config.json Datei

Auch bei der Benutzerverwaltung haben die Entwickler:innen auf zwei bekannte Verwaltungsmöglichkeiten gesetzt: Manuelle Verwaltung und eine LDAP Anbindung. Semaphore stellt zusätzlich eine API-Schnittstelle zur Verfügung, über die User:innen Ansible Semaphore konfigurieren und steuern können. Mehr über die Konfiguration und wie genau du sie durchführst erfährst du in der API-Dokumentation von Semaphore.

Benutzeroberfläche von Semaphore

Bei einer Web-UI kommt es vor allem auf eines an: Übersichtlichkeit. Und das schafft Semaphore ganz gut. Nach dem erfolgreichen Einloggen bekommst du folgende Oberfläche angezeigt: Die Weboberfläche von Semaphore. Man sieht 3 gelaufene Tasks, einer ist erfolgreich gelaufen, die anderen sind fehlgeschlagen. An der linken Seite gibt es eine bläuliche Menüleiste, in der die Punkte Die von mir gezeigte Oberfläche hat schon ein paar Tasks im Dashboard. Bei einer frischen Installation ist es noch leer, eine Demo-Konfiguration ist also nicht vorhanden. Dafür bietet Semaphore eine interaktive Demo-Oberfläche, auf der du dich mit der neuen Umgebung vertraut machen und erst kleine Aufgaben testen kannst. Um zu veranschaulichen, wie eine Produktivumgebung von Semaphore aussehen kann, habe ich drei Beispieltasks erstellt. Eine ist erfolgreich gelaufen, die anderen beiden sind fehlgeschlagen. Dadurch kann ich euch passende Beispiele für die Darstellung des Status zeigen. Neben der Darstellung der der Tasks ist auf der linken Seite eine türkis/blaue Menüleiste mit den Menüpunkten „Dashboard“, „Task Templates“, „Inventory“ „Environment“, „Key Store“, „Repositories“ und „Team“. Ganz unten in der Leiste gibt es einen Slider für einen Dark Mode und du bekommst angezeigt mit welchem User du angemeld bist. Die Oberfläche ist ja schön und gut, aber wie erstelle ich jetzt Tasks? Dafür musst du noch vier Parameter konfigurieren:

Keys

Im Key Store können SSH-Keys und Benutzer-Passwort-Paare abgelegt werden. Diese werden verwendet, um sich bei den Servern, auf denen die Ansible-Playbooks ausgeführt werden, zu authentifizieren. Die Keys werden auch zur Authentifizierung bei den Repositories verwendet, in denen die Playbooks liegen.

Inventories

Inventories enthalten, wie bei klassischem Ansible, die Server/Hosts, auf denen die Playbooks ausgeführt werden sollen. Inventories können entweder direkt in der Oberfläche angelegt werden oder auf dem Host-System von Semaphore abgelegt werden.

Environments

In Semaphore können verschiedene Environments angelegt werden, in denen Environment-Variablen gesetzt werden können.

Repositories

Die Playbooks, die verwendet werden sollen, müssen über Git-Repositories eingebunden werden. Diese Repositories können auf Git-Servern oder als lokale Repositories auf dem Host-System vorliegen. Zum Einbinden von Repositories wird ein Access Key aus dem Key Store benötigt. Bei Repositories, die über ssh eingebunden werden, ist dies ein privater SSH-Key. Bei HTTPS-Repositories muss ein Access Key vom Typ „None“ eingebunden werden, der nichts beinhaltet, aber angelegt sein muss. Somit können nur öffentliche Repositories über HTTPS eingebunden werden.

Erstellen und Ausführen von Tasks

Sobald alle oben genannten Komponenten eingerichtet sind, können „Task Templates“ erstellt werden. Anders als bei Ansible bestimmen Tasks in Semaphore, welche Playbooks ausgeführt werden. Ein Task Template umfasst:

  • Was passiert: Welches Playbook verwendet wird
  • Wo es passiert: Welches Inventory verwendet wird
  • Wie es passiert: Welches Environment verwendet wird
  • Wann es passiert: Planung durch Cron

Es gibt drei Arten von Templates: Task, Build,Deploy

  • Normale Tasks führen einfach Playbooks aus
  • Builds werden verwendet, um Artefakte (z.B. Packages oder Docker Container) zu erstellen. Semaphore unterstützt die Artefakterstellung nicht von Haus aus, das Build Template liefert lediglich eine Versionierung.
  • Deploys werden verwendet, um mit Build erstellte Artefakte zu deployen/installieren. Deploy Templates werden immer mit Build Templates verknüpft. Dadurch kann eine bestimmte Version des Artefakte auf den spezifizierten Servern installiert werden.

Nachdem das Task-Template erstellt wurde, drückt man einfach auf „Play“! Semaphore bietet die Möglichkeit, die Playbooks im Debug-Modus (ansible-playbook –vvvv), als Dry-Run (–check) oder im „Diff“-Modus (–diff) auszuführen. Der bekannte Output von Ansible wird dann angezeigt und kann auch nach dem Durchlauf eingesehen werden. Dadurch kann man bei einem fehlgeschlagenen Play nachsehen, welcher Fehler aufgetreten ist.

Fazit

Semaphore eignet sich meiner Ansicht nach zum gemeinsamen Arbeiten mit den gleichen Playbooks. Durch das benutzerfreundliche Interface erhält man schnell einen Überblick über die Ausführung von Tasks auf verschiedenen Geräten und deren Erfolg.  Die Cron-Funktion der Tasks ermöglicht eine regelmäßige Ausführung, was beispielsweise beim Aktualisieren von installierten Paketen nützlich ist. Es besteht allerdings auch noch Verbesserungsbedarf. Bei der Arbeit kann es hinderlich sein, dass private Git-Repositories nicht über HTTPS eingebunden werden können, da keine Authentifizierung möglich ist. Die „CI“-Funktionen mit den Build- und Deploy-Tasks werfen auch noch einige Fragen auf und sind vielleicht noch nicht ganz ausgereift. Wenn du dir jetzt denkst, dass sich Ansible Semaphore eigentlich ganz interessant anhört, du aber wissen willst wie es sich im Vergleich mit den GUI-Tools Rundeck und AWX beweist, dann habe ich gute Nachrichten für dich: Ich habe genau diese drei Tools miteinander verglichen und mein persönliches Fazit gezogen. Das Ergebnis meines Tests liest du im entsprechenden Blogpost.

Lucy Siemer
Lucy Siemer
Consultant

Lucy ist seit Mai 2023 bei NETWAYS als Consultant tätig, nachdem sie im Jahr 2022 ihre Ausbildung zur Fachinformatikerin für Systemintegration erfolgreich abgeschlossen hat. Ihre Schwerpunkte liegen auf den Bereichen Kubernetes, Infrastructure as Code und Monitoring. Neben ihrer Arbeit bei NETWAYS betreut Lucy auch privat ihre eigene Infrastruktur auf Kubernetes. Darüber hinaus ist sie leidenschaftlich daran interessiert, eigene Kleider zu nähen und individuelle Designs zu kreieren.