Ansible Molecule: Der DevOps-Baustein für stabile Playbooks
Für das Konfigurationsmanagement verteilter Server haben sich Ansible Playbooks bewährt, doch sie sollten nie ungetestet in den Produktivbetrieb gehen.
- Martin Reinhardt
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