Lokales Provisioning

Verwenden Sie sailwright provision local, wenn Sailwright das konfigurierte Standard-Playbook auf der aktuellen Maschine ausführen soll – anstelle einer verwalteten VM oder eines Remote-Hosts.

Definieren Sie diesen Standard für die tägliche Maschineneinrichtung in ansible-role-sources.yml. Ohne konfigurierten Standard verwendet Sailwright als Fallback das mitgelieferte ./playbooks/role-sources-test.yml – ein schnelles Beispiel-Playbook für Rollenquellen (Smoke Test). Um das umfangreichere mitgelieferte Beispiel-Setup direkt auszuführen, übergeben Sie --playbook ./playbooks/setup.yml.

Beginnen Sie mit der README im Root-Verzeichnis für Installation und Übersicht, und nutzen Sie anschließend diese Anleitung für das Wrapper-spezifische Verhalten und die Flags.

Kurzbeispiele

sailwright provision local --check
sailwright provision local --proto ssh --check
sailwright provision local --playbook ./playbooks/setup.yml --check
sailwright provision local --playbook ./playbooks/setup.yml
sailwright provision local -- --diff --tags java
sailwright provision local --inventory-path ./inventory/remote.yml -- --limit workstation --ask-become-pass
sailwright provision local --check --yes
sailwright provision local --check --yes --force-winrm-uninstall
sailwright provision local --proto ssh --check --yes --force-ssh-uninstall
sailwright provision local

Was der Wrapper macht

• Wählt ein Standard-Inventory für localhost passend zum Betriebssystem des aktuellen Hosts aus.
• Ermittelt das Playbook aus --playbook, ansible-role-sources.yml oder dem mitgelieferten Rollenquellen-Smoke-Fallback.
• Reicht zusätzliche ansible-playbook-Flags durch, wenn Sie diese nach -- platzieren.

Verwenden Sie --playbook, um auf eine andere Playbook-Datei zu verweisen. Verwenden Sie --inventory-path, um die lokale Standard-Inventory-Datei zu überschreiben.

Plattform-Standards

• macOS und Linux verwenden inventory/localhost.yaml.
• Windows verwendet standardmäßig inventory/localhost_windows_winrm.yml.
• Unter Windows wechselt --proto ssh zu inventory/localhost_windows_ssh.yml.

Das lokale Ziel für macOS/Linux ist derzeit als instabil markiert, bis es durchgängig validiert wurde.

Lokales Verhalten unter Windows

Der Windows-Wrapper nimmt temporäre Änderungen am Host vor, damit Ansible die lokale Maschine während des Laufs sicher erreichen kann.

Im standardmäßigen WinRM-Modus führt der Wrapper Folgendes aus:

• Erstellt ein temporäres Administratorkonto mit einem zufälligen Passwort.
• Erstellt für den Lauf einen temporären, nur auf Loopback beschränkten WinRM-HTTPS-Listener.
• Stellt beim Cleanup den vorherigen WinRM-Zustand wieder her.

Mit --proto ssh führt der Wrapper Folgendes aus:

• Erstellt oder aktualisiert ein temporäres Administratorkonto mit einem temporären SSH-Schlüssel.
• Aktiviert oder installiert bei Bedarf den OpenSSH-Server.
• Setzt für den Lauf die Standard-SSH-Shell auf PowerShell.
• Stellt anschließend den vorherigen Zustand von SSH-Dienst, Firewall, authorized_keys und Shell wieder her.

Musste der Wrapper den OpenSSH-Server installieren, deaktiviert das Cleanup sshd, belässt die OpenSSH-Server-Funktion (Capability) jedoch installiert, damit das Cleanup keinen Neustart erfordert.

Existiert das Konto devalchemy_ansible bereits, verwendet der SSH-Wrapper es als Automatisierungskonto weiter und rotiert dessen Passwort für den Lauf. Das Cleanup stellt das vorherige Passwort nicht wieder her – behandeln Sie dieses Konto daher als automatisiert verwaltet und nicht als manuell verwalteten Login.

Da es sich um erhebliche Änderungen am Host handelt, fragt der lokale Windows-Ablauf standardmäßig nach Bestätigung. Verwenden Sie --yes, um diese CLI-Bestätigungsabfragen zu überspringen.

Unter Windows ist lokales Provisioning nur dann vollständig nicht-interaktiv, wenn Sie sailwright aus einer bereits erhöhten (elevated) Shell starten. Ist die aktuelle Shell nicht erhöht, lösen die privilegierten Bootstrap- und Cleanup-Schritte vor ihrer Ausführung dennoch eine UAC-Abfrage aus.

Der Wrapper streamt Bootstrap- und Cleanup-Logs in das Hauptterminal zurück.

Anleitungen zur manuellen Einrichtung des Windows-Transports und zum Rollback finden Sie unter Windows-Ansible-Zugriff.

Cleanup-Flags

--force-winrm-uninstall gilt nur für den Standard-WinRM-Modus. Es erzwingt, dass das Cleanup WinRM deaktiviert und die temporäre Remoting-Einrichtung nach dem Lauf entfernt.

--force-ssh-uninstall gilt nur für --proto ssh. Es erzwingt, dass das Cleanup sshd deaktiviert, die SSH-Firewallregeln entfernt und den temporären Ansible-Benutzer nach dem Lauf entfernt, ohne den OpenSSH-Server zu deinstallieren.

Wenn Sie eine vom Wrapper installierte OpenSSH-Server-Funktion (Capability) entfernen müssen, folgen Sie den manuellen Rollback-Schritten unter Windows-Ansible-Zugriff.