Windows Server mit Ansible automatisieren (Beispiel Windows Updates)

Es muss ja nicht immer gleich SCCM sein… Ich war auf der Suche nach einer Möglichkeit, möglichst viele meiner langweiligen Aufgaben für meine eignen Systeme zu automatisieren: Backup bzw. Spiegelung der Website auf das NAS, Installation von Updates (Windows / Linux), Installation von Testumgebungen. Eben immer wieder wiederholbarer, langweiliger, zeitfressender Kram, wie gemacht für die Automatisierung und zentrale Steuerung. Ich bin dann nach einigen Tests bei Ansible gelandet, um möglichst viele Aufgaben zu automatisieren. Mittlerweile (zugegeben nach einigen Fehlschlägen) läuft es rund, daher gibt es hier mal einen kleinen Einstieg in das Thema Automatisierung mittels Ansible. Da es mein erster Anwendungsfall war, habe ich mir für das erste Beispiel das Thema Windows Updates ausgesucht.

CentOS 8 Installation

Ich nutze normalerweise Debian für die meisten meiner Linux basierten Server, in der letzten Zeit habe ich allerdings immer mehr Gefallen an CentOS gefunden. Meine privaten Systeme stelle ich gerade von Debian auf CentOS um, daher setzt nun auch dieser Artikel auf CentOS als Betriebssystem für Ansible (falls sich jemand wundern sollte, warum nicht Debian zum Einsatz kommt).

Die Installation von CentOS ist selbsterklärend, daher gibt es hier nur ein paar Screenshots zu meinem Setup:

Da ich CentOS als VM betreibe habe ich “Server” und “Gast-Agenten” ausgewählt:

Während der Installation können Root-Password festgelegt und ein Benutzer erstellt werden:

Nach ein paar Minuten ist CentOS fertig installiert:

Nach der Installation wurden lediglich noch eine IP Adresse und DNS Server, sowie die Zeitsynchronisation via NTP konfiguriert. Nachdem die CentOS Installation abgeschlossen ist, kann Ansible installiert werden.

Ansible Installation

Für die Ansible Installation kann PIP (python installs packages) verwendet werden. Damit dies funktioniert, muss zunächst Python installiert werden. Die Installation von Python kann mit den folgenden Befehlen durchgeführt werden:

Nach Python kann Ansible mit dem folgenden Befehl installiert werden:

Die Installation habe ich übrigens bewusst via PIP durchgeführt, bei der Installation von Ansible über das normale CentOS Repo, habe ich es nicht geschafft alle Komponenten erfolgreich lauffähig zu bekommen. Wenn die Installation mittels PIP erfolgte, gab es bei mir keine Probleme.

Ansible ist jetzt bereits installiert, damit später auch Windows Server mittels WinRM verwaltet werden können, ist noch das Paket PyWinRM erforderlich. Das Paket kann mit dem folgenden Befehl installiert werden:

Nachdem Ansible installiert wurde, kann es mit der Grundkonfiguration weiter gehen.

Ansible Grundkonfiguration

Da die Installation von Ansible mittels PIP durchgeführt wurde, fehlen noch zwei grundlegende Dateien für die Konfiguration von Ansible. Die erforderlichen Dateien können aber einfach runtergeladen und im entsprechenden Verzeichnis angelegt werden. Ansible lädt diese Dateien dann zur Laufzeit.

Um das Verzeichnis anzulegen und die Konfigurationsdateien runterzuladen können die folgenden Befehle verwendet werden:

Die Datei ansible.cfg muss zunächst nicht angepasst werden. In der Datei “hosts” werden später die zu verwaltenden Server angegeben.

Ansible Authentifizierung mittels Kerberos

Die Verwaltung von Windows Servern mit Ansible würde jetzt bereits mittels WinRM funktionieren, allerdings aktuell nur mit einem lokalen Benutzer auf dem jeweiligen Server. Die Verwendung von Active Directory Benutzerkonten und die Authentifizierung mittels Kerberos ist hier allerdings der elegantere Weg, zumal auch die Verwaltung einiger Dienste auf Windows Servern nur mit Active Directory Benutzern funktionieren (die Automatisierung von Exchange Servern wäre hier ein Beispiel).

Damit die Anmeldung von Ansible an Windows Servern mittels AD Benutzer und Kerberos funktioniert, müssen noch einmal ein paar Pakete nachinstalliert werden.

In der Datei /etc/krb5.conf muss nun die Verbindung zum Active Directory konfiguriert werden. In der Datei werden dazu in der Sektion “realms” die Domain Controller und in der Sektion “domain_realm” der Name des Active Directory.

In meiner Testumgebung sieht dies beispielsweise wie folgt aus (Groß/Kleinschreibung beachten):

Mit dem folgenden Befehl lässt sich nun testen, ob die Authentifizierung mittels Kerberos funktioniert:

Wenn der Befehl keine Fehlermeldung liefert, ist alles in Ordnung. Mit dem Befehl “klist” kann zusätzlich geprüft werden, ob ein Kerberos Ticket ausgestellt wurde:

Zum Schluss muss nun noch die Kerberos Unterstützung für PyWinRM installiert werden:

Ansible kann nun auch Active Directory Benutzer und Kerberos für die Authentifizierung am Windows Server verwenden.

Gruppen und Hosts erstellen

Server die via Ansible verwaltet werden sollen, müssen in der Datei /etc/ansible/hosts bekannt gemacht werden. Einzelne Server können innerhalb der Datei zu Hostgruppen zusammengefasst werden. Hier mal ein Beispiel meiner /etc/ansible/hosts Datei:

In der Datei findet sich beispielsweise die Gruppe “exchangeserver”. Die Server ex1 und ex2 sind Mitglied der Gruppe exchangeserver (erster Kasten im Screenshot). Im zweiten Kasten finden Sie die Umgebungsvariablen für die Gruppe, der Einfachheit halber habe ich hier auch die Anmeldeinformationen hinterlegt. Des weiteren gibt es noch die Gruppe “windowsserver”, diese Gruppe enthält alle Hostgruppen mit Windows Systemen:

Die relevanten Dateien habe ich am Ende des Artikels als Download zusammengefasst. Falls jemand dies also nachbauen möchte, muss hier nicht alles abgetippt werden.

Windows Systeme konfigurieren

Damit Ansible per WinRM auf die Windows Server zugreifen kann, muss WinRM entsprechend konfiguriert werden. Die Konfiguration von WinRM ist dank eines PowerShell Scripts sehr einfach möglich. Das Script kann hier runtergeladen werden:

• ConfigureRemotingForAnsible.ps1

Das Script muss als Administrator auf jedem Windows Server ausgeführt werden, der mittels Ansible verwaltet werden soll.

Das Script erstellt ein selbst signiertes Zertifikat und konfiguriert WinRM entsprechend. Die Verbindung vom Ansible Server zum Windows Server erfolgt über den Port 5986, die Windows Firewall wird automatisch konfiguriert, falls weitere Firewalls zum Einsatz kommen, müssen diese die Kommunikation via Port 5986 zulassen.

Verbindung testen

Die Vorbereitungen sind nun soweit abgeschlossen und es kann getestet werden, ob Ansible eine Verbindung zu den konfigurierten Windows Servern herstellen kann. Für den Test der Verbindung kann der folgende Befehl verwendet werden:

Dieser Befehl führt das Module win_ping (WinRM basierter Test) zu den Mitgliedern einer Gruppe aus:

Im Screenshot ist zu sehen, wie die einzelnen Gruppen getestet werden können. Falls es hier zu Problemen kommt, dann mal als ersten prüfen, ob die Server via DNS aufgelöst werden und die Anmeldeinformationen korrekt sind. Ist die Verbindung erfolgreich, kann man sein erstes Playbook erstellen.

Playbook für Windows Updates erstellen

Playbooks dienen dazu eine Abfolge von Aktionen auf den Zielsystemen auszuführen. In diesem Abschnitt wird ein einfaches Playbook für die Installation von Windows Updates erstellt. Dieses Playbook dient erst einmal nur als Beispiel, wer sich ein wenig in Ansible einarbeitet, kann hier aber schnell komplexere Sachen umsetzen.

Zunächst kann eine Verzeichnisstruktur für die Playbooks erzeugt werden, so lassen sich die Playbooks später einfacher wiederfinden. In diesem Beispiel wird das Verzeichnis “ansible-playbooks” und das Unterverzeichnis “windows” angelegt. Im Ordner “windows” können dann alle Playbooks für Windows Systeme gespeichert werden. Die Verzeichnis Struktur ist hier natürlich frei wählbar:

Jetzt kann das erste Playbook im Ordner “windows” angelegt werden. Mit dem Playbook werden in diesem Beispiel die Windows Updates auf den Windows Servern installiert:

Das erste Playbook bekommt den folgenden Inhalt:

Der erste Step installiert Windows Updates auf Servern der Gruppe “fileserver” (hosts: fileserver). Wenn es mehrere Hosts in der Gruppe Fileserver gibt, werden die Updates parallel auf den Servern installiert (strategy: free). Der Task definiert welche Aktion durchgeführt werden soll. In diesem Fall werden kritische und Sicherheitsupdates installiert und die Server bei Bedarf neu gestartet. Im nächsten Step sind dann die Domaincontroller dran, danach die Hosts der Gruppe “exchangeserver”.

Dieses einfache Playbook ist nur ein kleines Beispiel. Wenn man sich hier ein bisschen einarbeitet, lässt sich mittels Ansible vieles automatisieren. Auch dieses Beispiel findet sich am Ende des Artikels als Download.

Ich hab mir beispielsweise den Updatevorgang für meine private Umgebung automatisiert, dies läuft dann wie folgt ab:

1. VMware Snapshots für alle virtuellen Server erzeugen, welche Updates erfordern
2. Updates auf Windows und Linux Servern installieren
3. Neustart der Server durchführen, wenn dies erforderlich ist
4. E-Mail Benachrichtigung versenden
5. 2 Tage später Snapshot löschen

Im Download am Ende des Artikels findet sich auch ein Beispiel, wie eine Exchange DAG aktualisiert werden kann.

Playbook ausführen

Zuvor angelegte Playbooks lassen sich mit dem Befehl “ansible-playbook” ausführen. In diesem Beispiel wird das zuvor angelegte Playbook ausgeführt:

Ansible führt nun die Schritte aus dem Playbook auf den Servern aus:

Wie man im Screenshot oben sehen kann, reicht nun ein Befehl aus, um alle Windows Server in der entsprechenden Reihenfolge mit Updates zu versorgen. Innerhalb des Playbooks lassen sich auch mehrere verschiedene Systeme ansprechen. Beispielsweise kann hier zuerst ein Exchange Server aus dem Loadbalancer Pool genommen und erst dann aktualisiert werden, oder es könnte vorher noch ein Snapshot erzeugt werden, oder oder oder…

Download

Wie versprochen findet sich hier der Download mit den entsprechenden Beispielen:

Die enthaltenen Dateien dienen nur als Beispiel und müssen an die eigene Umgebung angepasst werden. Vielleicht erleichtern die Beispiele ja dem ein oder anderen den Einstieg in Ansible.

Fazit

Nach ein bisschen Einarbeitungszeit und vielen Tests, gewöhnt man sich recht schnell an Ansible. Gerade die Möglichkeit nahezu alle Systeme zu automatisieren, bietet enormes Potenzial. Es lassen sich ja schließlich nicht Aktionen auf Windows- und Linux Servern ausführen, sondern auch nahezu jedes andere Gerät im Netzwerk steuern (Switches, Router, Firewalls, Loadbalaner, Hypervisor, “das Blech”, Klimaanlagen, Zutrittskontrolle, Datenbanken usw. usw. usw.) und beim eigenen Netzwerk ist ja noch nicht Schluss, auch die Schnittstellen von Azure, AWS und GCP lassen sich ansteuern. Die Möglichkeiten sind also ziemlich vielseitig…

Tipp: Es gibt auch ein grafisches Frontend für Ansible:

• AWX Project