Ein Problem weniger: Windows Server Patching mit Ansible vollautomatisch

Patchen Sie noch von Hand?
Patchen Sie Ihre virtuellen Windows Server immer noch manuell? Mit einer vollständigen Automatisierung sparen Sie Zeit und Aufwand und erhöhen gleichzeitig die Sicherheit. Vollautomatisches Server Patching mit Ansible …
Einen Mojito am Strand trinken, während die Systeme gepatcht werden. Wenn alles erledigt ist, kommt eine Benachrichtigung.
opensight.ch – roman hüsler

Vollautomatisches Server Patching mit Ansible

• «Gibt es neue Security Updates für meine Server-VMs?»
• «Ist das Backup letzte Nacht erfolgreich gelaufen?»
• «Hat die VM bestehende Snapshots?»
• «Hat die VM genug freien Speicherplatz?»
• «Kann ich die VMs abends um 21:00 Uhr patchen?»

Die Antworten auf diese Fragen kann man entweder von Hand auf der eigenen Infrastruktur zusammensuchen oder den ganzen Ablauf von A bis Z mit Ansible automatisieren. Zum Patching gehören oft Prüfungen und Vorkehrungen auf allen Umsystemen (Backup, Hypervisor-Snapshots, Monitoring). In diesem Beitrag zeigen wir, wie das Open-Source-Tool «Ansible» bei der Automatisierung hilft.

Bevor es losgeht: Alle hier erwähnten Playbooks und Module finden Sie auch im zugehörigen Open-Source-Repository auf GitHub.
opensight.ch – roman hüsler

Über Ansible

Ansible ist ein Open-Source-Automatisierungstool, das Funktionen wie Softwareverteilung, Ad-hoc-Ausführung von Befehlen und Konfigurationsmanagement vereint.

Ansible beschreibt den gewünschten Zustand von Systemen in Dateien im YAML-Format (Playbooks). Der Ansible-«Master-Server» verbindet sich dann per SSH (bei Windows per WinRM) mit den «Slave-Servern», um die nötigen Konfigurationen vorzunehmen. Es gibt zahlreiche fertige «Ansible-Module», mit denen sich alle möglichen Systemkonfigurationen umsetzen lassen. Natürlich kann man auch eigene Module entwickeln, und genau solche nutzen wir für die Prüfungen auf Umsystemen wie den Hyper-V-Hosts.

GitOps / Infrastructure as Code
Kombiniert man Ansible (bzw. seine YAML-Dateien) mit den Funktionen von Git, lässt sich die Konfiguration der Infrastruktur versionieren. Stichworte: «Infrastructure as Code (IaC)», «GitOps».
opensight.ch – roman hüsler

Web-GUI: AWX installieren

Ansible gehört heute zu den etabliertesten Open-Source-Tools für Orchestrierung. Es basiert auf Python und wird über die Kommandozeile bedient. Es gibt aber auch grafische Oberflächen, die die Bedienung erleichtern, einen besseren Überblick bieten und Scheduling-Funktionen mitbringen. Die bekannteste ist Red Hats «Ansible Tower». Wir verwenden hier allerdings dessen Open-Source-Variante: «Ansible AWX».

Für AWX haben wir einen bestehenden Kubernetes-Cluster genutzt, es gibt aber natürlich auch andere Möglichkeiten. Für das Deployment von AWX Version 20 auf Kubernetes empfiehlt sich der «AWX Operator». Er legt auf dem Kubernetes-Cluster eine Custom Resource Definition (CRD) «AWX» an, die das AWX-Deployment verwaltet. Als Datenbank dient PostgreSQL. Auf die Installation können wir hier nicht im Detail eingehen, die Dokumentation finden Sie hier.

Windows Slaves konfigurieren

Dieser Beitrag konzentriert sich auf das Patchen von Windows-Server-Systemen mit Ansible. Linux-Systeme lassen sich aber auf die gleiche Weise patchen (mit kleinen Unterschieden).
opensight.ch – roman hüsler

Sie patchen stattdessen Linux? Das vollständige Playbook für Ubuntu und RHEL, mit Rolling Batches und Reboots nur bei Bedarf, finden Sie in How to Patch Linux Servers Using Ansible (auf Englisch).

Damit Ansible auf eine zu patchende Windows-Server-VM zugreifen kann, braucht der Windows Server mindestens PowerShell 3.0 und .NET Framework 4.0. Danach muss der WinRM-Dienst für Ansible konfiguriert werden. Er sollte auf den Zielsystemen so eingerichtet sein, dass die Kommunikation sicher und verschlüsselt abläuft. Dazu empfehlen wir unseren Beitrag «WinRM – Remoteverwaltung von Windows Servern» (auf Englisch).

Ansible Playbooks erstellen

Bereiten wir nun einige Playbooks vor, die uns zu unserem Ziel bringen: vollautomatisches Server Patching mit Ansible. Im Git-Repository liegen einige Playbooks, die beim Patchen von Windows Servern nützlich sind:

• Playbook: Windows Updates prüfen
  Sucht auf den Clients nach verfügbaren Windows Updates
• Playbook: Speicherplatz prüfen
  Prüft, ob auf Laufwerk C: mindestens 20 GB frei sind
• Playbook: VM-Snapshots prüfen
  Prüft, ob die VM auf dem Virtualisierungsserver aktive Snapshots hat

In jedem Playbook ist eine Abfolge von «Tasks» definiert, die nacheinander auf den definierten Systemen ausgeführt werden. Schlägt einer dieser Tasks fehl, wird die Ausführung abgebrochen.

Playbook: Windows Updates prüfen

Jetzt testen wir das System. Dafür verwenden wir ein Playbook (check-updates.yml), das die verfügbaren Updates auf allen Windows Servern auflistet.

---

- name: windows server patching
  hosts: all
  tasks:

    - name: Check for missing updates
      win_updates:
        state: searched
      register: update_results

    - name: report update results
      debug:
        msg: |
          {% for k in update_results.updates %}
          {{ k.title }}
          {% endfor %}

Wir binden das Playbook als «Job Template» in Ansible AWX ein. Nach der Ausführung sehen wir (Bild, grüne Zeilen), dass ein Windows-System ausstehende Updates hat.

Playbook: Speicherplatz prüfen

Auf die gleiche Weise definieren wir ein weiteres Job Template, das den freien Speicherplatz auf Laufwerk C: prüft. Sind weniger als 20 GB frei, gilt der Test als fehlgeschlagen.

---

- name: check free disk space
  hosts: all
  tasks:
    - name: 'Check free space in C:'
      win_shell: 'write-host ([math]::Round((Get-PSDrive C | Select-Object Free).free / 1024 / 1024 / 1024,2))'
      register: freespace

    - name: report free disk space
      debug:
        msg: |
          "{{ freespace.stdout }} GB"

    - name: fail if there is not enough space
      fail:
        msg: "VM {{inventory_hostname}} has not enough space"
      when: "{{freespace.stdout | int < 20}}"

Playbook: VM-Snapshots prüfen

In unserem Fall soll das Patching nur starten, wenn die virtuellen Maschinen keine aktiven Snapshots haben (nur als Beispiel dafür, was möglich ist).

Im Git-Repository liegt ein eigenes Modul für Ansible, das prüft, ob eine Hyper-V-VM gerade einen Snapshot hat. Testen wir es:

• Wir erstellen einen Snapshot der VM bnetprtg01
• Im Ansible-Inventory ergänzen wir beim Host bnetprtg01 die Variable «hyperv_vmname=bnetprtg01», die das Modul / Playbook braucht (siehe Dokumentation)
• Wir ergänzen im Ansible-Inventory die nötige Variable «module_hyperv_host: 192.168.1.2», die auf den Hyper-V-Host zeigt (siehe Dokumentation)
• Dann führen wir das Playbook aus dem Git-Repository aus (hyperv-check-nospanshot.yml)

Wie erhofft schlägt das Playbook für die VM bnetprtg01 fehl, weil sie einen aktiven Snapshot hat. Mit einer kleinen Anpassung könnte dasselbe Playbook natürlich auch vor dem Patching einen Snapshot erstellen und ihn danach wieder löschen.

Werfen Sie einen Blick ins Git-Repository: Es enthält auch Playbooks, die den Monitoring-Status eines Systems in PRTG prüfen und das Monitoring pausieren oder fortsetzen.
opensight.ch – roman hüsler

Weitere Playbooks beschreiben wir an dieser Stelle nicht. Natürlich lassen sich die Snapshots aber analog auch auf einer VMware-basierten Infrastruktur prüfen oder ändern. Oder man prüft das Backup auf einem Veeam-Server usw.

Grande Finale: der vollautomatische Patching-Prozess

Mit einem «Workflow Job Template» verknüpfen wir nun alle zuvor definierten Playbooks («Job Templates») in Ansible AWX zu einem vollständig automatisierten Ablauf:

• Speicherplatz prüfen
• Snapshots prüfen
• Nach Updates suchen
• Updates installieren und neu starten

Wir definieren einen Job Schedule, damit das vollautomatische Windows Server Patching einmal im Monat um 02:00 Uhr nachts läuft. In einem echten Patching-Szenario stimmt man den Zeitpunkt am besten auf den «Microsoft Patch Tuesday» ab.

Reporting und Benachrichtigungen

Für das Reporting kann man zum Beispiel eine E-Mail-Benachrichtigung einrichten.
Das Format der E-Mail lässt sich in gewissen Grenzen anpassen. Es gibt aber natürlich auch weitergehende Möglichkeiten. So könnte man alle Logs mit Logstash in einen Elasticsearch-Cluster streamen. Das schauen wir uns vielleicht in einem späteren Beitrag an.

Fazit

Ansible ist zu Recht in die Oberliga der beliebtesten Orchestrierungs- und Automatisierungstools aufgestiegen. Die Bedienung ist intuitiv, und natürlich lassen sich damit auch ganz andere Abläufe automatisieren als «vollautomatisches Server Patching mit Ansible».