Seite wählen

NETWAYS Blog

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.

Ansible Continuous Deployment without AWX/Tower/AAP

Why Ansible?

Ansible is a configuration management tool to automate tasks in your IT infrastructure. It offers a rather low barrier of entry, when compared to other tools. A local Ansible installation (i.e. on your machine) with SSH access to the infrastructure you want to manage is sufficient for getting started. Meaning, it requires no substantial additions to existing infrastructure (e.g. management servers or agents to install). Ansible also ships with an extensive standard library and has a large selection of modules to extend functionality.

Why Continuous Deployment?

Once a simple Ansible setup is up & running and things start to scale to more contributors, servers or services, it is usually necessary to automate the integration of code changes. By creating one or more central Ansible repositories, we create a single source of truth for our infrastructure. We shift to continuous integration, start testing and verifying changes to the code base.

The next logical step is then to use automate the deployment of this single source of truth, to make sure changes are applied in a timely/consistent manner. Infrastructure code that is not deployed on a regular basis tends to become riskier to deploy each day, since it’s better to discover errors promptly so that they can be traced back to recent code changes; and we all know that people make undocumented hand-crafted changes that are then overwritten and all goes up in flames. Thus we want shorter, more frequent cycles and consistent deployments to avoid our infrastructure code becoming stale and risky.

Why not AWX/Tower/AAP?

AWX (aka. Tower, now Ansible Automation Platform) aims to provide a continuous deployment experience for Ansible. Quote:

Ansible Tower(formerly ‚AWX‘) is a web-based solution that makes Ansible even more easy to use for IT teams of all kinds.

It offers a wide array of features for all your ‚Ansible at scale‘ needs, however it comes with some strings attached. Namely, it involves management overhead for smaller environments as it introduces yet another tool to install, learn, update and manage throughout its life cycle. Not only that but from version 18.0 onward the preferred way to install AWX is the AWX (Kubernetes) Operator. Meaning – preferably – we would need a Kubernetes instance laying around somewhere. Of course, there is always the option to use „unorchestrated“ Containers as an alternative, but that comes with its own obstacles.

Installation and management aside, there is also Red Hat’s upstream first approach to consider. Meaning, AWX is the upstream project of Ansible Tower and thus it might not be as ’stable‘. Furthermore, Red Hat does not recommend AWX for production environments. Quote:

The AWX team currently plans to release new builds approximately every 2 weeks. The AWX team will flag certain builds as “stable” at their discretion. Note that the term “stable” does not imply fitness for production usage or any kind of warranty whatsoever.

Obviously, there are alternatives to AWX/Ansible Tower. Rundeck allows for predefined workflows, these jobs can then be triggered from a Web GUI, API, CLI, or by schedule and works not just with Ansible. Semaphore offers a simple UI for Ansible to manage projects (environments, inventories, repositories, etc.) and includes an API for launching tasks. Puppet aficionados may already know Foreman, which is a great and battle-tested tool for provisioning machines. You can use the „Foreman Remote Execution“ to run your Playbooks and use Ansible callbacks to register new machines in Foreman. Here are some recommended videos on this topic:

– FOSDEM 2020, Foreman meets Ansible: https://www.youtube.com/watch?v=PQYCiJlnpHM
– OSCamp 2019, Ansible automation for Foreman (hosts): https://www.youtube.com/watch?v=Lt0MksAIYuQ

That being said, the premise was to avoid substantially extending any existing infrastructure. Any of the mentioned tools need at least an external database service (e.g. MariaDB, MySQL or PostgreSQL). With that in mind, this article will now describe alternative solutions for continuous deployment without AWX/Ansible Tower. It will show examples using the GitLab CI, however, the presented solutions should be adaptable to various CI/CD solutions.

Ansible Continuous Deployment via the Pipeline

For this article, we will assume a central Ansible Repository on an existing GitLab Server with some GitLab CI Pipeline already in place. Meaning, we might also have some experience with CI jobs in Containers.

Many (if not all) CI/CD solutions feature isolated jobs within Containers, which enables us to quickly spin up predefined execution environments for these jobs (e.g. pre-installed with various tools for testing). Furthermore, it is possible to use specific machines for specific jobs, or place certain machine in different network zones (e.g. a node that triggers something in production environment could be isolated from the rest).

Given this setup we will now explore two scenarios for Ansible Continuous Deployment via pipeline jobs. One based on SSH and the other based on HTTP (Webhooks).

The example Ansible repository follows a standard pattern and is safely stored in a git repository:

git clone git@git.my-example-company.com:ansible/ansible-configuration.git
cd ansible-configuration/

ls -l
ansible.cfg
playbooks/
roles/
inventory/
collections/
site.yml
requirements.yml

SSH

Since the basis for all Ansible deployments is SSH we will leverage this protocol to deploy our code. Fundamentally, there are two options to achieve this:

– Connect from a pipeline job to a central machine with Ansible already installed, download the code changes there and trigger a playbook
– Run an Ansible playbook directly in a pipeline job (i.e. a Container)

For this example we will generate a specific SSH Keypair that is then used in the pipeline. The public key needs to be added to the `authorized_keys` of any machines we want to connect to. Secrets such as the SSH private key can be managed directly in GitLab (CI Variables) or be stored in an external secret management tool (e.g. Hashicorp Vault). Don’t hardcode secrets in the Ansible code base or CI configuration.

# -t keytype (preferably use ed25519 whenever possible)
# -f output file
# -N passphrase
# -C comment

ssh-keygen -t ed25519 -f ansible-deployment -N '' -C 'Ansible-Deployment-Key'

Option A: via an Ansible machine

In this scenario, we connect from a CI job in the pipeline to a machine with Ansible already installed. On this machine we will clone the Ansible configuration and trigger a playbook. This article will refer to this machine as ‚central Ansible node‘, obviously a more complex infrastructure might need more of these machines (i.e. per network zone).

First, we need to copy the previously generated SSH Key onto the central Ansible node, so that we connect from the GitLab CI job. Second, we require a working Ansible setup on this node. Please note, that a detailed installation process will not be explained in this article, since the focus lies on the CI/CD part. We assume that this node has a dedicated user for Ansible is be able to successfully run the Ansible code.

# Copy public key for deployment on the central Ansible node
scp ansible-deployment.pub ansible@central-ansible-node.local
ssh ansible@central-ansible-node.local

# Authorize the public key for outside connections
cat 'ansible-deployment.pub' >> ~/.ssh/authorized_keys

# Install Ansible
pip3 install --user ansible # or ansible==version
# Further setup like inventory creation or dependency installation happens here...

At this point we assume, we can connect to our infrastructure and run Ansible playbooks at our leisure. Next we will create a GitLab CI job which do the following:

  • Retrieve the previously generated SSH private key from our secrets, so that we can connect to the central Ansible node
  • Connect to the central Ansible node and clone the repository there. We will use the GitLab’s CI job tokens for this
  • Create a temporary directory to isolate each pipeline job
  • Run a playbook via SSH on the central Ansible node
---
stages:
- deploy

variables:
CENTRAL_ANSIBLE_NODE: central-ansible-node.local
# Or you can provide a ssh_known_hosts file
ANSIBLE_HOST_KEY_CHECKING=False

deploy-ansible:
image: docker.io/busybox:latest
stage: deploy
before_script:
- mkdir -p ~/.ssh
# SSH_KNOWN_HOSTS is a CI variable to make sure we connect to the correct node
- echo $SSH_KNOWN_HOSTS ~/.ssh/known_hosts
# The SSH private key is a CI variable
- echo $SSH_PRIVATE_KEY > id_ed25519
- chmod 400 id_ed25519
script:
- TMPDIR=$(ssh -i id_ed25519 $CENTRAL_ANSIBLE_NODE "mktemp -d")
- ssh -i id_ed25519 $CENTRAL_ANSIBLE_SERVER "git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@git.my-example-company.com:ansible/ansible-configuration.git $TMPDIR"
- ssh -i id_ed25519 $CENTRAL_ANSIBLE_SERVER "ansible-playbook $TMPDIR/site.yaml"

This basic example can be extended in many ways. For example, CI variables could be used to control which Ansible playbook is executed, change which hosts or tags are included. Furthermore GitLab can also trigger jobs on a schedule. Some of the benefits of this approach are that it is rather easy to set up since it mirrors the local execution workflow, plus the deployment can be debugged and triggered on the central Ansible node.

However, we now have a central Ansible node to manage and we might need several in different network zones. Additionally the `mktemp` solution is a bit hacky and might need a garbage collection job (e.g. `tmpreaper`). The next solution will alleviate some of these issues.

Option B: directly via a Pipeline

In this scenario, Ansible executed directly in the CI pipeline job (i.e. a Container). It is recommended to use a custom pre-build Ansible Container Image, to make the jobs faster and more consistent. This Image may contain a specific Ansible version and further tools required for the given code. The Image can be stored in the GitLab Container Registry. Building and storing Container Images is outside the scope of this article. Here’s a small example of how it might look like:

cat Dockerfile.ansible.example

FROM docker.io/python:3-alpine
RUN pip install --no-cache-dir ansible
# ... Install further tools or infrastructure specifics here
# The image will be stored at registry.my-example-company.com:ansible/ansible-configuration/runner:latest

cat .gitlab-ci.yaml
---
stages:
- deploy

variables:
# Or you can provide a ssh_known_hosts file
ANSIBLE_HOST_KEY_CHECKING=False

deploy-ansible:
image: registry.my-example-company.com:ansible/ansible-configuration/runner:latest
stage: deploy
before_script:
# The SSH private key is a CI variable
- echo $SSH_PRIVATE_KEY > id_ed25519
- chmod 400 id_ed25519
script:
- ansible-playbook --private-key id_ed25519 site.yaml

This removes the need for a central Ansible node and the need for external garbage collection, since these CI jobs are ephemeral by default. That being said, if we have a more complex network setup we might need runners in these zones and a way to control which job is executed where.

HTTP (Webhooks)

In this scenario, we setup another central Ansible node that will run the playbooks, however, there won’t be a SSH connection from the CI job. Instead we will trigger a webhook on this central Ansible node. While this scenario is more complex it offers some benefits when compared to previously discussed options.

Since there are several ways to implement incoming webhooks, we will not view a specific implementation but discuss the concept. Interestingly enough, a webhook-based feature is currently in developer preview to be provided by Ansible. Event-Based-Ansible provides a webhook service that can trigger Playbooks.

In this example we have a service providing webhooks running on central-ansible-node.local on port 8080. This service is configured to run Ansible with various options which we can pass via a HTTP POST request. This request will certain data that controls the Ansible playbook.

cat trigger-site-yaml.json
{
"token": "$WEBHOOK_TOKEN",
"playbook": "site.yaml",
"limit": "staging"
}

cat .gitlab-ci.yaml
---
stages:
- deploy

variables:
CENTRAL_ANSIBLE_NODE: central-ansible-node.local:8080

deploy-ansible:
image: docker.io/alpine:latest
stage: deploy
before_script:
- apk add curl gettext
script:
# Replace the $WEBHOOK_TOKEN placeholder in the file with the real value from the CI variables
- envsubst < trigger-site-yaml.json > trigger-site-yaml.run.json
- curl -X POST -H "Content-Type:application/json" -d @trigger-site-yaml.run.json $CENTRAL_ANSIBLE_NODE

From a security standpoint we remove the need for reachable SSH ports, the central Ansible node now just accepts HTTP (or specific HTTP methods) secured by Tokens. Furthermore there now is a layer between our CI jobs and the Ansible playbooks which can be used to validate requests.

That being said, this extra layer could also be seen as a hurdle that might break. And beside the central Ansible node we now need to manage a service that provides these webhooks. However, in the future Event-Based-Ansible might alleviate some of these issues.

Conclusions

Deploying Ansible is quite flexible due to its simple operational model based on SSH. As we have seen, there are some low-effort alternatives to AWX/Tower that can be applied in various use cases. However, at some point there is a maintainability tradeoff. Meaning, even though AWX/Tower might not appear as stable or is sometimes tricky to operate, once an environment is large enough it might be a better option than custom creations. Probably not a satisfying conclusion for an article named „without AWX/Tower“, I agree.

Foreman presents an interesting alternative due to its myriad of other features that you get with an installation. Finally, Event-Based-Ansible could be very promising webhook-based solution when it comes to automated deployments. Starting simple and then pivoting to a more complex system is always an option.

References

Markus Opolka
Markus Opolka
Senior Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

Versteckte Director-Features: Update-Only Sync-Regeln

Heute möchte ich ein neues kleines Feature im Icinga-Director vorstellen: die Möglichkeit, mit Sync-Regeln keine vollständigen Objekte zu verwalten, sondern nur bestimmte Eigenschaften von bestehenden Objekten zu steuern. Das klingt erst mal banal, also wozu das Ganze?

Bereits seit der ersten Director-Version ist es möglich, mehrere Import-Quellen in einer Sync-Regel miteinander zu kombinieren. Allerdings ist das in der Praxis nicht immer ganz so einfach. Spätestens wenn die zweite Quelle nur Zusatzinfos liefern soll, dabei aber mehr Hosts als die erste enthält – dann wird es kompliziert. Viele Import-Quellen lassen sich filtern, da kommt man schon weiter. Und seit einiger Zeit gibt es auch wenn die Quelle das nicht kann die Möglichkeit, via Property-Modifier Zeilen filterbasiert zuzulassen oder abzuweisen.

Der übliche Trick an der Stelle ist dann aber häufig das Anlegen von entsprechenden Datenlisten im Director. Diese befüllt man über dedizierte Sync-Regeln mit Leben und kann sie dann via Map-Modifier am primären Host-Import nutzen. Das funktioniert einwandfrei, ist aber ein wenig umständlich.

Director Sync-Rule - Update-Only

Director Sync-Rule – Update-Only

Beides ist mittlerweile nicht mehr erforderlich. Im aktuellen Master-Branch und in der kommenden Version 1.8 gibt es die Möglichkeit, sogenannte „Update-only“ Sync-Regeln anzulegen. Dabei kann man einem beliebigen Objekt-Typ (meist Hosts) eine Reihe von zusätzlichen Eigenschaften aus einer anderen Quelle verpassen, ohne aber zu riskieren dass diese Zweitquelle jetzt ungewollt Hosts hinzufügt oder gar entfernt.

Einfach, aber nützlich. Und das war’s auch schon für heute, wünsche euch ein schönes Wochenende!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

SPS Messe 2019: Automatisierung und IoT in Nürnberg

Letzte Woche, am 26.11.2019, war das Shop-Team inklusive mir auf der SPS-Messe. Die Smart Production Solutions-Messe ist eine riesige Messe in dem Fachbereich der industriellen Automation und das jährliche Highlight der Automatisierungsbranche. Von einfachen Sensoren bis hin zu intelligenten Lösungen und technischen Fortschritten umfasst sie noch einiges mehr.

Die SPS war die erste Messe für mich und es war eine große Erfahrung und vor Allem auch sehr informativ. Zwischen hunderten Ständen und technologischen Ausstellungen haben wir immer etwas aufgefriffen und sind jetzt auf dem neusten Stand der industriellen Automation. Bei vielen Ständen standen wir länger und haben uns bis in das kleinste Detail informieren lassen, um vielleicht unseren Shop auch bald aufzustocken, wie beispielsweise bei JUMO. JUMO ist ein Global Player auf dem Gebiet der industriellen Sensor- und Automatisierungstechnik. Verschiedene Sensoren wie….

  • Flüssigkeitsanalsye (Messgrößen wie pH-Wert, Redox-Potential…)
  • Drucksensor (vor Allem gut bei den Lebensmittel- und Pharmabereich oder für den Maschinen- und Anlagenbau)
  • Füllstandssensor (Anwendung bei drucklosen Behältern, Brunnen und Gewässern)
  • Durchflusssenor (auch Flügelgrad- und kalorimetrische Strömungssensoren)
    …..stellt Jumo her mit den verschiedenen Automationen.

 

Außerdem standen wir eine Weile bei Schildknecht und haben uns von den DATAEAGLE Bluetooth Roaming begeistern lassen. Es ermöglicht den Aufbau eines Funknetzwerkes in getrennten Räumen mit dem Einsatz von Bluetooth-Funktechnologie. Die Sensoren sind beispielsweise auch über Bluetooth zu erreichen, das bietet gegenüber dem WLAN viele Vorteile, wie die extrem stabile Funkverbindung. Außerdem erreicht man eine flexiblere Funkplanung, weil Bluetooth weniger Probleme mit der Reichweite hat.

Weiterhin habe ich mich über die CO2-Messung bei E+E Elektronik aufklären lassen. Wusstet Ihr, dass schon ab 1.000 ppm CO2 in der Luft einem Raum zur Müdigkeit und Konzentrationsschwäschen führen kann? Die CO2-Messsensoren zeigen genau sowas an! Sie basieren auf dem NDIR-Zweistrahlverfahren (2 Wellenlängen / 2 Detektoren). Einer der Detektoren ist auf einer Wellenlänge von 3,9 μm eingestellt und wird von keinem Gas beeinflusst. Natürlich wird dann aber die Messung aus beiden Detektoren herausgenommen. Der Sensor ist unempfindlich gegen Verschmutzung und Alterungseffekte werden ausgegelichen und eine ausgezeichnete Langzeitstabilität ist gegeben. Natürlich bietet E+E nicht nur diese CO2 Sensoren an, sondern auch viele mehr!

@LangLang21 und @leoniepehle1 auf der SPS 2019!

 

FuehlerSysteme eNET International GmbH entwickelt und produziert Sensoren zur Messung von Umweltbedingungen wie Feuchte,Temperatur, Druck, Luftqualität, Strömung und viele mehr. Für jede Messung hat FuehlerSysteme etwas parat und verfügt deshalb auch über ein großes Produktspektrum. Deshalb waren wir dann auch dort und haben uns informieren lassen. Die Gateways, die mit den Sensoren verbunden werden, haben viele verschiedene Eigenschaften und ist mit vielem kompatibel, wie z. B.

  • Datenformate: .xml, .sql, .json, .csv
  • Konvertierung: Snap7, BACnet, Modbus
  • Verkabelung: RS485, RJ-45, COM-Port

 

Viele weitere Firmen mit anderen tollen Ideen waren auch auf der SPS vertreten, trotzdessen dass viele, ähnliche oder fast die selben Produkte anbieten, sind sie alle auf ihre Art und Weise verschieden. Ob es die Menschen sind, oder ob sie dann doch nur ein anderes Netzteil verwenden. Es war eine tolle Erfahrung für mich und das Team! Wir sehen uns auf der nächsten SPS wieder.

Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns seit kurzem auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team!

Leonie Pehle
Leonie Pehle
Account Manager

Leonie ist seit September 2019 bei NETWAYS und hat dort eine Ausbildung zur Kauffrau für Büromanagement erfolgreich abgeschlossen. Seit Juli 2022 unterstützt sie uns als Account Manager im Bereich Sales für NETWAYS Web Services. In ihrer Freizeit ist sie aktive Hobbyfotografin, immer auf der Suche nach dem perfekten Schnappschuss. Darüber hinaus ist sie immer im Stadion zu finden,  wenn der 1.FC Nürnberg spielt.