Automatisieren von Windows Server-Konfigurationen mit Ansible

Im Bereich von DevOps gibt es immer einen Drang zur Automatisierung, auch wenn dies nicht immer möglich ist, aber wir können es zumindest versuchen. Wir alle wissen, was Ansible ist: ein Konfigurationsmanagement-Tool für Automatisierung und Infrastruktur als Code. Ansible wird in der Regel mit Linux- und Unix-Systemen, Open-Source-Technologie, Python und SSH assoziiert und scheint daher in erster Linie auf das Linux-Ökosystem zugeschnitten zu sein. In der realen Welt läuft jedoch nicht alles unter Linux. Manchmal müssen Sie jedoch die Konfiguration von Windows-Maschinen automatisieren. Es gibt Fälle, in denen die Automatisierung von Windows-Serverkonfigurationen notwendig ist, und manchmal muss diese Automatisierung innerhalb einer Pipeline erfolgen, die durch einen Linux-Container ausgelöst wird.

Warum Ansible wählen? Gibt es noch andere Tools für das Konfigurationsmanagement von Windows-Servern? Wahrscheinlich, aber die Software von Red Hat ist zeitlos, idempotent und hat eine YAML-basierte Automatisierungssyntax, die schnell zu erlernen ist. Es besteht keine Notwendigkeit für eine komplexere Lösung. Es geht um die Automatisierung von Windows-Servern, nicht um Raketenwissenschaft.

Einrichten der Verbindung mit Windows Server

Wenn Sie bereits Erfahrung mit Ansible haben oder unseren Leitfaden für Einsteiger gelesen haben, werden Sie wissen, dass die Verbindung zwischen dem Ansible-Controller und den Hosts über SSH hergestellt wird. Wenn wir jedoch mit Windows-Servern arbeiten, sollten wir etwas namens WINRM verwenden. Ja, es gibt OpenSSH für Windows, aber WinRM ist auf jedem Windows-Server vorinstalliert. 

Außerdem müssen wir für diese Automatisierung PowerShell und Module für Windows verwenden, aber zuerst müssen wir einen Linux-Controller mit Windows Server 2019 verbinden.

Windows Server 2019 einrichten:

1. Zuerst müssen wir sicherstellen, dass WinRm auf dem Server läuft:

PS C:\Users\itgix\Downloads> winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.

Wenn es nicht läuft, können Sie es jederzeit mit aktivieren:

PS C:\Users\itgix\Downloads> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-RemoteManagement-Client

2. Als nächstes können wir sehen, ob es irgendwelche Listener gibt, die für den Server konfiguriert sind:

PS C:\Users\itgix\Downloads> winrm enumerate winrm/config/Listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.240.1.100, 127.0.0.1, ::1, fe80::9745:976c:b3e1:74bc%2

Dies sollte die Standardkonfiguration des Listeners sein. Sie können jederzeit einen neuen Listener einrichten. Es gibt auch etwas, auf das wir hinweisen sollten. Sie können im Beispiel sehen, dass der Listener auf Port 5985 konfiguriert ist, dies ist kein sicherer Port (es wird kein SSL-Zertifikat verwendet). Der sichere WinRM-Port ist 5986, aber Sie müssen ein SSL-Zertifikat haben und einrichten, um diese Art von Verbindung herzustellen. 

Wenn Sie ein Zertifikat haben, können Sie es mit dieser Anleitung von Microsoft konfigurieren. Allerdings liegt unser Schwerpunkt in diesem Fall nicht auf der Sicherheit, aber wir empfehlen dringend Vorsicht, wenn kein SSL verwendet wird.

3. Wir brauchen einen dedizierten Windows-Benutzer, der die Aufgaben ausführt. In Ansible haben wir immer einen Benutzer, der die Aufgaben ausführt, die der Controller sendet. In diesem Windows-Fall sollte der Benutzer Administrator sein. Jeder Admin-Benutzer kann verwendet werden, aber normalerweise, wenn wir Ansible verwenden, verwenden wir einen dedizierten Benutzer. Das ist einfach die beste Praxis.

4. Chocolatey installieren

Dies wird benötigt, damit das Ansible-Modul den Chocolatey-Paketmanager zum Herunterladen von Material verwenden kann:

Set-ExecutionPolicy Bypass -Scope Process -Force; `
  iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Linux einrichten:

Da am Ende alles benutzerfreundlich sein soll, wird das Ansible-Playbook von einer GitLab-Pipeline ausgeführt, d. h. es wird auf einem GitLab-Runner ausgeführt. Der von uns verwendete läuft auf einem Linux-Container, genauer gesagt auf Alpine Container.

1. Überprüfen Sie zunächst die Windows Server-Verbindung.

Da Linux eine Verbindung zu einer anderen virtuellen Maschine herstellen soll, müssen wir zunächst sicherstellen, dass sie eine Verbindung zueinander herstellen können (Überprüfung der Portverfügbarkeit).

Unser Windows Server befindet sich in der Azure Cloud, daher müssen wir eine Regel für den eingehenden Port erstellen, um auf Port 5985 / oder 5986 zuzugreifen.

Wenn es sich um eine andere Cloud handelt, ist das Konzept dasselbe: AWS - Sicherheitsgruppe - eingehende Regel, GCP-Firewall-Regel usw. 

Wenn Sie eine virtuelle Maschine auf Ihrem eigenen Server oder lokalen Hypervisor verwenden, sollten Sie eine Firewall-Regel erstellen, um genau diesen Port zu öffnen.

Danach können wir die Verfügbarkeit des Hafens über den Alpencontainer prüfen:

# apk add net-tools
# telnet /WINDOWS IP/ 5985
Connected to /WINDOWS IP/

2. Installieren Sie die benötigten Abhängigkeiten:

# apk add python3 py3-pip gcc libffi-dev ansible
# pip3 install "pywinrm>=0.3.0"

3. Einrichten der Bestandsdatei

Für das Projekt müssen wir nun die Ansible-Inventarisierungsdatei (Host) und die erforderlichen Variablen für die Verbindung (Port, Benutzer, Passwort) einrichten:

[win]
{ip addresses for the windows vms (one per row)}
[win:vars]
ansible_port=5985
ansible_user={Windows Admin User}
ansible_password={Password}
ansible_connection=winrm
ansible_winrm_server_cert_validation=ignore

Gastgeber prüfen:

 # ansible -i hosts  all --list-hosts
  hosts (2):
    windows1
    windows2

Ansible Playbook erstellen

Jetzt ist es an der Zeit, den Konfigurationsteil des Aufbaus einer Ansible-Pipeline durchzuführen. Etwas Einfaches kann wie folgt aussehen:

---
- name: Set Up Automation of Windows Server 2019
  hosts: win
  tasks:
    # installing dependencies and packages
    - name: Install C#
      win_chocolatey:
        name: "{{ item }}"
        state: present
      loop:
        - dotnet
    
    - name: Install Firefox using Chocolatey
      win_chocolatey:
        name: firefox
        state: present
    
    - name: Install Notepad++ using Chocolatey
      win_chocolatey:
        name: notepadplusplus
        version: 8.5.2
        state: present
    
    - name: Install Prometheus Windows Exporter using Chocolatey
      win_chocolatey:
        name: prometheus-windows-exporter.install
        state: present

Dieses Ansible Playbook installiert einige Pakete und Abhängigkeiten über win_chocolatey. 

Um Ansible zu testen, führen Sie also ein Playbook aus:

# ansible-playbook -i hosts main.yml
PLAY [Set Up Automation of Windows Server 2019] ********************************
TASK [Gathering Facts] *********************************************************
changed: [windows1]
TASK [Install C#] **************************************************************
changed: [windows1] => (item=dotnet)
TASK [Install Firefox using Chocolatey] ****************************************
changed: [windows1]
TASK [Install Notepad++ using Chocolatey] **************************************
changed: [windows1]
TASK [Install Prometheus Windows Exporter using Chocolatey] ********************
changed: [windows1]
PLAY RECAP ******************************
20.56.144.225              : ok=5    changed=5    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Wie Sie sehen können, werden die Abhängigkeiten erfolgreich auf dem Windows Server aus dem Alpine Container installiert. Für den Test wird nur eine Windows-VM verwendet - windows1.

GitLab-Pipeline

Ein letzter Schritt. Wir müssen eine Pipeline erstellen, über die das Playbook ausgeführt wird.

Hier ist ein Beispiel für eine Pipeline, die Sie verwenden können:

default:
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/releases/1.4
    entrypoint:
      - "/usr/bin/env"
      - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
stages:
  - windows-ansible-playbook

windows-ansible-start:
  stage: windows-ansible-playbook
  before_script:
    - export ANSIBLE_PORT=${ANSIBLE_PORT}
    - export ANSIBLE_USER=${ANSIBLE_USER}
    - export ANSIBLE_PASSWORD=${ANSIBLE_PASSWORD}
    - ansible --version
  script:
    - ansible-playbook -i hosts main.yml
  when: manual

In diesem Beispiel können Sie sehen, dass wir 3 Variablen exportieren. Dies ist für die Inventarisierungsdatei, da es nicht sicher ist, Windows-Benutzer und -Passwort direkt in die Datei zu schreiben. Die Variablen stammen aus den CICD-Umgebungsvariablen von GitLab:

Dann können wir die Pipeline starten:

Schlussfolgerung

Automatisierung ist ein Ziel für jeden DevOps Engineer. Aber das muss nicht komplex sein und alles um jeden Preis automatisiert werden. Es gibt immer die richtigen Tools für jede Situation und Infrastruktur.

Dieses Beispiel für die Konfiguration von Windows-Servern könnte mit Server-Templating-Tools wie z. B. Packer durchgeführt werden. Das hängt von der Situation und der Umgebung ab. Die Architektur ist der Schlüssel.