Code your Infrastructure - Ansible

Sollen Server automatisiert aufgesetzt und provisioniert werden, darf ein Tool in der Sammlung des DevOps Engineers nicht fehlen - Ansible.

Nachdem wir uns in den letzten Teilen der "Code your Infrastructure" Reihe bereits Terraform kennengelernt haben, mit dem wir virtuelle Server verwalten können geht es bei Ansible darum, diese Server mit der entsprechenden Software und Konfiguration auszustatten. Ebenfalls in der Reihe haben ich bereits den "cloud-init" Prozess vorgestellt. Die Grundkonzepte von cloud-init und Ansible sind dabei recht ähnlich. Auch bei Ansible wird eine (oder besser sehr viele) Konfigurationsdatei im yaml-Format verwendet um zu beschreiben, welche Setup- und Konfigurationsschritte auf einem neuen Rechner auszuführen sind.

Neben Ansible gibt es noch eine größere Anzahl von ähnlichen Tools wie zum Beispiel

• Puppet
• Salt
• Chef

Das besondere an Ansible ist jedoch die Einfachheit der Konfiguration, wie folgendes Beispiel zeigt.

- name: add apt signing key from official docker repo
  apt_key:
    url: https://download.docker.com/linux/debian/gpg
    state: present
- name: add docker official repository for Debian Buster
  apt_repository:
    repo: deb [arch=amd64] https://download.docker.com/linux/debian buster stable
    state: present
- name: install docker
  apt:
    name: "docker-ce"
    state: latest
    update_cache: yes
    force_apt_get: yes

Mit dieser Konfiguration im yaml-Format wird auf dem Zielrechner die Docker Engine installiert (auf einem Linux System, in dem konkreten Beispiel auf einem Debian/Ubuntu System).

Was dabei ins Auge sticht ist, dass es hier die Konfiguration deklarativ angegeben wird. D.h. es wird beschrieben, wie das System nach der Ausführung aussehen soll. Das unterscheidet Ansible von den oben genannten alternativen Tools wie Puppet in dem die Konfiguration aus Ruby Programmen besteht.

Eine weitere Besonderheit von Ansible ist, dass auf dem Zielserver keine spezielle Software benötigt wird. Denn Ansible verwendet SSH-Verbindungen zu den aufzusetzenden Zielrechnern um die Konfiguration durchzuführen. Die einzige Vorraussetzung für die Verwendung von Ansible ist also ein vorhandener SSH-Zugang - und das ist wohl auf allen Cloud Systemen gegeben. Die folgende Grafik zeigt den grundsätzlichen Ablauf eines Konfigurationsvorgangs.

Die eigentliche Konfiguration wird in Rollen zusammengefasst. Unser Beispiel von oben gehört dabei zu der Rolle "of.docker" und ist für die Installation der Docker Runtime verantwortlich. Rollen können dabei auch mehrere Zielplattformen gleichzeitig unterstützen (wie zum Beispiel Debian oder Red Hat basierte Systeme). Auch wenn Windows seit geraumer Zeit von Ansible grundsätzlich unterstützt wird, bleibt der Windows Support weit hinter den Unix basierten Plattformen inkl. macOS zurück. Damit hätten wir auch schon einen der ganz wenigen Nachteile von Ansbible beschrieben.

Neben den Rollen wird noch das "Inventory" benötigt. Im Inventory sind alle Server erfasst, die mit Ansible konfiguriert werden sollen.

Playbooks aggregieren mehrere Rollen und beschreiben den genauen Ablauf einer Konfiguration.

Module schließlich sind low level Komponenten, die die eigentliche Arbeit am Server verrichten. So gibt es Module für die Benutzerverwaltung oder für das Paketmanagement. Im obigen Beispiel werden die Module

• apt_key,
• apt_repository sowie
• apt

verwendet, um Docker auf dem Zielrechner zu installieren. Ansible kommt dabei mit einer sehr großen Anzahl an Standardmodulen daher, die nahezu alle Anwendungsfälle der Systemprovisionierung abdecken. Sollte man doch noch ein Spezialmodul benötigen, kann man sich natürlich auch eigene Module schreiben. In den letzten 7 Jahren (so lange verwenden wir Ansible bereits!) hatten wir allerdings noch nicht einmal den Fall, dass wir mit den vorhandenen Modulen nicht ausgekommen wären.

Ansible ist bereits 2012 veröffentlicht worden und gehört seit 2015 zu Red Hat. Die Entwicklung von Ansible ist damit langfristig gesichert und auch die Open Source Lizenz fördert eine weite Verbreitung des Werkzeugs.

Ich habe übrigens beim DevFest 2015 einen Vortrag über Ansible gehalten. Auch wenn das schon eine Weile her ist, an den Grundkonzepten hat sich wenig geändert und die Folien zum Vortrag haben wir in unserem Github zur Verfügung gestellt: https://github.com/openforce/talks/blob/master/2015-devfest_vienna_ansible/openForce_DevFest_Ansible.pdf

Mit diesem Teil der Reihe haben wir jetzt alle Werkzeuge zusammen um das eigentliche Ziel anzugehen - den Aufbau eines Cloud Clusters. Ich freu mich schon darauf! Also, wir lesen uns...