Ansible: Infrastruktur als Code

Für die Entwicklung und Bereitstellung von IT-Systemen ist „Infrastructure as Code“ zu einem bedeutendem Schlüsselbegriff in der Welt der Systemadministration geworden. Dabei bezieht sich der Zusatz „as Code“ darauf, dass die Systeme nicht mehr manuell eingerichtet und konfiguriert sind, sondern mittels einer Skriptsprache entwickelt werden – auch im Data-Science-Kontext lassen sich dadurch schnell und einfach Test- und Produktivsysteme aufsetzen. In unserem Beitrag zeigen wir Ihnen wie sich Konfigurationsabläufe mittels Ansible automatisieren lassen.

Warum eine Infrastruktur mit Ansible konfigurieren?  

Ansible ist neben Puppet eines der bekanntesten Tools für Infrastruktur-Automatisierung. Es wird von RedHat als Open-Source-Management-Lösung entwickelt und kommt, im Gegensatz zu vergleichbaren Programmen, vollständig ohne Agenten auf den Zielsystemen aus. Benötigt werden lediglich SSH und Python. Die Skripte werden in der Markup-Sprache YAML geschrieben.

Was Ansible von anderen Tools abhebt ist das Konzept von Idempotenz. Es werden nur Aktionen durchgeführt, wenn sie notwendig sind, was bedeutet, dass selbst wenn ein Vorgang mehrfach wiederholt wird – z. B. bei der Wiederherstellung nach einem Ausfall – das System immer in denselben Zustand versetzt wird und diese wiederholten Vorgänge ohne Nebenwirkung sind.

Durch die Verwendung von Ansible lassen sich Konfigurationsabläufe auf einer ganzen Reihe von Systemen mittels Skripten automatisieren, sodass ein manueller Eingriff nicht mehr nötig ist. Das spart Zeit und senkt die Fehleranfälligkeit. Die Arbeit erfolgt hier in der Regel nicht auf der Zielumgebung, sondern die Skripte werden aus der Ferne gestartet und setzen anschließend eine Abfolge von Prozessen, beispielsweise zur Installation von Software, auf einem oder mehreren Zielsystemen in Gang. Eine Installation der Tools auf den entfernten Maschinen ist in diesem Fall nicht nötig.

Die Prozesse werden in einem Playbook vereinigt, dass wiederum in Roles aufgegliedert ist in dem die einzelnen Prozesse als Tasks organisiert sind. Man schreibt wie in einem Film Drehbücher, die mit verschiedenen Rollen besetzt sind und die Aktionen auf den ausgewählten Servern ausführen. Dieselben Skripte können wiederholt für unterschiedliche Umgebungen genutzt und wenn nötig individuell angepasst werden. Dabei kann über das Inventory ausführlich definiert werden, welche Skripte auf welchen Systemen ausgeführt werden sollen. Die Zielsysteme werden granular definiert oder auch als Gruppe, die dann als Datenbankserver und Webserver zusammengefasst angesprochen werden.

Gängige Abläufe, die sich automatisieren lassen, sind beispielsweise die Systemkonfiguration, die Installation von Software, das Erstellen von Backups oder sogar das komplette Einrichten eines ganzen Systems. Werden die Playbooks zusätzlich mit einer Versionskontrollsoftware wie Git verwaltet, können beliebige Szenarien durch die individuelle Konfigurierbarkeit der Rollen und Tasks reproduzieren lassen.

Erweiterungen für Ansible

Für alle drei vorgestellte Tools gibt es zusätzliche Web-Oberflächen zur Steuerung der Abläufe. Diese sind vollständig optional und dienen lediglich zur einfacheren Bedienung im Unterschied zur Arbeit in der Konsole.

Im Falle von Ansible sind dies Ansible AWX (Open Source) und die kommerzielle Alternative Ansible Tower, welche mehr Funktionen und Support für Unternehmen bietet. Mit Ansible Galaxy erhält man Zugriff auf tausende, von der Community bereitgestellte Skripte für alle erdenklichen Aufgaben, die sich mit wenig Anpassung direkt für die eigenen Bedürfnisse verwenden lassen können.

Beispiel mit Ansible

Das folgende Playbook demonstriert die Installation des Python-Interpreter in der Version 3.7 auf allen Hosts, welche in der Liste „Server“ eingetragen wurden:

– name: Python
  hosts: Server
  vars:
    PYTHON_VERSION: "3.7" # alternatively "3" for the most recent version
  tasks:
  – name: Install Python package
    package:
      name: "python{{ PYTHON_VERSION }}"
      state: installed

Mit dem Befehl ansible-playbook kann das YAML-Skript nun gestartet werden:

user@host:~$ ansible-playbook skript.yml

Wir haben beim Ausführen des Playbooks eine hohe Transparenz und sehen live welche Tasks wo ausgeführt werden und zum Abschluss ein PLAY RECAP, eine Zusammenfassung der durchgeführten Tasks. Sofern der Task nichts modifiziert, erhalten wir ein ok=1 und changed=0, in unserem Fall haben wir zwei Änderungen durchgeführt und erhalten ok=1 und changed=1 für jeden Server, auf dem Python 3.7 installiert wurde:

user@host:~$ ansible-playbook skript.yml
PLAY [Python] ******************************************************************

TASK [Install Python package] **************************************************
changed: [172.16.2.101]
changed: [172.16.2.102]

PLAY RECAP *********************************************************************
172.16.2.101 : ok=1 changed=1 unreachable=0 failed=0
172.16.2.102 : ok=1 changed=1 unreachable=0 failed=0

Fazit

Wir empfehlen Ansible, da es hervorragende Möglichkeiten zur automatisierten Infrastruktur-Konfiguration bietet und gleichzeitig, im Vergleich zur Konkurrenz, nur minimale Voraussetzungen benötigt, sodass der Nutzer im Vorfeld nichts weiter als die Playbook-Skripte schreiben muss und jegliche weitere manuelle Arbeit entfällt. Mit RedHat steht ein großes und innovatives Unternehmen hinter dem Tool und gewährt zusammen mit einer starken Community die Zukunftsfähigkeit des Projekts.

Auch Sie möchten eine automatisierte IT-Infrastruktur in Ihrem Unternehmen konfigurieren? Die System Engineers von eoda | analytic infrastructure consulting unterstützen Sie gern bei der Umsetzung! Sprechen Sie uns an.