Ansible Molecule: Der DevOps-Baustein für stabile Playbooks

Im Softwarelebenszyklus ist das Konfigurationsmanagement unabdingbar zur Aufrechterhaltung des gewünschten Systemzustands. Dabei kommen gängige Werkzeuge wie Chef, Puppet, Ansible oder SaltStack zum Einsatz. Bevor sich die Konfiguration jedoch gefahrlos produktiv einsetzen lässt, muss sie getestet werden, da sich verschiedene Systeme selbst bei derselben Konfiguration unterschiedlich verhalten. Daher sollte stets sichergestellt sein, dass ein gewünschter Konfigurationszustand jedes relevante Testszenario durchläuft, bevor er im Produktionssystem landet. An dieser Stelle kommt Molecule ins Spiel.

Server-Administration mit Ansible Playbooks

Als Software zur automatisierten zentralen Verwaltung (Orchestrierung) und Administration verteilter Server hat Ansible mit seinen in YAML verfassten Playbooks einen festen Platz neben vergleichbaren Anwendungen wie Puppet oder Chef erobert. Die Community-Version von Ansible ist als Open-Source-Software im Rahmen der Linux-Administration lizenzfrei. Darüber hinaus bietet Hersteller Red Hat lizenzpflichtige Ansible-Editionen, die zusätzliche Funktionen wie ein Dashboard oder Workflows zur Verfügung stellen.

Das seit 2012 verfügbare Verwaltungswerkzeug ist in den meisten Linux-Distributionen enthalten – darunter CentOS, Ubuntu und Debian. Im Vergleich zu Puppet und Chef zeichnet sich Ansible durch ein einfacheres Konzept aus. Anstelle einer zentralen Komponente genügt ein einzelner Rechner, der per SSH Zugriff auf die zu verwaltenden Server hat. Nach Erfahrung des Autors fällt auch der Einarbeitungsaufwand bei Ansible geringer aus als bei Chef oder Puppet.

Remote-Systeme lassen sich mit Ansible bereitstellen, indem zunächst ein SSH-Schlüsselpaar angelegt und der öffentliche SSH-Schlüssel in der Datei ~/.ssh/authorized_keys zur Verfügung gestellt werden. Eine Inventardatei – beispielsweise development.ini – fasst die zur Verwendung vorgesehenen Hosts zusammen:

[GROUP]
MACHINE_NAME hostname=MACHINE_NAME ansible_ssh_host=IP_ADDRESS ansible_port=SSH_PORT
ansible_connection=ssh ansible_user=USER ansible_ssh_extra_args="-o
StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"

Darin definiert Hostname den Hostnamen der Remote-Maschine, ansible_ssh_host die IP-Adresse oder Domäne des Remote-Hosts und ansible_port den Port des Remote-Hosts, in der Regel 22. Die bevorzugte Verbindungsart legt ansible_connection fest, den ssh-Benutzer ansible_user. Zusätzliche Argumente für die SSH-Verbindung lassen sich mit ansible_ssh_extra_args ergänzen. So bietet StrictHostKeyChecking in Kombination mit UserKnownHostsFile die Option, einen Schlüssel abzufragen, um zu prüfen, was auf ein Ja oder Nein wartet. Ansible kann diese Frage nicht beantworten und gibt einen Fehler aus, der Host ist nicht verfügbar.

Auf Grundlage dieser Inventardatei lässt sich ein Playbook wie folgt erstellen:

---
- hosts: MACHINE_NAME
  tasks:
     - name: Say hello
       debug:
           msg: 'Hello, World'

und anschließend ausführen:

ansible-playbook -i development.ini playbook.yml