Lokales Provisioning

Verwenden Sie sailwright provision local, wenn Sailwright das konfigurierte Standard-Playbook auf dem aktuellen Rechner ausführen soll, statt auf einer verwalteten VM oder einem Remote-Host.

Für die tägliche Einrichtung Ihres Rechners legen Sie dieses Standard-Playbook in ansible-role-sources.yml fest. Ist keines konfiguriert, greift Sailwright auf das mitgelieferte ./playbooks/role-sources-test.yml zurück, ein kurzes Smoke-/Beispiel-Playbook für Rollenquellen. Um stattdessen das umfangreichere mitgelieferte Beispiel-Setup direkt auszuführen, übergeben Sie --playbook ./playbooks/setup.yml.

Beginnen Sie mit der README im Stammverzeichnis für Installation und Überblick. Dieser Leitfaden behandelt anschließend das Verhalten des Wrappers und seine Flags.

Kurze Beispiele

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 tut

• Er wählt ein Localhost-Inventory passend zum Betriebssystem des aktuellen Hosts.
• Er ermittelt das Playbook aus --playbook, aus ansible-role-sources.yml oder aus dem mitgelieferten Smoke-Fallback für Rollenquellen.
• Er reicht zusätzliche ansible-playbook-Flags durch, wenn Sie diese nach -- angeben.

Mit --playbook verweisen Sie auf eine andere Playbook-Datei. Mit --inventory-path überschreiben Sie die Standard-Inventory-Datei für den lokalen Host.

Plattform-Standards

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

Das lokale Ziel unter macOS/Linux ist derzeit als instabil gekennzeichnet, solange es nicht durchgängig validiert ist.

Verhalten unter Windows

Der Windows-Wrapper nimmt temporäre Änderungen am Host vor, damit Ansible den lokalen Rechner für die Dauer des Laufs sicher erreichen kann.

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

• Er legt ein temporäres Administratorkonto mit zufälligem Passwort an.
• Er richtet für den Lauf einen temporären, nur auf Loopback lauschenden WinRM-HTTPS-Listener ein.
• Bei der Bereinigung stellt er den vorherigen WinRM-Zustand wieder her.

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

• Er legt ein temporäres Administratorkonto mit einem temporären SSH-Schlüssel an oder aktualisiert es.
• Er aktiviert den OpenSSH-Server oder installiert ihn bei Bedarf.
• Er setzt PowerShell für die Dauer des Laufs als Standard-Shell für SSH.
• Anschließend stellt er den früheren Zustand von SSH-Dienst, Firewall, authorized_keys und Shell wieder her.

Musste der Wrapper den OpenSSH-Server installieren, deaktiviert die Bereinigung sshd, lässt die OpenSSH-Server-Funktion aber installiert, damit für die Bereinigung kein Neustart nötig ist.

Existiert das Konto devalchemy_ansible bereits, verwendet der SSH-Wrapper es als Automatisierungskonto weiter und ändert sein Passwort für den Lauf. Die Bereinigung stellt das vorherige Passwort nicht wieder her. Behandeln Sie dieses Konto daher als von der Automatisierung verwaltet und nicht als manuell gepflegten Login.

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

Unter Windows läuft das lokale Provisioning nur dann vollständig nicht-interaktiv, wenn Sie sailwright aus einer Shell mit bereits erhöhten Rechten starten. Hat die aktuelle Shell keine erhöhten Rechte, lösen die privilegierten Schritte für Bootstrap und Bereinigung vor ihrer Ausführung weiterhin eine UAC-Abfrage aus.

Die Logs von Bootstrap und Bereinigung erscheinen im Haupt-Terminal.

Hinweise zur manuellen Einrichtung des Windows-Transports und zum Zurücksetzen finden Sie unter Windows-Ansible-Zugriff.

Flags für die Bereinigung

--force-winrm-uninstall gilt nur für den standardmäßigen WinRM-Modus. Das Flag erzwingt, dass die Bereinigung nach dem Lauf WinRM deaktiviert und die temporäre Remoting-Konfiguration entfernt.

--force-ssh-uninstall gilt nur für --proto ssh. Das Flag erzwingt, dass die Bereinigung nach dem Lauf sshd deaktiviert, die SSH-Firewall-Regeln entfernt und den temporären Ansible-Benutzer löscht, ohne den OpenSSH-Server zu deinstallieren.

Wenn Sie eine vom Wrapper installierte OpenSSH-Server-Funktion entfernen möchten, folgen Sie den manuellen Schritten zum Zurücksetzen unter Windows-Ansible-Zugriff.