xPhoenix - Workstation aus der Asche

Was treibt mich hier an? Ein Entwickler-Trauma

Es war Donnerstag … ein ganz normaler Donnerstag … bis mein MacBook Pro einfach auschaltete.

Bis dahin war ich mitten in der Endphase der Entwicklung und Integration einer virtual Appliance. Montag sollte die Demo beim Kunden sein und der Mac is weg. Ich konnte den neu starten, aber wenige Minuten später war es dann jeweils wieder vorbei mit Glanz und Glorie!

Eine Stunde und gefühlte 20 Reboots später war das Problem eingekreist: Der Mac überhitzte, weil ein Lüfter ausgefallen war.

Eigentlich eine gute Nachricht, aber die war nur der Beginn einer Odyssee. Ich brauchte einen neuen Lüfter. Bis zur Demo konnte ich den Mac aufbocken und mit einem kapitalen Raumlüfter die offene Unterseite kühlen. Laut, windig, aber stabil. Das Konstrukt konnte ich natürlich nicht beim Kunden aufbauen ohne mich bis auf die Knochen zu blamieren. Ich hatte Glück, dass überhaupt noch etwas lief.

Meine Entwicklungsumgebung war aber nicht virtualisiert, nur das End-Produkt wurde eine VM. Also spielten Dutzende Tools zusammen um das Endprodukt zu erstellen. Das Demo-Environment war nun mal auf diesem Mac. Das woanders neu aufzusetzen hätte zu lange gedauert.

Also zu Gravis! Von da hatte ich den Rechner und dort hatte ich eine Reparatur-Versicherung. Dort sagte man mir:

  • Rechner dort lassen, weil Apple das so will
  • Ersatzteile sind per Seriennummer zugeordnet, Originalteile werden per Dekret von Apple zurückgeschickt und bis zum Ende der Reparatur muss der Rechner in der Werkstatt verbleiben.
  • Dauer 5-9 Tage

Outch! Ich bin fast mutiert. Also wieder raus und 2 weitere Händler abgeklappert … gleiche Aussagen. Ich kann sogar Apple verstehen: durch solche Regeln hält man die Qualität hoch. Aber ich hing nun in der Luft. Ein Tech des letzten Händlers riet mir dann, nach Oberhausen zu fahren und Service im Apple-Store am Genius-Desk zu suchen. Vorher Termin machen! Gelernt und getan und siehe da, Samstag Mittag hatte ich zwei brandneue Lüfter und die Kiste lief.

Das war sehr knapp gut gegangen. Was wenn nicht? Dann wäre ich samt Reputation baden gegangen. Wo war das Problem?

Das zu Grunde liegende Problem

Das eigentliche Problem in der Geschichte war nicht der kaputte Lüfter oder der strikt geregelte Support. Das Problem war meine eigene Abhängigkeit von meiner Maschine.

Hätte ich meine Entwicklungsumgebung inkl. meiner Sources und Tools in endlicher Zeit auf eine andere Kiste transferieren können, wäre es kein Problem gewesen. Ok, Ihr Apple-Enthusiasten, hört auf zu unken, natürlich hätte ich einen neuen Mac kaufen können und ein Time-Machine-Backup drauf installieren können, aber ehrlich … 3k€ um einen defekten Lüfter zu kompensieren, bleiben wir mal etwas auf dem Boden.

PCs und Notebook hatte ich jede Menge. Meine Entwicklung nutzte den Mac als Workstation, das eigentliche Produkt war Linux.

Spinnen wir mal rum …

Es wäre doch sehr schön, hätte man eine automatisch aufgesetzte und bis in die Spitzen konfigurierte Workstation. Idealerweise sollte man einen beliebigen leeren Rechner binnen einer Stunde in eine taugliche Arbeitsplattform verwandeln können. Dieses inkl. …

  • Betriebssystem
  • Tools & Apps
  • eigene Sourcen

Der Werkzeugkasten

Denken wir uns mal einen aktuellen Arbeitsplatz für einen Entwickler zusammen:

  • Betriebssystem (also nicht Windows), z.B. Linux oder MacOS
  • Tools: Editor, Hypervisor, Browser, …
  • Devops:
    • Vagrant: VMs scripten
    • Ansible: Configuration-Management scripten
    • GIT: Scripte versionieren und im Internet zentral und sicher lagern

Ich gehe also davon aus, dass meine Workstation unabhängig von der eigentlichen Entwicklungsumgebung standardisiert aufgesetzt werden kann.

Die eigentliche Entwicklungsumgebung wird mit Vagrant und Ansible automatisiert aufgesetzt und mit meinen Sourcen versorgt.

Die logische Konsequenz

Wenn man schon die eigentliche Entwicklungsumgebung als VM mit Ansible konfiguriert, warum dann nicht auch gleich die Workstation?

Nicht reden … machen!

Derzeit baue ich einen Satz Skripte, mit denen ich ein Vanilla-aufgesetztes Kubuntu in eine waffenstarrende Entwicklerfestung verwandeln kann. All das inkl. optischen Gimmicks wie die Konfiguration von KDE, eigene Wallpapers, etc. pp. Schließlich sind Entwickler Künstler ;-). Der Gedanke: 30 Minuten für die Installation des OS, weitere 30 Minuten für den Download der Skripte und dem Durchlauf der weitergehenden Installation. Reboot! Fertig!

Ist das eine Utopie? Nein!

Ich bin mittendrin: ein Shell-Skript setzt GIT und Ansible auf und sorgt dafür dass Ansible-Vaults entschlüsselt werden können. Die perönlichen Setups und Konfigs (z.B. SSH-Schlüssel) liegen in Vaults in einer Sicherung im Internet. Das Ganze sind nur ein paar kB, das meiste wird generiert und nicht gesichert.

Ein einziges Kommando startet die Regeneration der Workstation, inkl. eigener Zugangsschlüssel, Wallpapers, Einstellungen, Vagrant-Maschinen und Ansible-Playbooks.

Das Ziel

Ich kann meine Workstation in einer Stunde auf eine neue Hardware klonen und das notfalls über mein Handy mit Tethering. Mehr Macht geht nicht.

Jetzt der Clou: erste Experimente haben sowohl auf MacOS als auch auf Kubuntu perfekt funktioniert. Aber ich schreibe den Code nochmal von Grund auf neu. Er soll seamless auf beiden Plattformen funktionieren. Andere … braucht doch keiner.

Wünscht mir Glück und Durchhaltevermögen!

Und weiter?

Ich hatte angefangen in einem Wiki meine Ideen und Fortschritte zu dokumentieren. Das mache ich nun auch neu: SWG via Jenkins. Passt besser ins Bild. Hier im Blog gibt es Updates wenn sich was tut.

Featured Articles
Featured posts