© zssp / 123RF.com

Ansible erlaubt durch seine eingängige Syntax einen schnellen Einstieg in die Automation. In einem mehrteiligen Workshop führen wir Sie in das Thema ein. Wir beginnen mit einigen Grundlagen und dem initialen Setup einer Ansible-Umgebung.

Glaubt man den Aussagen vieler Unternehmen, haben diese ihre IT nicht nur umfassend im Griff, sondern auch durchgehend automatisiert. In Gesprächen gelangt man schnell zum Eindruck, der Grad der Automation der durchschnittlichen deutschen IT-Abteilung läge bei 150 Prozent – mindestens.

Sieht man genauer hin und wirft einen Blick in den IT-Alltag der durchschnittlichen IT-Firma, bekommt das schöne Bild schnell Risse: Zwar finden sich in den allermeisten Firmen mittlerweile – oft große – Automationsinseln. Gleichzeitig hobeln und feilen Administratoren in viel zu vielen Firmen aber auch heute noch händisch an ihren Systemen herum – mit sämtlichen bekannten Nachteilen: Handarbeit ist fehleranfällig, besonders in Stresssituationen. Sie ist langsam und mühsam, vor allem dann, wenn immer wieder dieselben Arbeitsschritte zu erledigen sind.

Der Grund für fehlende Automatisierung ist oft Zeitmangel: Viele etablierte Lösungen wie Chef, Puppet oder Salt kommen mit eigenen Deklarationssprachen daher und erfordern eine umfassende Einarbeitung. Das bezieht sich sowohl auf die interne Funktion als auch auf die Art und Weise, wie Anweisungen für das jeweilige Werkzeug zu verfassen sind.

Ansible nutzt zwar auch YAML oder JSON, verpackt allerdings seine Anweisungen so in diesen Formaten, dass sie eher wie ein normales Shell-Skript oder wie eine Skriptsammlung daherkommen. Gleichzeitig bietet Ansible Features auch für fortgeschrittene Nutzer: Beispielsweise ermöglicht es eine umfangreiche Funktionsbibliothek, Standardaufgaben zu erledigen. Das Verfassen eigener Rollen ist in Ansible eine relativ triviale Angelegenheit, und viele Rollen lassen sich zu Playbooks verketten, die umfangreiche Automation ermöglichen.

Dieser Artikel bildet den Auftakt zu einer mehrteiligen Serie rund um den Einstieg in Ansible. Der vorliegende erste Teil befasst sich mit grundlegenden Begriffen aus der Ansible-Welt, dem Setup einer für Ansible geeigneten Umgebung und der Installation der Software selbst. Die weiteren Teile werden sich fortgeschrittenen Themen zuwenden, etwa dem Erstellen eigener Rollen und Funktionen, sowie vorgefertigte Ansible-Lösungen wie Red Hats Automation Controller (ex: Ansible Tower) beschreiben. Auch der Einsatz von Ansible für das Verwalten von Ressourcen in den Hyperscaler-Umgebungen von AWS, Azure und GCP wird eine Rolle spielen.

Begrifflichkeiten

Ganz am Anfang steht bei der Beschäftigung mit Ansible die Frage nach einigen zentralen Begriffen. Zwar wirft Ansible in dieser Hinsicht deutlich weniger in die Waagschale als die Konkurrenz, doch hat sich über die Jahre eine Art Ansible-Sprech herausgebildet, der um einige zentrale Begriffe kreist. Diese muss jeder Ansible-Admin unbedingt kennen, sonst versteht er weder die Ansible-Architektur, noch kann er zentrale Funktionen der Automationslösung nutzen.

Ansible selbst etwa ist als Begriff gar nicht so eindeutig, wie mancher Admin ohne entsprechende Vorkenntnis annehmen würde. Das liegt auch an der Historie des Werkzeugs: Eingangs war »ansible« tatsächlich ein Kommandozeilenwerkzeug, das man aufrief, wollte man eine Automation in Gang setzen. Diese Rolle übernimmt heute in vielen Umgebungen stattdessen »ansible-playbook« zum Abspielen von Playbooks. Faktisch beschreibt der Begriff Ansible heute eher eine Sammlung mehrerer Werkzeuge, zu denen beispielsweise auch der Passwortmanager »ansible-vault« (Abbildung 1) gehört.

Abbildung 1: Das Verwalten von Passwörtern übernimmt »ansible-vault«. Es legt die Passwörter nicht im Klartext ab, sondern ordentlich verschlüsselt.

Damit wären – in absteigender Reihenfolge ihrer Relevanz – auch schon die drei Werkzeuge benannt, mit denen Admins es auf der Kommandozeile im Ansible-Kontext üblicherweise zu tun bekommen: Ansible-playbook, Ansible-vault und Ansible.

Apropos Playbook: Dieser Begriff spielt im Ansible-Universum eine zentrale Rolle. Er umfasst die Liste von Anweisungen, die Ansible-playbook im Kontext eines einzelnen Aufrufs zur Anwendung bringt. Ein Playbook folgt einer strikten Syntax: Es umfasst neben einer Beschreibung die abzuarbeitenden Arbeitsschritte.

Meist schreiben Admins ihre Anweisungen heute allerdings nicht mehr unmittelbar in das Playbook. Stattdessen verfassen sie für die jeweiligen Arbeitsschritte sogenannte Rollen und verweisen aus ihren Playbooks darauf. Obendrein enthält eine Rolle stets die Angabe, auf welche Hosts sie sich bezieht.

Das sogenannte Inventar (Inventory) enthält nach ebenfalls festgelegter Syntax die Liste aller Hosts, die als potenzielles Deployment-Ziel für Ansible infrage kommen. Dabei bietet Ansible Unterstützung für Gruppen: Hosts lassen sich im Inventar also entweder in der großen Liste für alle Systeme einsortieren oder in eine eigene Gruppe, zum Beispiel die Gruppe Compute.

Ansible-Syntax

Die Beschreibung grundsätzlicher Ansible-Begriffe legt bereits nahe, dass Ansible heute deutlich größer und umfangreicher ausfällt als noch vor einigen Jahren. Bis heute legen die Ansible-Entwickler aber großen Wert darauf, vor lauter Lametta die Kernaufgabe des Werkzeugs nicht zu vernachlässigen: Ansible soll einzelne Befehle in festgelegter Reihenfolge auf den Zielsystemen ausführen. Daraus ergibt sich die Ansible-Syntax, die entweder direkt in Playbooks oder alternativ in den Task-Anweisungen von Rollen zum Einsatz kommt.

Diese in Listing 1 gezeigte Form der Notation erweist sich als einer der größten Vorteile von Ansible überhaupt: Durch die Möglichkeit, einen Namen für jeden auszuführenden Arbeitsschritt anzugeben, dokumentieren sich Ansible-Rollen und Playbooks weitgehend selbst. Zwar könnte man theoretisch das »name«-Tag auch weglassen, empfohlen ist das aber nicht. Zudem macht es den Kolleginnen und Kollegen die Lektüre von Rollen und Playbooks nur unnötig schwer. Der Ansatz, jedem auszuführenden Arbeitsschritt eine Beschreibung mit auf den Weg zu geben, hat sich jedenfalls bewährt.

tasks:
 - name: Beschreibung
 Anweisung: Funktion
 Parameter: Wert
[...]

Besondere Aufmerksamkeit sollten Sie an dieser Stelle »Anweisung« und »Parameter« schenken. Ersteres bezieht sich auf eine Ansible-interne Funktion, die in der Mehrzahl der Fälle entweder aus der Funktionsbibliothek von Ansible selbst kommt oder aus einem Erweiterungsmodul. Obendrein ist es möglich, Funktionen für die Verwendung in Ansible lokal zu definieren; das kommt als Thema aber erst in einem der nächsten Teile des Workshops zur Sprache.

Ob ein »Parameter« existiert oder nicht, hängt wiederum von der in »Anweisung« aufgerufenen Funktion ab. Hier sind der Fantasie kaum Grenzen gesetzt: Die Funktion »command« ermöglicht es etwa, Kommandozeilenbefehle direkt aufzurufen. Mittels der Funktion »selinux« lässt sich der Status von SELinux auf Zielsystemen manipulieren. Beide bieten Parameter, über die sich das Verhalten der jeweiligen Funktion genauer steuern lässt.

Gerade das Beispiel von »selinux« macht zugleich deutlich, wie effektiv Ansible dem Administrator bei der Arbeit unter die Arme greift. Auf allen Systemen, die ab Werk mit SELinux daherkommen, lässt es sich auch deaktivieren. Die Art und Weise, wie das zu geschehen hat, unterscheidet sich aber zum Beispiel schon zwischen Red Hat Enterprise Linux 8 und Red Hat Enterprise Linux 9 erheblich. Ansible kümmert sich um solche Details automatisch, indem es die Zieldistribution erkennt und die notwendigen Arbeiten ausführt. Aus Sicht des Administrators ist das vor allem praktisch, weil es riesige If-Then-Konstrukte im Ansible-Playbook unnötig macht.

Apropos If und Then: Auch diese Funktionen bietet Ansible in eingeschränktem Maß. So lässt sich beispielsweise das Ausführen einzelner Befehle vom Rückgabewert eines anderen Kommandos abhängig machen. Mittels einer Art Speicherfunktion kann man die Ergebnisse einzelner Aktionen in Variablen ablegen, anhand derer man dann wieder If-Funktionen definiert.

Bevor es an dieser Stelle zu tief ins Detail geht, wenden wir uns jedoch erst einmal den grundlegenden Schritten zu: Wie kommen Administratoren möglichst schnell zu einer lauffähigen Ansible-Umgebung?

Ansible installieren

Am Anfang jeder Arbeit mit Ansible steht dessen Installation. Obwohl das Tool sich mittlerweile großer Beliebtheit erfreut, gehört es bei den meisten Distributionen nicht zum Standardlieferumfang. Rocky Linux und AlmaLinux, RHEL 8/9, SLES sowie Debian und Ubuntu bringen zwar zum Teil Ansible-Pakete mit, doch die sind – wie bei Distributionen mit Langzeitunterstützung üblich – oft ziemlich angestaubt. Damit fehlen in der Regel aktuelle, komfortable Features. Besser verwenden Sie gleich jene Pakete, die Ansible als Open-Source-Projekt selbst für die diversen Systeme anbietet.

Allerdings finden sich diese Pakete regelmäßig nicht unmittelbar in einem vom Ansible-Projekt angebotenen Paketverzeichnis, sondern in Sonderverzeichnissen der Distributoren. So verhält es sich etwa bei AlmaLinux. Die aktuellste verfügbare Version von Ansible finden Sie dort in Form von ansible-core im RPM-Verzeichnis des Appstream-Projekts. Analog funktioniert das bei Rocky Linux 9, das wie AlmaLinux 9 binärkompatibel zu RHEL 9 ist und das Appstream-Verzeichnis ebenfalls anbietet.

Unter RHEL 9 lassen sich die Pakete aus dem Appstream-Verzeichnis ebenfalls nutzen. Dabei handelt es sich dann aber um das offizielle Appstream-Repo, und darauf bekommen nur solche Nutzer Zugriff, die eine gültige RHEL-Subskription besitzen. Die Pakete aus den Appstream-Repositories von AlmaLinux oder Rocky Linux sollten zwar durchaus funktionieren. Die installieren Sie als RHEL-Admin aber auf eigene Gefahr, und jegliche Gedanken an Support von Red Hat sind in einem solchen Szenario hinfällig.

Ähnlich stehen die Dinge bei Suse Enterprise Linux. Hier findet Ansible sich als Teil des Suse Package Hub Repository, wenn auch ohne Unterstützung seitens des Herstellers. Analoges gilt für Ubuntu. Wie üblich kommt die Rettung in Form eines PPAs daher. Nach dem Ausführen der Befehle aus Listing 2 sollten sowohl »ansible« als auch »ansible-vault« zur Verfügung stehen. Verwenden Sie stattdessen lieber Debian, finden Sie wahlweise in “Bullseye” eine halbwegs aktuelle Ansible-Version oder greifen bei Vorliegen der passenden Pakete zu einem späteren Zeitpunkt auf die entsprechenden Backports zurück.

$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt update && sudo apt install ansible

Setup mit Struktur

Bevor Sie nun allerdings zur Tat schreiten und auf Ihren Servern wahllos Ansible ausrollen, sollte Sie zumindest kurz über die Struktur Ihres Ansible-Setups nachdenken. Ansible nutzt – und auch darin liegt ein großer Unterschied zur Konkurrenz – SSH für die Verbindung zu den Zielsystemen. Es kommt also kein komplexes Server-Client-Protokoll zum Einsatz. Stattdessen genügt es, die auszuführenden Rollen und Playbooks in einem lokalen Verzeichnis zu lagern, von wo aus sie per SSH zu den Systemen gelangen, damit die Automation klappt. Das eröffnet einige praktische Möglichkeiten.

So hat es sich eingebürgert, dass Administratoren in ihrem Setup ein System zum Ansible Host oder zur Cluster Workstation erklären und dort die Struktur für Ansible bereithalten. Der Host ist oft auch der einzige Rechner im gesamten Setup, der Zugriff auf das Internet hat. Die anderen Systeme nutzen meist Proxy-Server, falls sie selbst mit dem Netz kommunizieren müssen. Die einzige Voraussetzung, die solch ein Ansible-Host erfüllen muss, ist der Zugriff per SSH auf alle Zielsysteme. Falls der Zugriff auf einzelne Systeme nur über einen weiteren SSH-Host gelingt, also einen Jumphost, lässt sich auch das relativ leicht bewerkstelligen: In seiner Inventar-Datei ermöglicht Ansible es, dem Aufruf von »ssh« beliebige Parameter mit auf den Weg zu geben, entsprechend also auch ein passendes Proxy-Kommando.

Die Architektur ohne eigene Agenten und ohne spezielles Client-Protokoll sorgt im Übrigen für einen weiteren angenehmen Nebeneffekt: Sie macht es zum Kinderspiel, die eigene Ansible-Infrastruktur redundant auszulegen. Über den hochverfügbaren Betrieb irgendwelcher Server-Dienste müssen Sie sich keine Gedanken machen. Damit entfällt auch die Planung eines HA-Setups mit eher unangenehmen Faktoren wie Pacemaker und Konsorten. Es genügt, die gesammelten Werke, die Ansible auf den Zielsystemen ausführen soll, lokal in Form eines Ordners vorzuhalten und eine aktuelle Version von Ansible installiert zu haben.

Das führt zu einem zentralen Faktor der Verwaltung der eigenen Ansible-Infrastruktur, nämlich der Art und Weise, wie man diese sinnvoll speichert. Weil das Gros der für Ansible benötigten Dateien wohl aus Text bestehen dürfte, liegt die Verwaltung in Form eines Versionskontrollsystems auf der Hand. Unter Linux ist hier Git das natürliche Mittel der Wahl. Am Anfang jeder Ansible-Automation steht deshalb meist auch kein Ansible-Befehl, sondern ein Git-Kommando: Innerhalb eines eigens für die künftige Arbeit mit Ansible geschaffenen Ordners legen Sie via »git init .« die Verzeichnisstruktur von Git an.

Erste Schritte

Wie eingangs erwähnt, benötigt Ansible ein Inventar, aus dem es Informationen zu den verfügbaren Systemen gewinnt. Im einfachsten Fall ist das eine Textdatei, die Hosts auflistet und gegebenenfalls in Gruppen unterteilt.

Das ist allerdings nicht die einzige Quelle, die Ansible für das eigene Inventar nutzen kann. Im Netz finden sich etliche Lösungen, die das Inventar aus anderen Diensten dynamisch auslesen. Setzen Sie beispielsweise das IPAM-DCIM-Werkzeug Netbox ein, beziehen Sie das Inventar auf Wunsch auch daraus.

Um zum ersten erfolgreichen Ansible-Aufruf in diesem Workshop zu kommen, steht aber das Anlegen eines Inventars zu Fuß auf dem Programm. Die gute Nachricht: Das Inventar nutzt in Ansible im einfachsten Fall eine INI-ähnliche Syntax (Abbildung 2). Ein valides, für Ansible nutzbares Inventar zeigt Listing 3.

Abbildung 2: Das Ansible-Inventar liefert Ansible alle Informationen über die zu nutzenden Systeme, inklusive des benötigten Benutzernamens.

[webservers]
server1.internal
server2.internal
server3.internal

Eine besondere Bedeutung kommt dabei DNS zu, denn Ansible muss in der Lage sein, die Host-Namen der referenzierten Systeme aufzulösen. Klappt das aus irgendeinem Grund nicht, etwa weil der lokale DNS-Dienst nicht richtig eingerichtet ist, springen Sie Ansible zur Seite, indem Sie »ansible_host=IP-Adresse« hinter jede Zeile im Inventar einfügen. Je nach Setup fallen zudem weitere Einstellungen an.

Verbindungsfragen

Von zentraler Bedeutung ist etwa die Frage, wie Ansible auf den Zielsystemen zu einer Shell mit Root-Rechten kommt. Hier kollidieren regelmäßig die eigentlich sinnvollen Sicherheitsvorkehrungen von Unternehmen mit den Bedürfnissen der Automation. Aus guten Gründen gilt es heute beispielsweise als verpönt, Root den SSH-Login auf ein System unmittelbar zu ermöglichen.

Distributionen wie Ubuntu, das in unserem Beispiel sowohl auf den Ansible-Workstations als auch auf den Zielsystemen zum Einsatz kommt, verbieten Root den Login per Sshd-Konfiguration explizit. Dagegen spricht auch grundsätzlich nichts, denn in Form von Sudo und der Eingabe des jeweiligen Passworts klappt der Zugang zum Account des Systemverwalters auch auf diesen Systemen.

Dazu geben Sie Ansible sowohl den Benutzernamen als auch das Passwort mit, das es nach der Eingabe von »sudo« benötigt. Ansible beherrscht den Umweg über Sudo nämlich bereits ab Werk. Die Parameter »ansible_user=ubuntu« und »ansible_sudo_pass=sehrgeheim« in der Zeile des jeweiligen Hosts im Inventar bringen Ansible dazu, sich auf dem Zielsystem als »ubuntu« einzuloggen und danach »sudo« mit dem Passwort »sehrgeheim« aufzurufen.

Über Sinn und Unsinn der Verwendung von Passwörtern lässt sich hier aber trefflich streiten. Längst gelten Passwörter im IT-Alltag der Systemadministration als ebenso verpönt wie der Login als Root, zumal in Form von SSH-Schlüsseln eine äußerst mächtige Alternative zur Verfügung steht. Wer den Login auf seinen Systemen per SSH mit Passwort vollständig unterbunden hat und stattdessen die Verwendung von SSH-Schlüsseln erzwingt, gewinnt durch die Eingabe des Passworts bei »sudo« allenfalls noch geringe zusätzliche Sicherheit. Hier lohnt es sich, zumindest darüber nachzudenken, die Verwendung des Passworts zum Zugriff auf »sudo« abzuschalten.

Noch radikaler geht vor, wer den Login als Root auf einem System zwar erlaubt, die Verbindung per SSH-Schlüssel dafür aber zur Bedingung macht. Zumindest in kleinen Unternehmen ohne allzu ausschweifende Compliance-Regulierung kann das eine valide Alternative dazu sein, mit Passwörtern und Sudo herumzuhantieren.

Dem in Sachen Sicherheit sensibilisierten Auge fällt zudem sofort auf, dass die Angabe eines Passworts im Klartext im Ansible-Inventar gerade dann keine echte Option ist, wenn man die Ansible-Dateien in Git verwaltet und sie später – zumindest intern – per Webbrowser irgendwo im freien Zugriff liegen. Das Problem lässt sich zwar lösen, indem Sie Ansible-vault nutzen und die Inventar-Datei von der einfachen INI-Syntax auf YAML oder JSON umstellen. Ansible unterstützt das durchaus. Wie groß der Sicherheitsgewinn dabei tatsächlich ausfällt, scheint aber diskussionswürdig.

Aus Gründen der Übersichtlichkeit nutzen wir hier deshalb einen anderen Ansatz. Ein Login als Root ist zwar weder auf den Zielsystemen noch auf den Ansible-Workstations erlaubt, doch ist auf allen Setups der Umgebung der öffentliche Teil des SSH-Schlüssels des ausführenden Admins in der Datei »~/.ssh/authorized_hosts« hinterlegt. Mittels des Benutzernamens ubuntu und dank aktivierten SSH-Forwardings erreicht der ausführende Admin also jedes Zielsystem ohne die Eingabe eines Passworts. Sudo ist auf den Zielsystemen so konfiguriert, dass es keine Passwortabfrage mehr anzeigt. Rufen Sie in diesem Setup »ansible-playbook« auf, erbt es quasi die SSH-Verbindung des ausführenden Nutzers samt Agent Forwarding und wird durch entsprechende Anweisungen im Playbook später zu Root.

Das erste Playbook

Haben Sie das Inventar – im Beispiel lautet der Name der Datei »hosts« – den Notwendigkeiten der Umgebung gemäß angelegt, genügt der Befehl »ansible all -i hosts -m ping«, um zu prüfen, ob es funktioniert (Abbildung 3). Kommt hier für alle Hosts als Ergebnis OK zurück, ist die erste Version des Inventars fertig und sämtliche Komponenten zusammengetragen, die das Ausführen eines ersten echten Playbooks möglich machen.

Abbildung 3: Ob das Aufsetzen des Inventars funktioniert hat, lässt sich mittels des Ansible-Moduls »ping« gut verifizieren.

Weil es gerade für einige Programme der Gegenwart von größter Bedeutung ist, stets die richtige Uhrzeit zu kennen und über alle Server des Setups hinweg synchron zu halten, bietet sich das Thema Zeit dabei perfekt an. Wo früher noch Ntpd zum Einsatz kam, entscheiden die meisten Admins sich heute eher für Chrony. Um zum ersten erfolgreich ausgerollten Ansible-Dienst zu kommen, benötigen Sie also eine Ansible-Rolle für Chronyd, das passende Playbook und das Inventar. Hier zeigt sich eine Herausforderung, mit der Sie im Alltag regelmäßig konfrontiert werden: die Suche nach passenden Ansible-Rollen, um bestimmte Dienste auf den Zielsystemen zu installieren und zu konfigurieren.

Rund um Ansible herum hat sich eine sehr aktive Community etabliert, die fertige Rollen für Dienste wie Chronyd unter einer freien Lizenz zur Verfügung stellt. Bevor Sie also eine eigene Rolle für Ihre Dienste schreiben, lohnt sich eine kurze Recherche. Im konkreten Beispiel führt die zu einer Ansible-Rolle [1] von François Kubler auf Github (Abbildung 4). Im nächsten Schritt legen Sie innerhalb des Ansible-Ordners – also dort, wo sich auch »hosts« befindet – den Ordner »roles« an. Dorthin entpacken Sie den Ordner der Rolle von Github oder checken ihn per »git« an diese Stelle aus.

Abbildung 4: Auf Diensten wie Github finden sich mittlerweile unzählige quelloffene Playbooks und Rollen für die Nutzung mit Ansible.

Zu guter Letzt legen Sie die Datei »chronyd.yaml« mit dem Inhalt aus Listing 4 an, das eigentliche Playbook. Die einzelnen Zeilen sind, sofern sie sich nicht ohnehin selbst erklären, schnell erläutert: »hosts: all« signalisiert Ansible, dass das Playbook sich auf sämtliche Hosts aus dem Inventar bezieht. »become: true« instruiert Ansible, auf den Systemen per Sudo die Systemrechte von Root zu erlangen. Der ganze Rest legt fest, welche Rollen dieses Playbook auf die Zielsysteme anwendet und mit welcher Konfiguration es das tut.

- hosts: all
  become: true
  roles:
    - role: frzk.chrony
      chrony_service_name: chronyd
      chrony_ntp_servers:
        - 0.ubuntu.pool.ntp.org iburst maxpoll 10
        - 1.ubuntu.pool.ntp.org iburst maxpoll 10
        - 2.ubuntu.pool.ntp.org iburst maxpoll 10
        - 3.ubuntu.pool.ntp.org iburst maxpoll 10

Hier wird deutlich, wie Ansible mit Variablen umgeht. Die meisten fertigen Rollen arbeiten mit generischen Variablen, die spezifisch für ein Setup in einem Playbook vor Ort mit konkreten Werten versehen sind. Das ermöglicht, dieselbe Rolle in zahllosen Setups weltweit zu nutzen, statt dem lokalen und mühsamen Not-invented-here-Prinzip zu folgen und ständig eigene Rollen zu verfassen.

Obendrein haben Rollen aus dem Netz in der Regel eine gewisse Entwicklungszeit hinter sich und kommen mit etlichen Problemen gut zurecht, statt sie auf den Admin abzuwälzen. Die Chrony-Rolle von François Kubler etwa installiert, falls nötig, auf den Zielsystemen nicht nur Chronyd zusammen mit einer entsprechenden Systemd-Unit. Sie deaktiviert zudem eventuell schon vorhandene Konkurrenzdienste wie Ntpd, damit die Zeitsynchronisierer auf dem System sich nicht ins Gehege kommen.

Sind alle Vorbereitungen getroffen, führt der Befehl »ansible-playbook -i hosts chronyd.yaml« das Playbook aus. Nach ein wenig Wartezeit sollte die Meldung »ok« für alle Zielsysteme Zeugnis davon geben, dass das Deployment funktioniert hat (Abbildung 5).

Abbildung 5: Zeigt Ansible am Ende eine Liste der »changed«-Aktionen an, die alle auf »ok« stehen, war der Ansible-Lauf erfolgreich. Quelle: unixsysadmin