In love with Ansible

foo — In love with Ansible
Wie konnte ich eigentlich jemals ohne Ansible leben?

Wenn man viele (Linux-) Rechner zu administrieren hat, dann wird das ab einer bestimmten Anzahl recht unübersichtlich ("welche Konfiguration ist jetzt gleich wieder auf web01?") und man führt viele Tätigkeiten immer wieder, aber doch immer ein bisschen anders, aus. Schlaue Leute dokumentieren ihre Änderungen, damit sie diese bei einer Neuinstallation oder der Einrichtung weiterer, ähnlicher Rechner griffbereit haben und die einzelnen Schritte nachvollziehen können. Im Laufenden Betrieb werden dann auch immer mal wieder kleine Änderungen vorgenommen, aber nicht unbedingt dokumentiert. Als Sysadmin fängt man dann irgendwann an, diese Aufgaben zu automatisieren. Vielleicht schreibt man einfach einige Shell-Skripte. Und merkt dann irgendwann, dass auch das relativ schnell unübersichtlich wird. Das muss doch noch besser gehen. Tut es. Es gibt zum Glück eine ganze Reihe von Open-Source Software für diesen Zweck. Die vier großen sind wohl Puppet, Chef, Salt und Ansible, wobei die letzten beiden vergleichsweise jung sind, aber schnell große Verbreitung fanden.

Zu Chef kann ich nicht viel sagen. Es gilt nach diversen Posts zu urteilen als ziemlich kompliziert, selbst im Vergleich zu Puppet, das auch nicht unbedingt den Ruf hat einfach zu sein. Mit Puppet und Foreman als Webinterface hatte ich schnell eine laufende Infrastruktur, der ganze beteiligte Softwarestack war aber doch relativ komplex (Ruby, diverse Dienste, Puppet Client auf den Nodes). Der Kunde war auch etwas überfordert von den vielen Möglichkeiten, die dieses Setup bietet und der damit einhergehenden Komplexität. Wir wollten jedoch eine einfache Lösung, die überschaubar ist und genau unsere Anforderungen erfüllt, aber nicht mehr. Also weiter evaluieren. Kurz Salt angeschaut, aber nach diversen Problemen erstmal aufgegeben und bei Ansible gelandet und geblieben.

The Beautifulness of Ansible

Ansible wurde von Anfang an entwickelt, um einfach zu sein. Bereits in den Release Notes zu Version 0.0.1 verspricht Michael DeHaan, der Autor von Ansible:

The easiest config management system to use, ever.

und

Dead simple setup

(siehe README.md)

Während die anderen genannten Tools im Pull-Modus arbeiten (Client holt sich die Konfiguration vom Server), arbeitet Ansible per Default im Push-Modus. Das heisst, die Softwareanforderungen sind extrem gering. Der zu Konfigurierende Client benötigt lediglich einen laufenden SSH-Server und installiertes Python, beides wird in der Regel ohnehin schon vorhanden sein. Ein dedizierter Server wird nicht benötigt, eine Installation von Ansible auf einem Linux-Rechner reicht aus.

With a click on play you will allow that this video will be loaded from YouTube. Personal information may be transferred to YouTube.

Ansible. Simplicity and the Zen of Python, Talk by Tedd Owen at PyCon 2015, CC

Installation von Ansible

Da ich auf meiner Workstation Debian testing habe, in dem das Ansible-Paket nicht auf dem neueten Stand ist, habe ich Ansible daher via pip installiert, womit ich auch gleich die kürzlich erschienene Version 2.0 bekam. Das ist erstmal alles und man kann Ansible nun bereits grundlegend benutzen, etwa mit dem command oder dem shell Modul. Mehr dazu im Ansible Handbuch unter Your first commands. Das Grundprinzip dabei ist: Ansible logged sich per ssh auf dem Client ein und führt dort seine Python-Scripte aus, um die Konfiguration durchzuführen oder Infos vom Client zu bekommen.

Damit lässt man es natürlich nicht auf sich beruhen. Der Spass fängt jetzt erst richtig an. Doch zunächst noch einige Grundkonzepte von Ansible.

apt-get install python-pip
pip install ansible

Hat man diese Dinge verstanden, dann kennt man Ansible eigentlich schon fast. Aufgrund der Einfachheit von Ansible hat man das auch in einigen Tagen verinnerlicht und kann nun anfangen, über einen Produktiveinsatz nachzudenken.

Ansible Grundlagen

Einige zentrale Begriffe von Ansible:

inventory

Ein Inventory beschreibt den Bestand an bekannten Rechnern. Es enthält vor allem Rechnernamen, Verbindungsdetails und die Zugehörigkeit von einzelnen Rechnern zu Gruppen. Ein inventory kann dabei eine einfache Textdatei sein, aber auch dynamisch generiert werden, etwa indem man das Inventory aus einem anderen, bereits bestehenden System holt und generieren lässt.

localhost  ansible-connection=local
server01
server02
[group1]
server01
server02
[sql_server]
server01

playbooks

playbooks: Mehrere Aufgaben (tasks) werden üblicherweise in playbooks zusammengefasst, die dann mit ansible-playbook ausgeführt werden. Playbooks können neben Tasks auch noch Variablen, Rollen (gleich mehr) und inventory-Daten beinhalten.

- hosts: all
  gather_facts: False
  remote_user: mgmt
  tasks:
    - name: Upgrade all packages
      apt: update_cache=yes upgrade=dist cache_valid_time=600
      become: yes

roles

Rollen wiederum fassen ganze Aufgabenblöcke zusammen. Sie beinhalten ihrerseits in der Regel Variablen, Tasks und weitere von der Rolle benötigte Dateien. Eine Rolle könnte z.B. "unattended-upgrades" sein. Diese würde unter Debian/Ubuntu das Paket für unbeaufsichtigte Systemupdates installieren und entsprechend einiger Variablen/Templates konfigurieren. Um dies nun auf einem Rechner (oder auch allen gleichzeitig) zu installieren, müssen wir ihm jetzt nur noch die entsprechende Rolle zuweisen und möglicherweise spezifische Variablen überschreiben. Mit der Ansible-Galaxy gibt es einen zentralen Punkt, an dem einige Hundert Rollen für verschiedene Aufgaben geteilt werden. Manche Rollen kann man direkt verwenden, bei vielen fand ich es aber auch nötig Anpassungen vorzunehmen oder gleich selbst eine neue Rolle zu schreiben, was wirklich einfach ist.

- hosts: all
  become: yes
  roles:
    - sudo
    - users
    - c1.bashaliases
    - c1.ssh-hardening
    - c1.firewall
    - c1.ntpdate
    - jnv.unattended-upgrades
    - role: c1.hddtemp
      when: "'bare_metal' in group_names"
    - c1.collectd
    - xcezx.aliases

variables

Variablen sind in Ansible überall zu finden und bestimmen sowohl die Ausführung von Ansible selbst als auch die auf Clients verteilte Konfiguration. Variablen können durch spezifischere Variablen überschrieben werden. Wir können z.B. in einer Rolle eine Default-Variable definieren, diese dann aber für eine bestimmte Gruppe oder einen bestimmten Host überschreiben. Dabei ist natürlich die Priorität der Variablen zu beachten.

---
collectd_enabled: yes
collectd_loglevel: info
collectd_plugin_network_enabled: yes
collectd_plugin_network_options:
  - Listen "1.2.3.4" "25826"
  - Server "remote-server" "54321"

Ansible all the things!

Mittlerweile konfiguriere ich viele Dinge auf den meisten meiner Rechner/Server mit Ansible und frage mich, wie ich jemals ohne ein vernünftiges Konfigurationsmanagementsystem leben konnte. Die Rechner sind jetzt alle auf einem bekannten Stand und ich spare mir viel Zeit beim Einrichten neuer Rechner. Ausserdem übernimmt Ansible gleich noch in gewisserweise die Dokumentation: Aufgrund der einfachen YAML-Schreibweise und Taskbeschreibungen in natürlicher Sprache ist beim Überfliegen von Playbooks leicht zu verstehen, was sie tun.

Schön ist auch, dass man Ansible nach und nach einführen kann. Man kann schrittweise immer weitere Tasks hinzufügen und nach ausgiebigem Testen auf allen Rechnern deployen.

Fazit

Würde es wieder tun.

Ansible überzeugt durch seine Einfachheit, ohne dabei den Admin zu sehr einzuschränken. Bisher konnte ich alle Aufgaben damit umsetzen, die ich mir in den Kopf gesetzt hatte.