Ansible auf Windows installieren

Die Maschine, die man für die Aufgaben des Configuration Management verwendet, wird als Steuerknoten ("Control Node") bezeichnet. Diese Maschine muss Linux ausführen (WSL auf Windows ist ebenfalls möglich) und Python installiert haben.

Die verwalteten Knoten ("Managed Nodes") werden in einer einfachen INI- oder YAML-Datei ("Inventory") erfasst. Ich empfehle die Verwendung von Visual Studio Code für die Entwicklung mit Ansible, da es dafür gut geeignet ist und sich einfach mit WSL integrieren lässt.

Kommunikation über WinRM

Die Netzwerk­kommunikation zwischen dem Steuer- und den verwalteten Knoten erfolgt entweder über Secure Shell (SSH) oder Windows Remote Management (WinRM). Man muss sich also keine Gedanken über das Öffnen von nicht-standardmäßigen Ports in der Netzwerk­infrastruktur machen.

Man kann Ansible über die Befehlszeile (CLI) interaktiv administrieren, aber die wahre Stärke der Software zeigt sich, wenn man die Aufgaben für das Configuration Management in YAML-Playbooks zusammenfasst. Man kann sogar mehrere Playbooks zu Ansible-Rollen aggregieren und mit der Community auf Ansible Galaxy teilen.

Zentrale Koordination über Automation Platform

Grundsätzlich kann man das gesamte Configuration Management von einer Workstation aus steuern. Aber es gibt eine zentrale "Befehls- und Kontrollstelle" für Ansible namens Red Hat Ansible Automation Platform (früher als Ansible Tower bekannt).

Sie ist ein kostenpflichtiges Produkt, das Admins eine zentrale REST-API und ein Web-Portal bietet, von denen aus sie ihre Knoten steuern können.

Aufbau der Lab-Umgebung

Die folgende Abbildung zeigt mein einfaches Windows-Lab für diese Anleitung. Sie besteht aus zwei Hosts mit Windows Server 2022. dc1 ist mein Domänencontroller, der auch als Ansible-Steuerknoten fungiert; mem1 ist ein Member Server und dient als verwalteter Knoten.

Die Kommunikation zwischen Client und Server erfolgt entweder über TCP 5985 (HTTP) oder TCP 5986 (HTTPS) mittels WinRM PowerShell Remoting.

Der Steuerknoten verfügt über Python 3 und Ansible, die ich im Windows Subsystem für Linux (WSL) installiert habe. Während verwaltete Linux-Knoten Python benötigen, muss auf Windows-Endpunkten lediglich WinRM PowerShell Remoting aktiviert sein.

Steuerknoten einrichten

Wie bereits erwähnt, läuft der Ansible-Server nur unter Linux. Daher muss man auf dem Windows Server, der als Kontrollknoten dienen soll, WSL2 einrichten. WSL2 mit Ubuntu lässt sich über diesen Befehl installieren:

wsl --install

Ansible installieren

In einem WSL-Terminal führen Sie die folgenden Befehle aus, um Ansible zu installieren. Die Ansible-Dokumentation beschreibt diese ebenfalls.

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install ansible -y

Man kann die erfolgreiche Installation von Ansible durch diesen Befehl verifizieren:

ansible –-version

Konfigurationsdatei bearbeiten

Ansible speichert alle Einstellungen in einer Textdatei im INI-Format unter /etc/ansible/ansible.cfg. Öffnen Sie die Konfigurationsdatei mit dem Texteditor nano:

sudo nano /etc/ansible/ansible.cfg

Fügen Sie den folgenden Block am Anfang der Datei ein:

[defaults]
Inventory=/etc/ansible/hosts

Inventory-Datei erstellen

Wir müssen nun dc1 und mem1 zu unserem Ansible-Inventar hinzufügen, damit wir diese Maschinen für Verwaltungsaufgaben heranziehen können. Diese Befehle erstellen die Datei und öffnen sie in nano:

sudo touch /etc/ansible/hosts

sudo nano /etc/ansible/hosts

Fügen Sie folgenden Text in die Datei ein:

[control] dc1 ansible_host=10.0.2.15 [infra] mem1 ansible_host=10.0.2.16 [infra:vars] ansible_user=administrator ansible_password=P@$$w0rd143! ansible_port=5986 ansible_connection=winrm ansible_winrm_transport=basic ansible_winrm_server_cert_validation=ignore

Hier die Erklärung für die obigen Einträge in die hosts-Datei :

• [control], [infra]: Dabei handelt es sich um Gruppen von Hosts. Wir fügen unseren Steuerknoten zu einer Gruppe namens control hinzu und unseren verwalteten Knoten in die Gruppe infra.
• ansible_host: Diese vordefinierte Variable informiert Ansible über den DNS-Namen oder die IP-Adresse, die es verwenden soll, um mit diesem Knoten zu kommunizieren. Sie ist optional, bietet aber eine gute Möglichkeit, um einen kurzen Alias zu definieren.
• [infra:vars]: Hier definieren wir Variablen, die Ansible anweisen, WinRM als Transport und den integrierten lokalen Administrator als Konto für den Aufbau der Verbindung zu nutzen. Natürlich sollten Sie niemals Passwörter als Klartext in einer Datei speichern. Ansible kann die Dateien mit Ansible Vault verschlüsseln.

PowerShell Remoting aktivieren

Für Ansible existiert ein PowerShell-Script, das die Konfiguration des WinRM-Listeners vereinfacht. Man führt es sowohl am Steuerknoten als auch am Management-Node aus.

Verbindung testen

Von nun an arbeiten wir vom WSL-Prompt des Steuerknotens aus.

Wenn man Ansible installiert, dann erhält man eine Bibliothek mit integrierten Modulen, die jeweils ein bestimmtes Produkt oder eine bestimmte Technologie abdecken. Die Ansible-Module für Windows haben alle das Präfix win_. Der folgende Befehl zeigt alle verfügbaren Module an:

ansible-doc -l | grep 'win'

Zu den am meisten genutzten Modulen für Windows gehören:

• win_domain_controller: Konfiguriert einen Windows Server als Domain Controller oder konvertiert einen solchen zu einem Member Server
• win_file: Dateien und Ordner erstellen oder löschen
• win_ping: Netzwerkverbindung testen
• win_regedit: Schlüssel und Werte in der Registry hinzufügen, ändern oder löschen
• win_setup: Sammelt Informationen zum Ziel-Host
• win_shell: Führt Shell- oder PowerShell-Kommandos am Zielrechner aus
• win_whoami: Liefert Informationen über den aktuellen Benutzer

Der folgende Befehl testet die Konnektivität zwischen dem Ansible-Steuerknoten und den verwalteten Rechnern. In diesem Beispiel beziehen wir uns auf die infra-Gruppe des Inventars. Das Schlüsselwort all würde die Prüfung aller Knoten im Inventar bewirken.

ansible infra -m win_ping

Ansible Facts bezeichnet die Metadaten der Knoten. Sie lassen sich mit dem integrierten Modul win_whoami aufrufen:

ansible infra -m win_whoami

Playbook ausführen

Ansible CLI-Befehle ad hoc auszuführen ist praktisch, um einzelne Aktionen anzustoßen. Aber das Configuration Management besteht meistens aus komplexeren Abläufen, die sich mit Playbooks abbilden lassen.

Im folgenden Beispiel erstelle ich eine neue Datei namens apache.yaml, um den Apache-Webserver zu installieren:

--- - name: Installing Apache MSI hosts: win tasks: - name: Download the Apache installer win_get_url: url: https://archive.apache.org/dist/httpd/binaries/win32/httpd-2.2.25-win32-x86-no_ssl.msi dest: C:\httpd-2.2.25-win32-x86-no_ssl.msi - name: Install MSI win_package: path: C:\ansible_examples\httpd-2.2.25-win32-x86-no_ssl.msi state: present

YAML unterscheidet nicht nur Groß- und Kleinschreibung, sondern ist auch sehr pingelig, was die Einrückung angeht.

Hier nun einige kurze Erklärungen zur Struktur von Ansible Playbooks:

• hosts: Hier geben Sie Inventargruppen, bestimmte Hosts oder die Schlüsselwörter wie all oder ungrouped für die Ziel-Hosts an.
• tasks: Jeder Abschnitt in einem Playbook besteht aus einer oder mehreren Tasks, welche die atomaren Arbeitseinheiten darstellen
• win_get_url, win_package: Integrierte Module, die den Apache Web-Server herunterladen und installieren

Das Playbook führt man dann mit diesem Befehl aus:

ansible-playbook iis.yaml

Ansible-Playbooks sind idempotent, d. h., man kann sie immer wieder ausführen und nur die Änderungen, die Sie an der Datei vornehmen, werden auf die Zielknoten angewandt.

Mit dem integrierten Modul win_stat lässt sich schließlich überprüfen, ob das Apache-Verzeichnis auf dem Zielknoten vorhanden ist:

ansible infra -m win_stat -a "path='C:\Program Files (x86)\Apache Software Foundation\Apache2.2'"

Das stat: dictionary sollte das Schlüssel/Wert-Paar "exists": true für das Apache-Verzeichnis enthalten.