Anwendungsfälle

Reale Szenarien, in denen Sailwright manuelles, auf Erfahrungswissen basierendes Setup durch etwas Wiederholbares ersetzt.

Jedes Szenario unten beschreibt ein Problem, für das Sailwright entwickelt wurde, und nennt jeweils die zugehörigen Befehle — damit Sie Sailwright direkt Ausprobieren können. Möchten Sie lieber herausfinden für wen Sailwright entwickelt wurde? Siehe Zielgruppen.

Onboarding neuer Entwickler

Der Laptop einer neuen Mitarbeiterin oder eines neuen Mitarbeiters sollte nicht davon abhängen, dass ein erfahrener Kollege durch eine Wiki-Seite führt. Richten Sie sailwright provision local auf die gemeinsamen Rollen und Playbooks des Teams — dasselbe Setup, das auf jeder bestehenden Maschine läuft, gilt auch für die neue: auf macOS, Linux oder Windows. Was früher ein halber Tag manueller Installationen und Slack-Fragen war, wird zu einem einzigen Befehl, der bei Bedarf erneut ausgeführt werden kann.

Provisioning-Änderungen sicher testen

Bevor eine Rollenänderung reale Maschinen erreicht, testen Sie sie stattdessen an einem Wegwerf-Ziel: sailwright build, create und provision --check erstellen eine Wegwerf-VM und führen genau das Playbook, das Sie ausliefern wollen, im Trockenlauf aus. Iterieren Sie, bis der Diff passt, provisionieren Sie dann real, um die Konvergenz zu bestätigen, und entfernen Sie die VM anschließend mit destroy, ohne Aufräumarbeiten zu hinterlassen.

Die eigene Workstation im Griff behalten

Behandeln Sie Ihre täglich genutzte Maschine wie jedes andere verwaltete Ziel — statt als Ansammlung von Hand angewendeter Anpassungen. Ein kurzer Aufruf von sailwright provision local --check zeigt Ihnen, was vom vorgesehenen Setup abgewichen ist, bevor Sie überhaupt etwas anfassen; der reale Lauf bringt die Maschine wieder in Ordnung — dieselbe Befehlsoberfläche, egal ob Sie eine echte Workstation oder ein Wegwerf-Testziel prüfen.

Ein Team mit gemischten Betriebssystemen standardisieren

Wenn ein Team macOS, Windows und Linux parallel einsetzt, spalten sich Setup-Anleitungen leicht in drei kaum gepflegte Versionen auf. Mit Sailwright decken plattformübergreifende Rollen die gemeinsame Basis ab, während ansible-role-sources.yml ein privates Override-Repository vor die öffentliche Basis legt — so bleiben teamspezifische Anpassungen versioniert und überprüfbar, ohne den gesamten Rollensatz zu forken.

Build-Artefakte wiederverwenden statt neu bauen

Dasselbe Basis-VM-Image auf jedem Laptop und jedem CI-Runner neu zu bauen kostet Zeit. Übertragen Sie ein fertiges Build-Artefakt einmal mit sailwright push in eine OCI-Registry und holen Sie es dann mit sailwright pull überall dort ab, wo es gebraucht wird — Teammitglieder, CI-Jobs oder eine frische Maschine starten alle mit demselben bewährten Image, statt von Grund auf neu zu bauen. Genau das macht Sailwrights eigene CI: Sie veröffentlicht Ubuntu-Build-Artefakte bei jedem Push auf main in der GitHub Container Registry.

Windows verwalten, ohne eine Tür offen zu lassen

Sicherheitsbewusste Teams wollen keine Windows-Maschine, die dauerhaft über WinRM oder SSH erreichbar ist, nur damit Ansible sie gelegentlich konfigurieren kann. Der lokale Wrapper öffnet einen temporären, nur lokal erreichbaren WinRM-Listener (oder einen temporären SSH-Schlüssel) ausschließlich für die Dauer eines sailwright provision local-Laufs und stellt danach beim Aufräumen den vorherigen Fernzugriffsstatus der Maschine wieder her — es bleibt keine dauerhafte Fernverwaltungsoberfläche zurück.

Eine Oberfläche, jede Betriebssystem-Eigenheit

Ansible verhält sich je nach Umgebung unterschiedlich — hier ein Fork-Safety-Absturz, dort eine verdeckte Python-Installation, da eine Gast-IP, die erst nach einem Moment erscheint. Sailwright fängt diese plattformspezifischen Eigenheiten im Tool selbst ab, sodass Sie unabhängig vom Host denselben Befehl sailwright provision ausführen, statt die Eigenheiten jedes Betriebssystems selbst immer wieder neu zu lernen.

Da jeder Lauf idempotent ist, funktioniert das auch als Wiederherstellungspfad: Richten Sie Sailwright auf eine Maschine, die von ihrem vorgesehenen Zustand abgewichen ist — durch manuelle Anpassungen, einen fehlgeschlagenen Lauf oder den „schnellen Fix“ von jemand anderem —, und ein erneutes Provisioning bringt sie wieder in Ordnung, statt einen kompletten Neuaufbau zu erfordern.

Bereit, es auszuprobieren?

Laden Sie ein Release von GitHub herunter und folgen Sie der Dokumentation, um Ihr erstes provision --check auszuführen. Möchten Sie zuerst die komplette Befehlsübersicht sehen? Siehe Funktionen — oder nehmen Sie Kontakt auf bei Fragen.