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.

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 ist der Zugriff bewusst eng begrenzt und zeitlich befristet: Der Wrapper legt ein zeitlich befristetes Administratorkonto und einen nur lokal erreichbaren WinRM-Listener an (oder einen temporären SSH-Schlüssel bei Verwendung von --proto ssh), die nur für die Dauer des Laufs bestehen, und stellt anschließend den vorherigen Zustand der Maschine wieder her – es bleibt kein dauerhafter Remote-Verwaltungszugriff zurück. 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.

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.

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 pushen und pullen Sie mit sailwright push und sailwright pull in bzw. aus jeder beliebigen OCI-Registry (im Docker-Stil) – 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.

Sailwright bewahrt seinen Build-Status, Caches und Laufzeit-Assets in betriebssystemgerechten App-Data- und Konfigurationsverzeichnissen auf – nichts verteilt sich über Ihr Repository oder Ihr Home-Verzeichnis, und jeder Speicherort lässt sich überschreiben. Details finden Sie unter Verwaltete Anwendungsdaten.

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.