Sollen Server automatisiert aufgesetzt und provisioniert werden, darf ein Tool in der Sammlung des DevOps Engineers nicht fehlen - Ansible.
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.