© saicle/Shutterstock.com
Kolumne: Quality Time

Kolumne: Quality Time


Spätestens seit dem Siegeszug von DevOps gehört es zum guten Ton eines Entwicklungsteams: Die benötigte Serverkonfiguration wird direkt im Projekt gehalten, das Einrichten und Aktualisieren aller Systeme wird auf Knopfdruck automatisiert, was Zeit, Nerven und letztendlich auch Geld spart. Die Konfigurationsdateien für Orchestrierungswerkzeuge wie Puppet [1] und Chef [2], die ganze Serverfarmen, aber auch einzelne virtuelle Maschinen betreuen können, werden gemeinsam mit dem Quellcode des Projekts versioniert.

Gegen diese beiden Platzhirsche der Szene tritt An­sible [3] seit seiner Geburt vor zwei Jahren als pragmatische Open-Source-Lösung für Konfigurationsmanagement und Administration an. Dabei legt das Tool Wert auf Einfachheit und Lesbarkeit der Konfiguration – Eigenschaften, die den etablierten Lösungen oft fehlen. Als kleines Beispielszenario soll hier mit Ansible der Apache-Webserver auf einem Ubuntu-System installiert und eine Vhost-Konfiguration erstellt werden. Aus Platzgründen werden hier einige Details nicht dargestellt, Sie können den gesamten Quellcode aber unter [4] einsehen und ausprobieren.

Ansible benötigt mindestens zwei Konfigurationsdateien: ein so genanntes Playbook, das die Regieanweisungen – also die auszuführenden Befehle – enthält, und eine Inventory-Datei, die beschreibt, welche Computer administriert werden sollen und in welche Gruppen diese aufgeteilt sind. Wir schauen uns zuerst das Playbook an, das hier provision.yml heißt:

--- - hosts: backend sudo: yes roles: - role: webserver vhosts: - { hostname: 'ansible.local', dir: '/home/vagrant/ansible/htdocs' }

Diese YAML-Datei [5] beschreibt eine Hostgruppe namens backend, beliebige weitere Hostdefinitionen können mit Spiegelstrichen hinzugefügt werden. Für die Hosts in der backend-Gruppe sollen die anstehenden Befehle mit sudo, also als Root-Benutzer, ausgeführt werden. Anstatt diese Befehle jedoch direkt im Playbook aufzulisten, was durchaus möglich wäre, wird als Best Practice die Modularisierung mit Rollen genutzt. Im konkreten Fall wird der Hostgruppe die Rolle webserver zugewiesen.

Hosts dieser Gruppe spielen also die Rolle webserver und sollen entsprechend ausgestattet werden. Jede Hostgruppe kann beliebig viele Rollen spielen, die als Gesamtergebnis alle auszuführenden Tasks definieren. Andere denkbare Rollen wären z. B. database für die Installation von MySQL oder javascript für Node.js und weitere Tools. Im gezeigten Fall erhält die Rolle webserver beim Aufruf den Paramet...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang