Ansible

Veröffentlicht am von

Zur Verwaltung von Rechnernetzen, Serverclustern oder Umgebungen die aus mehreren Rechnern bestehen, können nur mit großem Aufwand alle Einstellungen manuell getätigt und anschließend von Hand auf dem aktuellen Stand gehalten werden.
Zeitsparender ist der Einsatz von Automatisierungswerkzeugen. Mehrfach auszuführende oder sich regelmäßig wiederholende Installations- und Aktualisierungsaufgaben können konfiguriert und anschließend bei Bedarf ausgeführt werden. Neben der Zeitersparnis kann durch die Wiederverwendung von Konfigurationen eine homogene Umgebung geschaffen werden, in der alle Anwendungen in der selben Version vorliegen.
Eines dieser Automatisierungswerkzeuge ist Ansible.

Inhalt

  1. Was ist Ansible
  2. Merkmale
  3. Installation/Einrichtung
  4. Nutzung
  5. Anwendungsbeispiel
  6. Konkurrenz
  7. Fazit
  8. Quellenverzeichnis

Was ist Ansible

Ansible ist ein Automatisierungswerkzeug, das im Jahr 2012 veröffentlicht wurde.
Mit diesem können verschiedene Aufgaben automatisiert und verwaltet werden.
Mittels Skripten, die in einem *Playbook* zusammengefasst werden, ist die wiederholte Anwendung auf mehreren Einheiten – z.B. einem Server-Cluster eines Unternehmens – ohne manuellen Mehraufwand und mit Echtzeitüberwachung möglich.
Die Grundfunktionen von Ansible sind kostenlos verfügbar. Zusätzlich gibt es mit der Red Hat Ansible Automation Platform eine kostenpflichtige Variante, die Grundfunktionen um weitere Features, Support und vorgefertigte Anwendungslösungen erweitert.
In Ansible wird keine konkrete Programmiersprache gefordert.
Die Definition, welches Skript zu verwenden ist, wird im Playbook in YAML verfasst.
Die verwendete Sprache im Skript ist jedoch frei wählbar.
Eben jene flexible aber gleichzeitig sicherheitsorientierte Funktionalität wird vom Hersteller Red Hat beworben. Die Sicherheitsorientierung manifestiert sich in der ausschließlichen Nutzung von SSH-Verbindungen und dem Verzicht auf Agenten (Ansible ist agentless). Dies bedeutet, dass keine weitere Software auf den zu kontrollierenden Systemen installiert werden muss, um Ansible nutzen zu können.
(vgl. Quelle[3])
Das Einsatzgebiet von Ansible ist dabei vielfältig. Von Netzwerkmanagement über Konfigurationsmanagement bis zur Automatisierung einer Cloud- oder Edgeumgebung sowie von Securitysystemen, ist mit diesem Werkzeug alles möglich.

Merkmale

Das Grundgerüst innerhalb der Automatisierung sind die sogenannten Module.
Innerhalb eines einzelnen Moduls befinden sich verschiedene Playbooks.
Diese sind in YAML verfasst, also einer einsteigerfreundlichen und leicht lesbaren Sprache.
Solche Module können sowohl selbst geschrieben, als auch als vorgefertigte und etablierte Lösungen genutzt werden.
Eine Eigenschaft dieser Architektur ist die Fähigkeit, dass diese Module einzeln, in einer Reihenfolge und/oder multipel ausgeführt werden können – je nachdem wie sie in den Playbooks konfiguriert werden.
Prinzipiell kann festgehalten werden, dass die Gestaltung einer Automatisierung mittels Ansible nicht ohne die dazugehörigen Plattformen stattfinden kann.
Nachfolgend sind all diese Komponenten – wie sie von Red Hat bezeichnet werden – tabellarisch aufgelistet und kurz beschrieben.
Den Beginn der Tabelle stellt mit Ansible Core die Hauptanwendung dar.
Automatation Plattform:
Ansible Core
Hauptanwendung, welche alle grundlegenden Automatisierungsfunktionen bereitstellt.
Automatisierungssteuerung
Eine Steuerungsebene mit Benutzeroberfläche, welche zur Standardisierung der Funktionen Bereitstellung, Initiieren und Überprüfen von Automatisierungen verwendet wird.
Automatisierungs-Ausführungsumgebungen
Container als portable Ausführungsumgebungen von Ansible Playbooks und Roles.
Automatisierungsnetz
Skalierung von Gruppen, Plattformen und Netzwerktopologien. Verhilft dem System eine höhere Ausfallsicherheit zu etablieren und die Automatisierung an sich zu standardisieren. Eine graphische Visualisierung der Topologie ist ebenfalls möglich.
Ansible Content Sammlungen
Sammlung vertrauenswürdiger Bausteine flexibler Automatisierungsinhalte, für eine Vielzahl von Anwendungsfällen.
Automatisierungs-Hub
Eine Plattform zum zügigen Finden und/oder Anpassen von geeigneten Inhalten von Red Hat oder seinen Technologiepartnern. Ebenfalls als private Version verfügbar, um eine lokale Instanz zu besitzen.
Ansible Content Tools
Zur Erstellung und Verwaltung von Ausführungsumgebungen verwendbar.
Red Hat Insights für Red Hat Ansible Automation Platform
Reihe von Dashboards zur Überwachung der Automatisierungsarchitektur, welche von den Leitern an die Teams abgegeben wurden. Es berechnet Vorhersagen bezüglich Zeit- und Kosteneinschätzung und möglichen Einsparungen z.B. bei den Teamgrößen und Strukturen.
Ebenfalls wird die Visualisierung von der Infrastruktur bereitgestellt, womit sich eine Bewertung vereinfacht.
Katalog für Automatisierungsdienste
Spezielle Produkte von Drittherstellern zur Automatisierung .
Für die Kurzbeschreibung, vgl. Quelle[4]

Installation/Einrichtung

Mit Ansible können mehrere Hosts (Rechner, Server,…) von einem Kontrollsystem verwaltet und gesteuert werden. Um Ansible in der kostenlosen Variante verwenden zu können, muss es auf dem Kontrollsystem (control node) installiert werden. Da Ansible agentless agiert, muss es nicht auf den Hostsystemen (managed nodes) eingerichtet werden. Für die Nutzung müssen SSH sowie Python ab Version 2.7 bzw. 3.5 vorhanden sein.
Auf dem control node wird Python ab Version 3.8 (Ansible Core 2.12) bzw. Python 3.9 (Ansible Cor 2.14) benötigt. Die Installation kann mittels eines Paketverwaltungstools wie pip:
  python3 -m pip install –user ansible
oder conda:
  conda install -c conda-forge ansible
erfolgen.
Für macOS kann zusätzlich die Paketverwaltung Homebrew:
brew install ansible
verwendet werden.
Unter Windows ist Ansible nativ nicht nutzbar, kann jedoch über einen Umweg mittels WSL (Windows Subsystem for Linux) wie oben beschrieben eingerichtet und angewendet werden.
Nach der Installation von Ansible auf dem Kontrollsystem muss gegebenenfalls noch ein SSH-Schlüsselpaar erstellt und der Public Key des control node bei den managed nodes hinterlegt werden.
Anschließend kann die Konfigurationsdatei ansible.cfg erstellt/angepasst werden. In ihr sind grundlegende Einstellungen von Ansible, wie z.B. Quellen für managed nodes, Log-Verhalten oder die Verwendung von Plugins festgelegt. Ansible Inventories sind Dateien, in denen die managed nodes aufgelistet werden, die für bestimmte Vorhaben angesprochen werden sollen. Mit ihrer Hilfe können verschiedene Gruppen für verschiedene Aufgaben angelegt werden.

Nutzung

Um Ansible zu nutzen, können entweder Befehle direkt in der CLI, also ad-hoc, angegeben werden oder Playbooks definiert werden.
Inventory
Das Inventory wird in YAML spezifiziert. Hier werden Gruppen, oder auch pattern, von verschiedenen Servern/Rechnern festgelegt. Es wird für jede Gruppe ein Gruppenname vergeben. Hierbei können Gruppenzugehörigkeiten vererbt werden, bzw. eine Adresse auch in unterschiedlichen Gruppen vorkommen.
Hierbei sind „webservers“, „databases“ und „dummygroup“ die jeweiligen Gruppennamen zu den Hosts.
Es ist ebenfalls möglich Host-Ranges, also eine große Anzahl an Hosts mit ähnlichem Namen festzulegen, Variablen im Inventory anzulegen sowie mehrere Inventory-Dateien zu verwenden.
Ad-hoc Befehle:
Sie können direkt über die Konsole ausgeführt werden und sind nützlich, um schnell kleinere Anpassungen auf den verwalteten nodes vorzunehmen.
Es bietet sich an, diese Funktionalität für Aufgaben zu nutzen, die man selten ausführen muss, oder die nur aus einem Befehl bestehen, wie z.B. Server-reboots:
ansible postgres -a „/sbin/reboot“
Wobei „postgres“ eine Gruppe von Servern ist und „/sbin/reboot“ die Moduloption, die für den Neustart genutzt werden soll.
Ansible Playbooks:
Playbooks sind organisierte Einheiten von wieder ausführbaren Skripten zum Verwalten von Serverkonfigurationen.
Durch Playbooks können jegliche manuelle Prozesse auf mehreren Maschinen orchestriert, sowie Prozesse synchron oder asynchron gestartet werden.
Ein Playbook wird im YAML-Format spezifiziert.
Dieses besteht aus einer Liste an Plays. Solche Plays sind Zuordnungen einer Reihe an managed nodes mit bestimmten Aufgaben („tasks“).
Playbook Anatomie mit 2 Plays:
Beispiel (https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html):
Ansible Playbooks bzw. deren Plays werden durch verschiedene Schlüsselwörter konfiguriert.
  • Dabei signalisiert „—“ den Start und das Ende eines Playbooks.
  • „name“ definiert immer einen String, der beim Ausführen des Plays ausgegeben wird.
  • „hosts“ bestimmt die Zielmaschinen durch eine oder mehrere Gruppen bzw. Host-Patterns. Im Beispiel ist „hosts“ mit den Gruppen ‚webservers‘ für den ersten bzw. ‚databases‘ für den zweiten task konfiguriert, welche eine Gruppe an Maschinen beschreibt.
  • „remote_user“ legt die Bezeichnung der aktuellen Maschine bzw. des Root-Users fest, auf dem das Playbook ausgeführt wird.
  • „tasks“ signalisiert den Anfang eines neuen Plays im Playbook. Für tasks gibt es auch verschiedene Schlüsselwörter:
    • „name“ definiert hier auch einen String, der beim Ausführen des tasks ausgegeben wird.
    • Weiters wird hier ein Modul angegeben, welches genutzt werden soll. Z.B. ‚yum‘, das die Versionierung von Paketen verwaltet. An diesem Punkt wird durch das Schlüsselwort „name“ die, vom Modul, zu betrachtende Komponente angegeben und hat somit eine andere Bedeutung als zuvor.
    • „state“ definiert auch Parameter für das Modul. Für ‚yum‘ wird im Beispiel die Zielversion von ‚postgres‘ angegeben.
Versionierung mit Git:
Durch Ansible können außerdem Aktionen mit Git durchgeführt werden.
Die Syntax für Git-Konfigurationen ist analog zur YAML-Struktur der bereits genannten Playbooks:
  • „name“ definiert die Anzeigen beim Ausführen des tasks.
  • „ansible.builtin.git“ bestimmt die Nutzung des ansible-core Git-Moduls, um mit Git zu interagieren.
  • „repo“ legt das zu nutzende Repository fest.
  • „dest“ ist das Schlüsselwort für den lokalen Dateipfad der Daten, die Git ablegt bzw. benutzt.
Beispiel:
Git Checkout:
<pre>-name: Git checkout
ansible.builtin.git:
repo: ‚https://foosball.example.org/path/to/repo.git‘
dest: /srv/checkout
version: release-0.22</pre>
Quelle[6]

Anwendungsbeispiel

Ein Unternehmen hat einen neuen Auftrag zur Erstellung einer Software erhalten. Dafür soll ein neues Team mit neuen Rechnern ausgestattet werden. Der Projektleiter für die Softwareentwicklung hat die Rahmenbedingungen für die Entwicklung definiert. Die Teamgröße wurde auf zehn Entwickler festgelegt und die benötigte Hardware ist bereits eingetroffen. Zum Einrichten der Geräte gibt er die Spezifikationen für die Rollenverteilungen, die Rechte der Entwickler, die benötigte Software und das anschließende Updateverhalten installierter Software an den zuständigen Administrator weiter. Dieser erstellt aus den vorliegenden Informationen die nötigen Gruppen für die Inventories. Alle Entwickler arbeiten mit der gleichen Software, daher wird dafür nur ein Inventory benötigt. Zwei Mitglieder agieren als Teamleiter und benötigen mehr Rechte für die Verwaltung des Repositories. Dafür sind zwei verschiedene Gruppen für die Rechte nötig. Insgesamt erstellt der Administrator drei Gruppen (Inventories) und schreibt die Playbooks für Ansible zur Softwareinstallation, Rechteverteilung und Updateverhalten. Anschließend führt er das Playbook zum Deploy der Software für alle Entwickler aus. Zum Schluss werden die definierten Rechte für die zwei verschiedenen Gruppen eingestellt.
Durch die Automatisierung der Einrichtung der Geräte musste der Administrator diese Arbeit nur einmal in den Playbooks definieren, anstatt zehnmal von Hand alle Anforderungen umzusetzen.
Nach einem Monat stellt der Projektleiter fest, dass noch drei weitere Entwickler nötig sind. Der Administrator erweitert die jeweiligen Gruppen um die Neuzugänge und kann seine Playbooks für die neuen Geräte erneut ausführen.
Neben der Zeitersparnis für den Administrator schafft die Automatisierung eine homogene Entwicklungsumgebung in der alle Entwickler mit den gleichen Versionen ihrer Programme arbeiten können.
Abbildung 1 zeigt eine mögliche Prozessmodellierung für das Anwendungsbeispiel.

Abbildung 1: Prozessmodellierung

Konkurrenz

Zwei Alternativen zu Ansible sind z.B. Chef und Puppet.
Puppet wurde bereits 2005 veröffentlicht und Chef betrat 2009 die Bühne der Automatisierungstools.
Im Gegensatz zu Ansible benötigen beide tools einen Agenten auf jedem zu verwaltenden System (Puppet-Agent und Chef-Client). Über diese Agenten können die Systeme Aktualisierungen vom Hauptsystem abfragen und ausführen. Dies kann als Pull-Configuration bezeichnet werden, während Ansible mit Push-Configuration aktiv die managed nodes anspricht.
Wie die Playbooks in Ansible, nutzt Chef Rezepte für Sammlungen von Befehlen und Zuweisungen. Um diese Dateien zu erstellen sind jedoch Kenntnisse in Ruby DSL nötig.
Alle drei tools gehören zu den am weitest verbreiteten Automatisierungswerkzeugen im Bereich Infrastructure as Code.

Fazit

Ansible ist ein Automatisierungswerkzeug, das die Verwaltung und Administration mehrerer Systeme durch ein Kontrollsystem ermöglicht.
Ansible ist agentless, das heißt auf den zu kontrollierenden Systemen ist keine Installation für die Nutzung notwendig. Voraussetzung für die Nutzung sind SSH und Python. Für die Verwendung von Ansible muss keine Programmiersprache erlernt werden. Die Ausführung kann mittels Ad-hoc Befehlen über die Kommandozeile erfolgen. Für umfangreichere Vorhaben können Playbooks erstellt werden. Dies sind Dateien, in denen Befehle und Zuweisungen im YAML-Format, einer leicht lesbaren Sprache, kombiniert werden können.
All diese Punkte machen Ansible zu einem schnell zu erlernenden Werkzeug, das mit wenig Aufwand und geringen Anforderungen an die Infrastruktur die Automatisierung verschiedener Aufgaben ermöglicht.

Quellenverzeichnis