Ansible Teil 9 – Zentrale Administration von WSL2

In einem meiner vorherigen Beiträge bin ich auf die Installation und Einrichtung von WSL2 mitsamt der Installation einer Linux Distribution eingegangen. Der entsprechende Beitrag ist hier verlinkt.
Da Linux in einer WSL2 Umgebung recht autark und abgekapselt dasteht, scheint eine zentrale Administration auf dem ersten Blick nicht direkt möglich zu sein.
In dem nachfolgendem Beitrag möchte ich trotz aller Hürden klären, ob dennoch eine Möglichkeit hierfür besteht.

Voraussetzung

Dieser Beitrag setzt eine bereits aufgesetzte WSL2 Installation mitsamt darin installierter Linux-Distribution voraus. Welche Distribution das ist, spielt dabei keine Rolle. Wichtig ist jedoch, dass WSL in der Version 2 installiert ist. Die dafür erforderlichen Schritte sind in diesem Beitrag bearbeitet und vorgestellt worden.
Außerdem benötigen wir einen installierten Ansible-Server. Anleitungen dazu stehen u.a. hier (Ubuntu) und hier (CentOS) bereit.

Zentrale Administration von WSL2 …

Prinzipiell arbeitet jedes in WSL2 installierte Linux als eigenständige virtuelle Umgebung. Leider gibt es dabei gleich mehrere Herausforderungen die es zu überwinden gilt, um die jeweiligen Maschinen zu kontaktieren:

• Die IP-Adresse der Maschine variiert mit jedem Neustart
• Der Netzwerkverkehr verläuft über ein privates Netzwerk
• Der Hostname der Maschine ist gleich dem des Windows Wirtssystems

Das Automatisierungstools Ansible arbeitet mit SSH-Verbindungen. Diese sind nicht nur auf die Erreichbarkeit der Zielmaschine angewiesen, sondern auch auf den geöffneten Port auf der gegenüberliegenden Seite. Leider haben wir durch das private WSL2 Netzwerk eben nicht diese Möglichkeit, die Maschine direkt zu erreichen um uns einen dort lauschenden Dienst zunutze zu machen.
Jedoch gibt es eine einfache Möglichkeit, dem ganzen ein Schnippchen zu schlagen. Hierfür machen wir uns die WSL2 Kommandozeile zunutze.

… mit der Windows Kommandozeile

Zunächst muss der OpenSSH-Server auf der Windows Maschine installiert werden, der uns hinterher als Brücke zwischen dem Ansible-Server und der Zielmaschine dient. Hierfür navigieren wir über den Punkt Optionale Features -> Features anzeigen und suchen dort nach ssh.

Wir aktivieren das Kontrollkästchen und klicken auf Weiter und installieren.
Nun stehen uns mehrere Möglichkeiten zur Verfügung, die Authentifizierung zwischen dem Ansible-Server und der Windows Zielmaschine einzurichten. Für 2 davon stehen jeweils eigene Artikel bereit:
Über WinRM
Über SSH
Ist auch dies erledigt, erstellen wir ein Playbook:

---
- hosts: windows

  tasks:
    - name: Execute command on WSL2
      win_shell: |
                      wsl -d Ubuntu -e bash -c "cat /etc/os-release"

In diesem Beispiel würde die laufende WSL2 Instanz Ubuntu angesprochen werden. Da wir hier den Weg über den Windows Host gehen, benötigen wir weder Hostnamen noch IP-Adresse, sondern lediglich ebendiesen Instanznamen.
Alternativ ließen sich die Befehle auch über eine .PS1-Datei aufrufen:

---
- hosts: windows

  tasks:
    - name: Execute command on WSL2 as powershell script
      win_command: powershell:exe -ExecutionPolicy Bypass -File C:\path\to\powershell-file\powershell.ps1 

Nun muss das Playbook nur noch ausgeführt werden um die gewünschten Änderungen durchzuführen.

Fazit

Leider bekommen wir mit dieser Methode weder Feedback noch eine Ausgabe über die Kommandozeile. Ob das gewünschte Vorhaben also tatsächlich in die Tat umgesetzt worden ist, ist also nicht sicherzustellen. Auch ist ein OpenSSH-Server auf dem Windows Wirtssystem notwendig, um diese Schritte abzuarbeiten.
Dennoch stellt diese Methode eine schnelle und einfache Möglichkeit dar, die, sonst nicht für die Zentralisierung ausgelegten, WSL2 Instanzen von einem Punkt aus zu steuern… oder zumindest den Versuch dort Befehle auszuführen.