Funktionen

Die Funktionen von Sailwright verfolgen ein gemeinsames Ziel: Das Rechner-Setup wird zu etwas, das Sie ausführen, statt sich zu merken. Jeder Abschnitt unten nennt die genauen Befehle dafür — wenn Sie lieber von einer Problemstellung als von einer Funktion ausgehen möchten, schauen Sie sich die Anwendungsfälle an, oder finden Sie Ihre Rolle unter Zielgruppen.

Die Arbeit mit virtuellen Maschinen bedeutet normalerweise ein anderes Tool pro Betriebssystem — hier Tart, dort Hyper-V, anderswo QEMU. Sailwright verbirgt das hinter einem einheitlichen Befehlsvokabular, unabhängig vom Backend darunter: build erstellt oder aktualisiert das wiederverwendbare VM-Image, create richtet das verwaltete Ziel ein, start/stop steuern dessen Betriebszustand, provision führt den Ansible-Setup-Workflow dagegen aus, und destroy entfernt es wieder.

Nutzen Sie den Unterbefehl list bei jedem dieser Befehle (sailwright build list, sailwright provision list usw.), um genau zu sehen, was Ihr aktueller Host unterstützt, sowie --help bei jedem Befehl für dessen vollständige Flag-Liste.

sailwright provision local wendet das Setup-Playbook Ihres Teams auf den Rechner an, an dem Sie gerade sitzen, statt auf eine verwaltete VM — mit --check für einen Testlauf, der zeigt, was sich ändern würde, bevor tatsächlich etwas passiert. Es wählt automatisch das passende Standard-Inventory für Ihr Host-Betriebssystem und erlaubt es Ihnen, Playbook oder Inventory-Pfad direkt über die Kommandozeile zu überschreiben.

Unter Windows geht der Wrapper besonders sorgfältig vor: Er legt ein temporäres Administratorkonto und einen nur lokal erreichbaren WinRM-Listener an (oder einen temporären SSH-Schlüssel bei Verwendung von --proto ssh), führt das Playbook aus und stellt anschließend den vorherigen Zustand wieder her. Da es sich um echte Änderungen am Host handelt, fragt er standardmäßig nach Bestätigung — übergeben Sie --yes, um die Abfrage zu überspringen, sobald Sie dem Ablauf vertrauen.

Für sicherheitsbewusste Teams und Windows-Flottenadmins ist genau das der Punkt: Es bleibt kein dauerhafter Remote-Verwaltungszugriff zurück.

Eine kleine YAML-Konfiguration (ansible-role-sources.yml) lässt Sie den Ansible-Rollensuchpfad und das Standard-Playbook aus mehreren Quellen zusammenstellen: lokale Verzeichnisse, an denen Sie gerade arbeiten, und Git-Repositories, die automatisch geklont und aktuell gehalten werden. Die Quellen sind der Reihe nach gestaffelt, sodass private Anpassungen vor den mitgelieferten öffentlichen Rollen stehen können, ganz ohne Forking.

Richten Sie einen Quellen-Stack auf ein bestimmtes Playbook aus, um es zum Standard-Einstiegspunkt für sailwright provision local und die VM-Provisionierung zu machen, oder behalten Sie die mitgelieferten Beispielrollen und -playbooks als Fallback, während Sie Ihre eigenen aufbauen. So halten Beratungsunternehmen und Organisationen mit mehreren Teams private Anpassungen vor einer gemeinsamen öffentlichen Basis — versioniert und überprüfbar, ohne Forking.

Erstellen Sie ein VM-Image einmal und teilen Sie es über Infrastruktur, die Sie bereits betreiben: Fertige Build-Artefakte können mit sailwright push und sailwright pull in jede beliebige OCI-Registry (im Docker-Stil) gepusht und daraus gepullt werden – mit demselben Zielvokabular wie der VM-Workflow und einer Docker-ähnlichen Image-Referenz. Zugangsdaten stammen standardmäßig aus Ihrer bestehenden docker login-Sitzung, mit zusätzlichen Flags für registry-spezifische Benutzername/Passwort-Kombinationen, Zugriffstoken oder eigene CA-Zertifikate.

Gepushte Artefakte sind ganz normale OCI-Artefakte und damit mit Standardwerkzeugen wie ORAS überprüfbar. Die eigene CI von Sailwright veröffentlicht fertige Ubuntu-Build-Artefakte bei jedem Push auf main in der GitHub Container Registry.

Build-Status, Deployment-Status, Caches und eigenständige Laufzeit-Assets liegen außerhalb des Repositorys in einem betriebssystemgerechten App-Data-Verzeichnis, während die vom Nutzer editierbare Konfiguration in einem separaten, betriebssystemgerechten Config-Verzeichnis liegt — beide lassen sich über Umgebungsvariablen überschreiben, falls die Standardwerte nicht zu Ihrem Setup passen.

Das eigenständige sailwright-Binary außerhalb eines Git-Checkouts auszuführen funktioniert genauso: Beim ersten Lauf extrahiert es seine mitgelieferten Skripte, Playbooks und weiteren Laufzeit-Assets in das verwaltete App-Data-Verzeichnis und hält diesen Verzeichnisbaum bei späteren Läufen synchron.

Diese Funktionen in der Praxis

Neugierig, wie alles in der Praxis zusammenspielt? Stöbern Sie in den Anwendungsfällen für reale Workflows, finden Sie Ihre Rolle unter Zielgruppen, oder tauchen Sie ein in die Dokumentation. Bereit, es auszuprobieren? Releases finden Sie auf GitHub — oder nehmen Sie Kontakt auf, wenn Sie Fragen haben.