Ansible: Up and Running, 3. Auflage

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Es ist eine interessante Zeit, um in der IT-Branche zu arbeiten. Wir liefern unseren Kunden keine Software mehr, indem wir ein Programm auf einem einzigen Computer installieren und dann Feierabend machen. Stattdessen werden wir alle nach und nach zu Cloud-Ingenieuren.

Wir stellen Softwareanwendungen bereit, indem wir Dienste aneinanderreihen, die auf verteilten Rechenressourcen laufen und über verschiedene Netzwerkprotokolle kommunizieren. Eine typische Anwendung kann Webserver, Anwendungsserver, speicherbasierte Caching-Systeme, Task Queues, Message Queues, SQL-Datenbanken, NoSQL-Datenspeicher und Load Balancer umfassen.

IT-Fachleute müssen auch sicherstellen, dass die richtigen Redundanzen vorhanden sind, damit unsere Softwaresysteme im Falle von Ausfällen (und die wird es geben) diese problemlos bewältigen. Dann gibt es noch die sekundären Dienste, die wir bereitstellen und warten müssen, wie z. B. Protokollierung, Überwachung und Analyse, sowie die Dienste von Drittanbietern, mit denen wir interagieren müssen, wie z. B. Infrastructure-as-a-Service (IaaS)-Endpunkte zur Verwaltung virtueller Maschineninstanzen.¹

Du kannst diese Dienste auch von Hand einrichten, indem du die benötigten Server hochfährst, dich auf jedem einzelnen anmeldest, Pakete installierst, Konfigurationsdateien bearbeitest usw., aber das ist mühsam. Es ist zeitaufwändig, fehleranfällig und einfach nur langweilig, diese Arbeit von Hand zu machen, vor allem beim dritten oder vierten Mal. Und bei komplexeren Aufgaben, wie dem Aufbau einer OpenStack-Cloud, ist es Wahnsinn, alles von Hand zu machen. Es muss einen besseren Weg geben.

Wenn du dies liest, bist du wahrscheinlich schon von der Idee des Konfigurationsmanagements überzeugt und erwägst, Ansible als dein Konfigurationsmanagement-Tool einzusetzen. Egal, ob du ein Entwickler bist, der seinen Code in der Produktion einsetzt, oder ein Systemadministrator, der nach einer besseren Möglichkeit zur Automatisierung sucht - ich denke, du wirst feststellen, dass Ansible eine hervorragende Lösung für dein Problem ist.

Ein Hinweis zu Versionen

Der Beispielcode in diesem Buch wurde mit verschiedenen Versionen von Ansible getestet. Ansible 5.9.0 ist die aktuellste Version zum Zeitpunkt der Erstellung dieses Buches; Ansible Tower enthält die Version 2.9.27 in der neuesten Version. Ansible 2.8 hat mit der Veröffentlichung von 2.8.20 am 13. April 2021 sein Lebensende erreicht. Erwarte, dass Ansible sich weiterentwickelt.

Seit Jahren ist die Ansible-Gemeinschaft sehr aktiv bei der Erstellung von Rollen und Modulen - so aktiv, dass es Tausende von Modulen und mehr als 20.000 Rollen gibt. Die Schwierigkeiten, ein Projekt dieser Größenordnung zu verwalten, veranlassten die Ersteller, die Inhalte von Ansible in drei Teile zu gliedern:

• Kernkomponenten, erstellt vom Ansible-Team

• Zertifizierte Inhalte, erstellt von Red Hats Geschäftspartnern

• Community-Inhalte, erstellt von Tausenden von Enthusiasten weltweit

Ansible 2.9 hat eine Menge eingebauter Funktionen, und spätere Versionen sind besser zusammensetzbar. Dieser neue Aufbau macht Ansible als Ganzes leichter wartbar.

Die Beispiele in diesem Buch sollten in verschiedenen Versionen von Ansible funktionieren, aber Versionsänderungen erfordern im Allgemeinen Tests, die wir in Kapitel 14 behandeln werden.

Was hat es mit dem Namen Ansible auf sich?

Es ist eine Science-Fiction-Referenz. Ein Ansible ist ein fiktives Kommunikationsgerät, das Informationen schneller als mit Lichtgeschwindigkeit übertragen kann. Ursula K. Le Guin erfand das Konzept in ihrem Buch Rocannon's World (Ace Books, 1966), und andere Science-Fiction-Autoren haben die Idee seitdem aufgegriffen, darunter Orson Scott Card. Der Mitbegründer von Ansible, Michael DeHaan, hat den Namen Ansible von Card's Buch Ender's Game (Tor, 1985) übernommen. In diesem Buch wurde die Ansible benutzt, um viele Schiffe über große Entfernungen gleichzeitig zu steuern. Sieh es als eine Metapher für die Steuerung von Servern aus der Ferne.

Ansible: Wozu ist es gut?

Ansible wird oft als Konfigurationsmanagement-Tool bezeichnet und in einem Atemzug mit Puppet, Chef und Salt genannt. Wenn IT-Fachleute von Konfigurationsmanagement sprechen, meinen wir damit in der Regel, dass wir eine Art Zustandsbeschreibung für unsere Server verfassen und dann ein Tool einsetzen, das sicherstellt, dass sich die Server tatsächlich in diesem Zustand befinden: Die richtigen Pakete sind installiert, die Konfigurationsdateien haben die erwarteten Werte und die erwarteten Berechtigungen, die richtigen Dienste laufen und so weiter. Wie andere Konfigurationsmanagement-Tools stellt Ansible eine domänenspezifische Sprache (DSL) zur Verfügung, mit der du den Zustand deiner Server beschreibst.

Du kannst diese Tools auch für die Softwareverteilung nutzen. Wenn von Bereitstellung die Rede ist, geht es in der Regel um die Erstellung von Binärdateien oder statischen Assets (falls erforderlich) aus Software, die von internen Entwicklern geschrieben wurde, das Kopieren der erforderlichen Dateien auf Server, das Hinzufügen von Konfigurationseigenschaften und Umgebungsvariablen und das Starten von Diensten in einer bestimmten Reihenfolge. Capistrano und Fabric sind zwei Beispiele für Open Source Deployment Tools. Ansible ist ein großartiges Tool für die Bereitstellung und das Konfigurationsmanagement. Ein einziges Tool für beides zu verwenden, macht das Leben derjenigen einfacher, die für die Systemintegration zuständig sind.

Manche Leute sprechen von der Notwendigkeit, Einsätze zu orchestrieren. Unter Orchestrierung versteht man die Koordination der Bereitstellung, wenn mehrere Remote-Server beteiligt sind und die Dinge in einer bestimmten Reihenfolge geschehen müssen. So kann es z. B. notwendig sein, die Datenbank vor den Webservern einzurichten oder die Webserver nacheinander aus dem Load Balancer herauszunehmen, um sie ohne Ausfallzeiten zu aktualisieren. DeHaan hat Ansible von Grund auf so konzipiert, dass es diese Aufgaben gut bewältigen und Aktionen auf mehreren Servern durchführen kann. Es verfügt über ein erfrischend einfaches Modell zur Steuerung der Reihenfolge, in der die Aktionen ausgeführt werden.

Schließlich wird auch von der Bereitstellung neuer Server gesprochen. Im Zusammenhang mit öffentlichen Clouds wie Amazon EC2 bezieht sich die Bereitstellung auf das Aufsetzen neuer virtueller Maschineninstanzen oder Cloud-nativer Software-as-a-Service (SaaS). Ansible bietet dir hier Module für die Kommunikation mit Clouds wie EC2, Azure,² Digital Ocean, Google Compute Engine, Linode, und Rackspace,³ sowie mit allen Clouds, die die OpenStack-APIs unterstützen.

Hinweis

Verwirrenderweise verwendet das Tool Vagrant, das später in diesem Kapitel behandelt wird, den Begriff Provisioner für ein Tool, das Konfigurationsmanagement betreibt. Es bezeichnet Ansible also als eine Art Provisioner. Vagrant bezeichnet Tools, die Maschinen erstellen, wie z.B. VirtualBox und VMWare, als Provider. Vagrant verwendet den Begriff Maschine für eine virtuelle Maschine und Box für ein Image einer virtuellen Maschine.

Wie Ansible funktioniert

Abbildung 1-1 zeigt ein Anwendungsbeispiel für Ansible in Aktion. Ein Benutzer, den wir Alice nennen, verwendet Ansible, um drei Ubuntu-basierte Webserver für den Betrieb von NGINX zu konfigurieren. Sie hat ein Skript namens webservers.yml geschrieben. In Ansible wird das Äquivalent eines Skripts als Playbook bezeichnet. Ein Playbook beschreibt, welche Hosts (Ansible nennt sie Remote-Server) konfiguriert werden sollen, und enthält eine geordnete Liste von Aufgaben, die auf diesen Hosts ausgeführt werden sollen. In diesem Beispiel sind die Hosts web1, web2 und web3, und die Aufgaben sind z. B. folgende:

• NGINX installieren

• Erstelle eine NGINX-Konfigurationsdatei

• Kopiere das Sicherheitszertifikat

• Starte den NGINX-Dienst

Abbildung 1-1. Ausführen eines Ansible-Playbooks zur Konfiguration von drei Webservern

Im nächsten Kapitel werden wir genauer erklären, was in diesem Playbook steht; jetzt konzentrieren wir uns auf seine Rolle im Gesamtprozess. Alice führt das Playbook mit dem Befehl ansible-playbook aus. Alice startet ihr Ansible-Playbook, indem sie zuerst den Befehl und dann den Namen des Playbooks in eine Terminalzeile eintippt:

$ ansible-playbook webservers.yml

Ansible stellt parallel SSH-Verbindungen zu web1, web2 und web3 her und führt dann die erste Aufgabe auf der Liste auf allen drei Hosts gleichzeitig aus. In diesem Beispiel ist die erste Aufgabe die Installation des NGINX-Pakets, also würde die Aufgabe im Playbook etwa so aussehen:

- name: Install nginx
  package:
    name: nginx

Ansible wird Folgendes tun:

1. Erstelle ein Python-Skript, das das NGINX-Paket installiert

2. Kopiere das Skript auf web1, web2 und web3

3. Führe das Skript auf web1, web2 und web3 aus

4. Warte darauf, dass das Skript auf allen Hosts vollständig ausgeführt wird

Ansible geht dann zur nächsten Aufgabe in der Liste über und durchläuft dieselben vier Schritte.

Es ist wichtig, Folgendes zu beachten:

1. Ansible führt jede Aufgabe parallel auf allen Hosts aus.

2. Ansible wartet, bis alle Hosts eine Aufgabe abgeschlossen haben, bevor es zur nächsten Aufgabe übergeht.

3. Ansible führt die Aufgaben in der Reihenfolge aus, in der du sie angibst.

Was ist so toll an Ansible?

Es gibt mehrere Open-Source-Konfigurationsmanagement-Tools zur Auswahl. Warum also Ansible? Hier sind 21 Gründe, die uns dazu bewogen haben. Kurz gesagt: Ansible ist einfach, leistungsstark und sicher.

Einfach

Ansible wurde so konzipiert, dass der Einrichtungsprozess sehr einfach ist und die Lernkurve minimal.

Leicht zu lesende Syntax

Ansible verwendet das YAML-Dateiformat und Jinja2 Templating, die beide leicht zu erlernen sind. Die Skripte für das Ansible-Konfigurationsmanagement werden Playbooks genannt. Ansible baut die Playbook-Syntax auf YAML auf. YAML ist eine Datenformatsprache, die für Menschen leicht zu lesen und zu schreiben sein soll. In gewisser Weise ist YAML für JSON das, was Markdown für HTML ist.

Leicht zu prüfen

Du kannst Ansible-Playbooks auf verschiedene Arten überprüfen, z. B. indem du alle Aktionen und beteiligten Hosts auflistest. Für Trockenübungen verwenden wir oft ansible-playbook --check. Mit der integrierten Protokollierung ist es einfach zu sehen, wer was und wo gemacht hat. Die Protokollierung ist steckbar und Log Collectors können die Protokolle leicht einlesen.

Wenig bis nichts auf den entfernten Hosts zu installieren

Um Server mit Ansible zu verwalten, müssen auf Linux-Servern SSH und Python installiert sein, während auf Windows-Servern WinRM aktiviert sein muss. Unter Windows verwendet Ansible die PowerShell anstelle von Python, sodass kein Agent oder eine andere Software auf dem Host vorinstalliert werden muss.

Auf dem Kontrollrechner (d.h. dem Rechner, den du zur Steuerung der entfernten Rechner verwendest) installierst du am besten Python 3.8 oder höher. Abhängig von den Ressourcen, die du mit Ansible verwaltest, brauchst du möglicherweise externe Bibliotheken. Schau in der Dokumentation nach, ob ein Modul bestimmte Anforderungen hat.

Ansible skaliert nach unten

Die Autoren dieses Buches verwenden Ansible, um Hunderte von Knotenpunkten zu verwalten. Aber was uns fasziniert hat, ist die Skalierbarkeit der Software. Du kannst Ansible auf sehr bescheidener Hardware einsetzen, wie einem Raspberry Pi oder einem alten PC. Die Konfiguration eines einzelnen Knotens ist einfach: Du schreibst einfach ein einziges Playbook. Ansible hält sich an Alan Kays Maxime: "Einfache Dinge sollten einfach sein, komplexe Dinge sollten möglich sein."

Leicht zu teilen

Wir erwarten nicht, dass du Ansible-Playbooks in verschiedenen Kontexten wieder verwendest. In Kapitel 7 werden wir über Rollen sprechen, mit denen du deine Playbooks organisieren kannst, und über Ansible Galaxy, ein Online-Repository für diese Rollen.

Die wichtigste Einheit für die Wiederverwendung in der Ansible Community ist heutzutage die Sammlung. Du kannst deine Module, Plug-ins, Bibliotheken, Rollen und sogar Playbooks in einer Sammlung organisieren und sie auf Ansible Galaxy teilen. Du kannst sie auch intern mit dem Automation Hub, einem Teil von Ansible Tower, teilen. Rollen können als einzelne Repositories geteilt werden.

In der Praxis sieht es jedoch so aus, dass jedes Unternehmen seine Server ein wenig anders einrichtet und du am besten Playbooks für dein Unternehmen schreibst, anstatt zu versuchen, allgemeine Playbooks wiederzuverwenden. Wir glauben, dass die Playbooks anderer vor allem dazu dienen, zu sehen, wie die Dinge funktionieren, es sei denn, du arbeitest mit einem bestimmten Produkt, für das der Anbieter ein zertifizierter Partner ist oder sich in der Ansible-Community engagiert.

Systemabstraktion

Ansible arbeitet mit einfachen Abstraktionenvon Systemressourcen wie Dateien, Verzeichnissen, Benutzern, Gruppen, Diensten, Paketen und Webservices.

Zum Vergleich schauen wir uns an, wie man ein Verzeichnis in der Shell konfiguriert. Du würdest diese drei Befehle verwenden:

mkdir -p /etc/skel/.ssh
chown root:root /etc/skel/.ssh
chmod go-wrx /etc/skel/.ssh

Im Gegensatz dazu bietet Ansible das Modul file als Abstraktion an, in dem du die Parameter des gewünschten Zustands definierst. Diese eine Aktion hat die gleiche Wirkung wie die drei Shell-Befehle zusammen:

- name: Ensure .ssh directory in user skeleton
  file:
    path: /etc/skel/.ssh
    mode: '0700'
    owner: root
    group: root
    state: directory

Mit dieser Abstraktionsebene kannst du dieselben Konfigurationsmanagement-Skripte verwenden, um Server mit Linux-Distributionen zu verwalten. Anstatt dich mit einem speziellen Paketmanager wie dnf, yum oder apt auseinandersetzen zu müssen, bietet Ansible eine "Paket"-Abstraktion, die du stattdessen verwenden kannst (beachte aber, dass die Paketnamen unterschiedlich sein können). Du kannst aber auch die systemspezifischen Abstraktionen verwenden, wenn du das möchtest.

Wenn du wirklich willst, kannst du deine Ansible-Playbooks so schreiben, dass sie je nach den verschiedenen Betriebssystemen der Remote-Server unterschiedliche Aktionen ausführen. Aber Bas, einer der Autoren dieses Buches, versucht das zu vermeiden, wo er kann. Er konzentriert sich stattdessen darauf, Playbooks für die Systeme zu schreiben, die tatsächlich genutzt werden.

Aufgaben von oben nach unten

In Büchern über Konfigurationsmanagement wird oft das Konzept der Konvergenz, also des konsistenten Zustands, erwähnt. Konvergenz im Konfigurationsmanagement ist eng mit dem Konfigurationsmanagementsystem CFEngine von Mark Burgess verbunden. Wenn ein Konfigurationsmanagementsystem konvergent ist, kann das System mehrmals ausgeführt werden, um einen Server in den gewünschten Zustand zu versetzen, wobei jeder Durchlauf den Server näher an diesen Zustand bringt.

Ein eventueller konsistenter Zustand trifft auf Ansible nicht wirklich zu, da es nicht mehrmals ausgeführt wird, um Server zu konfigurieren. Stattdessen funktionieren die Ansible-Module so, dass die einmalige Ausführung eines Playbooks jeden Server in den gewünschten Zustand versetzen sollte.

Leistungsstark

Wenn du Ansible zur Verfügung hast, kannst du deine Produktivität in verschiedenen Bereichen der Systemverwaltung enorm steigern. Die hochgradigen Abstraktionen, die Ansible bietet (wie z.B. Rollen), machen es möglich, dass du Dinge schneller und potenziell sicherer einrichten und konfigurieren kannst.

Inklusive Batterien

Du kannst Ansible verwenden, um beliebige Shell-Befehle auf deinen Remote-Servern auszuführen, aber die wahre Stärke von Ansible liegt in der großen Vielfalt der verfügbaren Module. Du verwendest Module, um Aufgaben wie die Installation eines Pakets, den Neustart eines Dienstes oder das Kopieren einer Konfigurationsdatei auszuführen.

Wie du später sehen wirst, sind Ansible-Module deklarativ; du verwendest sie, um den Zustand zu beschreiben, in dem sich der Server befinden soll. Du würdest zum Beispiel das Modul user wie folgt aufrufen, um sicherzustellen, dass ein Konto mit dem Namen "deploy" in der Webgruppe vorhanden ist:

- name: Ensure deploy user exists
  user:
    name: deploy
    group: web

Push-basiert

Chef und Puppet sind Konfigurationsmanagementsysteme, die Agenten verwenden. Sie sind standardmäßig Pull-basiert. Agenten, die auf den Servern installiert sind, melden sich regelmäßig bei einem zentralen Dienst und laden Konfigurationsinformationen von diesem herunter. Wenn du Änderungen an der Konfiguration von Servern vornimmst, geht das in etwa so:

1. Du: nimmst eine Änderung an einem Konfigurationsmanagement-Skript vor.

2. Du: Übergib die Änderung an einen zentralen Dienst für das Konfigurationsmanagement.

3. Agent auf dem Server: wacht auf, nachdem der Timer ausgelöst wurde.

4. Agent auf dem Server: stellt eine Verbindung zum zentralen Dienst für das Konfigurationsmanagement her.

5. Agent auf dem Server: lädt neue Konfigurationsmanagement-Skripte herunter.

6. Agent auf dem Server: Führt lokal Skripte zur Konfigurationsverwaltung aus, die den Serverstatus ändern.

Im Gegensatz dazu ist Ansible standardmäßig push-basiert. Eine Änderung sieht wie folgt aus:

1. Du: nimmst eine Änderung an einem Playbook vor.

2. Du: Führe das neue Spielbuch aus.

3. Ansible: stellt eine Verbindung zu Servern her und führt Module aus, die den Zustand der Server ändern.

Sobald du den Befehl ansible-playbook ausführst, stellt Ansible eine Verbindung zu den Remote-Servern her und führt seine Arbeit aus. Das verringert das Risiko, dass zufällige Server kaputt gehen, wenn ihre geplanten Aufgaben fehlschlagen und die Änderungen erfolgreich sind. Der Push-basierte Ansatz hat einen entscheidenden Vorteil: Du kontrollierst, wann die Änderungen auf den Servern stattfinden. Du brauchst nicht darauf zu warten, dass ein Timer abläuft. Jeder Schritt in einem Playbook kann sich auf einen oder eine Gruppe von Servern beziehen. Du kannst mehr Arbeit erledigen, anstatt dich von Hand bei den Servern anzumelden.

Multitier-Orchestrierung

Im Push-Modus kannst du Ansible auch für eine mehrstufige Orchestrierung verwenden, bei der du verschiedene Gruppen von Maschinen für einen Vorgang wie ein Update verwaltest. Du kannst das Überwachungssystem, die Load Balancer, die Datenbanken und die Webserver mit spezifischen Anweisungen orchestrieren, damit sie zusammenarbeiten. Das ist mit einem Pull-basierten System sehr schwer zu bewerkstelligen.

Meisterlos

Befürworter des Pull-basierten Ansatzes behaupten, dass für die Skalierung auf eine große Anzahl von Servern und für den Umgang mit neuen Servern, die jederzeit online gehen können, überlegen ist. Ein zentrales Konfigurationsmanagementsystem hört jedoch langsam auf zu funktionieren, wenn Tausende von Agenten gleichzeitig ihre Konfiguration ziehen, vor allem wenn sie mehrere Durchläufe benötigen, um zu konvergieren. Im Vergleich dazu verfügt Ansible über den Befehl ansible-pull, der Playbooks aus einem VCS-Repository wie GitHub ziehen kann. Ansible braucht keinen Master, aber du kannst ein zentrales System verwenden, um Playbooks auszuführen, wenn du das möchtest.

Steckbar und einbindbar

Ein großer Teil der Funktionalität von Ansible stammt aus dem Ansible-Plugin-System, von dem die Lookup- und Filter-Plug-ins am häufigsten verwendet werden. Plug-ins erweitern die Kernfunktionalität von Ansible um Logik und Funktionen, die für alle Module zugänglich sind. Module führen neue "Verben" in die Ansible-Sprache ein. Du kannst deine eigenen Plug-ins (siehe Kapitel 10) und Module(Kapitel 12) in Python schreiben.

Du kannst Ansible in andere Produkte integrieren: Kubernetes und Ansible Tower sind Beispiele für erfolgreiche Integrationen. Ansible Runner "ist ein Tool und eine Python-Bibliothek, die bei der direkten Anbindung an Ansible oder als Teil eines anderen Systems hilft, sei es über eine Container-Image-Schnittstelle, als eigenständiges Tool oder als Python-Modul, das importiert werden kann."⁴

Mit der ansible-runner-Bibliothek kannst du ein Ansible-Playbook aus einem Python-Skript heraus ausführen:

#!/usr/bin/env python3
import ansible_runner

r = ansible_runner.run(private_data_dir='./playbooks', playbook='playbook.yml')

print("{}: {}".format(r.status, r.rc))
print("Final status:")
print(r.stats)

Funktioniert mit vielen Dingen

Ansible-Module sind für eine Vielzahl von Systemadministrationsaufgaben geeignet. Diese Liste enthält die Kategorien der Module, die du verwenden kannst. Sie verweisen auf den Modulindex in der Dokumentation:

• Wolke
• Dateien
• Überwachung
• Quellenkontrolle
• Clustering
• Identität
• Net Tools
• Speicherung
• Befehle
• Infrastruktur
• Netzwerk
• System
• Krypto
• Inventar
• Benachrichtigung
• Versorgungsunternehmen
• Datenbank
• Nachrichtenübermittlung
• Verpackung
• Windows

Wirklich skalierbar

Große Unternehmen setzen Ansible erfolgreich in der Produktion mit Zehntausenden von Knoten ein und haben eine hervorragende Unterstützung für Umgebungen, in denen Server dynamisch hinzugefügt und entfernt werden. Organisationen mit Hunderten von Softwareteams verwenden in der Regel AWX oder eine Kombination aus Ansible Tower und Automation Hub für die Auditierbarkeit und für die Sicherheit mit rollenbasierten Zugriffskontrollen.

Machst du dir Sorgen über die Skalierbarkeit von SSH? Ansible nutzt SSH-Multiplexing, um die Leistung zu optimieren, und es gibt Leute, die Tausende von Knoten mit Ansible verwalten (siehe Kapitel 12 in diesem Buch).

Sicher

Die Automatisierung mit Ansible hilft uns, die Systemsicherheit gemäß den Sicherheitsgrundlagen und Compliance-Standards zu verbessern.

Kodifiziertes Wissen

Deine Autoren betrachten Ansible Playbooks gerne als ausführbare Dokumentation. Playbooks sind wie die README-Dateien, in denen früher die Befehle beschrieben wurden, die du für die Bereitstellung deiner Software eintippen musstest, mit dem Unterschied, dass diese Anweisungen nie veralten werden, weil sie auch der Code sind, der ausgeführt wird. Produktexperten können Playbooks erstellen, in denen bewährte Methoden berücksichtigt werden. Wenn Neulinge ein solches Playbook zur Installation des Produkts verwenden, können sie sicher sein, dass sie ein gutes Ergebnis erzielen.

Reproduzierbare Systeme

Wenn du dein gesamtes System mit Ansible einrichtest, wird es den von Steve Traugott so genannten "Zehntgeschoss-Test" bestehen:"Kann ich eine beliebige Maschine nehmen, die nie gesichert wurde, und sie aus dem Fenster im zehnten Stock werfen, ohne dass die Arbeit des Systemadministrators verloren geht?"

Gleichwertige Umgebungen

Ansible hat eine clevere Art, Inhalte zu organisieren, die dabei hilft, die Konfiguration auf der richtigen Ebene zu definieren. Es ist einfach, ein Setup für verschiedene Entwicklungs-, Test-, Staging- und Produktionsumgebungen zu erstellen. Eine Staging-Umgebung sollte der Produktionsumgebung so ähnlich wie möglich sein, damit die Entwickler Probleme erkennen können, bevor die Änderungen in Betrieb gehen.

Verschlüsselte Variablen

Wenn du sensible Daten wie Passwörter oder Token speichern musst, ist ansible-vault ein effektives Tool. Wir verwenden es, um verschlüsselte Variablen in Git zu speichern. Wir werden es in Kapitel 8 im Detail besprechen.

Sicherer Transport

Ansible verwendet einfach Secure Shell (SSH) für Linux und WinRM für Windows. In der Regel sichern wir diese weit verbreiteten Systemverwaltungsprotokolle mit starken Konfigurations- und Firewall-Einstellungen ab.

Wenn du lieber ein Pull-basiertes Modell verwendest, bietet Ansible offizielle Unterstützung für den Pull-Modus mit dem mitgelieferten Tool ansible-pull. In diesem Buch wird der Pull-Modus nicht behandelt, aber du kannst mehr darüber in der offiziellen Ansible-Dokumentation lesen.

Entpotenzierung

Module sind außerdem idempotent. Idempotenz ist eine gute Eigenschaft, denn sie bedeutet, dass es sicher ist, ein Ansible-Playbook mehrmals auf einem Server auszuführen. Schauen wir uns an, was das bedeutet, wenn wir einen Benutzer namens deploy brauchen:

- name: Ensure deploy user exists
  user:
    name: deploy
    group: web

Wenn der Benutzer deploy nicht existiert, wird er von Ansible erstellt. Wenn er bereits existiert, wird Ansible nichts unternehmen. Das ist eine enorme Verbesserung gegenüber der selbst erstellten Shell-Skript-Methode, bei der die Ausführung des Shell-Skripts ein zweites Mal einen anderen (und unbeabsichtigten) Effekt haben kann.⁵

Keine Dämonen

Es gibt keinen Ansible-Agenten, der auf einem Port lauscht. Wenn du Ansible verwendest, gibt es also keine zusätzliche Angriffsfläche. (Es gibt immer noch eine Angriffsfläche mit Elementen der Software-Lieferkette wie Python-Bibliotheken und anderen importierten Inhalten).

Wie ist die Beziehung von Ansible, Inc. zu Ansible?

Der Name Ansible bezieht sich sowohl auf die Software als auch auf das Unternehmen, das das Open-Source-Projekt betreibt. Michael DeHaan, der Erfinder der Software Ansible, ist der ehemalige CTO des Unternehmens Ansible. Um Verwechslungen zu vermeiden, bezeichnen wir die Software als Ansible und das Unternehmen als Ansible, Inc.

Ansible, Inc. verkauft Schulungen und Beratungsdienste für Ansible sowie ein webbasiertes Verwaltungstool namens Ansible Tower, das wir in Kapitel 19 behandeln. Im Oktober 2015 kaufte Red Hat Ansible, Inc. auf; IBM kaufte Red Hat im Jahr 2019.

Ist Ansible zu einfach?

Als Lorin an einer früheren Ausgabe dieses Buches arbeitete, erwähnte der Redakteur, dass "einige Leute, die das XYZ-Konfigurationsmanagement-Tool verwenden, Ansible als eine For-Loop über SSH-Skripte bezeichnen." Wenn du überlegst, von einem anderen Konfigurationsmanagement-Tool umzusteigen, machst du dir an dieser Stelle vielleicht Gedanken darüber, ob Ansible leistungsfähig genug ist, um deine Anforderungen zu erfüllen.

Wie du bald lernen wirst, bietet Ansible viel mehr Funktionen als Shell-Skripte. Neben der Idempotenz bietet Ansible eine hervorragende Unterstützung für Templating und die Definition von Variablen mit unterschiedlichen Gültigkeitsbereichen. Wer glaubt, dass Ansible der Arbeit mit Shell-Skripten gleichzusetzen ist, hat noch nie ein nicht-triviales, in Shell geschriebenes Programm unterstützt. Wenn wir die Wahl haben, werden wir Ansible immer den Shell-Skripten vorziehen, wenn es um Konfigurationsmanagement geht.

Was muss ich wissen?

Um mit Ansible produktiv arbeiten zu können, musst du mit den grundlegenden Aufgaben der Unix/Linux-Systemadministration vertraut sein. Ansible macht es dir leicht, deine Aufgaben zu automatisieren, aber es ist nicht die Art von Tool, die Dinge "automatisch" erledigt, die du sonst nicht beherrschen würdest.

In diesem Buch gehen wir davon aus, dass du mit mindestens einer Linux-Distribution (wie Ubuntu, RHEL/CentOS oder SUSE) vertraut bist und weißt, wie man:

• Verbinden mit einem entfernten Rechner über SSH

• Interaktion mit der Bash-Kommandozeilen-Shell (Pipes und Umleitung)

• Pakete installieren

• Verwende den sudo-Befehl

• Dateiberechtigungen prüfen und festlegen

• Dienste starten und stoppen

• Umgebungsvariablen setzen

• Skripte schreiben (jede Sprache)

Wenn dir diese Konzepte vertraut sind, kannst du mit Ansible loslegen.

Wir setzen nicht voraus, dass du Kenntnisse in einer bestimmten Programmiersprache hast. Du brauchst zum Beispiel keine Python-Kenntnisse, um Ansible zu benutzen, es sei denn, du willst dein eigenes Modul veröffentlichen.

Was nicht abgedeckt ist

Dieses Buch ist keine erschöpfende Abhandlung über Ansible. Der erste Teil ist darauf ausgelegt, dass du so schnell wie möglich produktiv mit Ansible arbeiten kannst. Dann wird beschrieben, wie du bestimmte Aufgaben ausführen kannst, die in der offiziellen Dokumentation nicht ersichtlich sind.

Wir behandeln nicht alle Module von Ansible im Detail: Es gibt mehr als 3.500 davon. Du kannst das ansible-doc Kommandozeilentool mit dem, was du installiert hast, verwenden, um die Referenzdokumentation und den bereits erwähnten Modulindex einzusehen.

Kapitel 8 behandelt nur die grundlegenden Funktionen von Jinja2, der Template-Engine, die Ansible nutzt. Das liegt vor allem daran, dass sich deine Autoren nur die grundlegenden Funktionen einprägen, wenn wir Jinja2 mit Ansible verwenden. Wenn du fortgeschrittenere Jinja2-Funktionen in Templates verwenden willst, schau dir die offizielle Jinja2-Dokumentation an.

Wir gehen auch nicht im Detail auf einige Funktionen von Ansible ein, die vor allem dann nützlich sind, wenn du es auf einer älteren Version von Linux einsetzt.

Schließlich gibt es Funktionen von Ansible, auf die wir nicht eingehen, damit das Buch eine überschaubare Länge hat. Wir empfehlen dir, in der offiziellen Dokumentation nachzuschauen, um mehr über diese Funktionen zu erfahren.

Vorwärts bewegen

In diesem Einführungskapitel wurden die grundlegenden Konzepte von Ansible auf allgemeiner Ebene behandelt. Dazu gehört auch, wie es mit Remote-Servern kommuniziert und wie es sich von anderen Konfigurationsmanagement-Tools unterscheidet. In den nächsten Kapiteln geht es darum, wie du Ansible in der Praxis einsetzen kannst.

¹ Weitere Informationen zum Aufbau und zur Wartung dieser Art von verteilten Systemen findest du in Thomas A. Limoncelli, Strata R. Chalup und Christina J. Hogan's The Practice of Cloud System Administration, Band 1 und 2 (Addison-Wesley) und Designing Data-Intensive Applications von Martin Kleppman (O'Reilly).

² Ja, Azure unterstützt Linux-Server.

³ Siehe zum Beispiel "Using Ansible at Scale to Manage a Public Cloud", eine Folienpräsentation von Jesse Keating, früher bei Rackspace.

⁴ Ansible Runner Dokumentation, letzter Zugriff am 2. Juni 2022.

⁵ Wenn du wissen willst, was der ursprüngliche Autor von Ansible über die Idee der Konvergenz denkt, schau dir den Newsgroup-Beitrag "Idempotence, Convergence, and Other Silly Fancy Words We Use Too Often" von Michael DeHaan im Ansible Project an .