Das Problem mit dem ständigen Konfigurieren
Du betreibst tausende Server, jeder über Jahre gewachsen – ein Patch hier, ein neues Tool da, eine manuelle Änderung dort. Nach einer Weile gleicht kein Server mehr dem anderen. Das ist Konfigurationsdrift, ein Albtraum für Infrastructure-Teams. Bei Slack war das lange Realität. Die Plattform verwendete Chef, um die Konfiguration auf Amazon EC2-Instanzen durchzusetzen. Die Chef-Infrastruktur war über die Jahre robuster geworden – mit versionierten Cookbooks, gestaffelten Rollouts und split environments. Aber das grundlegende Modell blieb: Instanzen wurden kontinuierlich aktualisiert, der Zustand nie wirklich eingefroren. Irgendwann war klar: Dieser Ansatz stößt an Grenzen.
Dienstebezogene Deployments waren fummelig, weil jede Instanz ihren eigenen Zustand hatte. Sicherheitsupdates mussten nach und nach aufgespielt werden. Fehler in einer Konfiguration konnten sich über die gesamte Fleet ausbreiten. Viele Unternehmen setzen auf Container. Aber nicht alle Workloads lassen sich containerisieren – etwa Kubernetes-Worker-Nodes, Netzwerk-Stacks oder Infrastruktur-Komponenten. Slack brauchte einen neuen Weg, um EC2-Instanzen mit der Vorhersagbarkeit und Sicherheit moderner App-Plattformen zu betreiben. Die Antwort: Shipyard.
Eine Plattform, die Infrastruktur wie Code behandelt
Shipyard ist kein weiteres Konfigurationsmanagement-Tool. Es ist eine Plattform, die das Paradigma umdreht: Statt Instanzen nach der Geburt ständig zu verändern, werden sie als unveränderliche Artefakte gebaut und ausgerollt. Jede Änderung führt zu einem neuen Image. Instanzen werden nicht mehr gepatcht, sondern durch frische ersetzt. Das ist radikal, aber genau das, was Container uns seit Jahren vormachen. Shipyard überträgt diese Ideen auf EC2.
Die Plattform unterstützt mehrere CPU-Architekturen – AMD64 und ARM (Graviton) – sowie Betriebssysteme wie Ubuntu, RHEL und Amazon Linux. Das ist kein Luxus, sondern nötig, wenn man heterogene Workloads mit unterschiedlichen Kosten- und Performance-Anforderungen bedient. Shipyard ist keine schnelle Bastellösung, sondern auf langfristige Flexibilität ausgelegt. Die Grundlage: ein mehrschichtiger Image-Ansatz, ähnlich dem Aufbau von Docker-Images.
Das Fundament: slack-zero als „Goldenes Base Image“
Am unteren Ende der Schichten steht ein Basis-Image namens slack-zero. Es enthält, was jede Instanz braucht: Betriebssystem mit Härtung, Netzwerk- und Service-Discovery-Konfiguration, Monitoring- und Security-Agenten, grundlegende Tools. Denk an ein Ubuntu-Base-Image für Container, aber für eine ganze EC2-Fleet. Dieses Image wird vom Compute-Platform-Team zusammen mit Security und Monitoring erstellt und gepflegt. Es ist unveränderlich, aber nicht statisch – wenn sich die Basis ändert, wird eine neue Version von slack-zero gebaut.
Zum Erstellen nutzt Slack AWS Image Builder statt des früheren Packer. Image Builder bietet integrierte Lifecycle-Verwaltung: alte AMIs werden automatisch gelöscht, neue AMIs aktualisieren einen SSM-Parameter. Per EventBridge und Lambda werden automatisch nachgelagerte Pipelines angestoßen, sobald ein neues Base-Image bereitsteht. Bevor ein Image veröffentlicht wird, startet Image Builder Testinstanzen und führt Validierungen aus. Das Risiko, ein kaputtes Image auszuliefern, wird minimiert. Slack-zero ist das Fundament für alles andere.
Service-spezifische Images und das Baking-Prinzip
Auf diesem Fundament setzen die Service-Teams ihre eigenen Images auf. Jedes Team definiert, welche Software installiert wird, wie der Dienst konfiguriert ist und was beim Start passiert. Das meiste wird direkt ins Image „hineingebacken“. Slack unterscheidet zwei Phasen: Baking und Provisioning. Beim Baking werden alle umgebungsunabhängigen Komponenten installiert – Pakete, Libraries, grundlegende Konfiguration. Das passiert einmal, bevor die Instanz jemals startet. Beim Provisioning, also beim ersten Booten, kommen nur umgebungsspezifische Daten dazu: Secrets, regionale Konfiguration, Metadaten. Das ist ein leichter Schritt, in Sekunden erledigt.
Ergebnis: Instanzen sind innerhalb weniger Sekunden betriebsbereit. Das beschleunigt Scaling-Events, erleichtert Rolling Deployments und macht die automatische Rotation von Instanzen praktikabel. Durch das Verlegen der schweren Arbeit ins Baking entfällt das Nachinstallieren während der Laufzeit. Die Instanzen bleiben konsistent – sie starten von einem definierten Zustand und ändern sich nicht mehr, es sei denn, ein Notfall erzwingt einen direkten Eingriff.
Deployments und Rollouts: Metriken als Sicherheitsnetz
Wenn ein Team eine Änderung ausrollen will, baut es ein neues AMI und stößt eine Deployment-Pipeline an. Die Pipeline arbeitet mit dem Orchestrator Gondola zusammen, der progressive Rollouts ermöglicht. Jede Phase des Rollouts – etwa eine Canary-ASG in einer Availability Zone – wird einzeln aktualisiert. Gondola überwacht kontinuierlich Metriken wie Latenz, Fehlerraten oder CPU-Auslastung. Bei Problemen stoppt Gondola die Auslieferung automatisch und kann ein automatisiertes Rollback zur vorherigen AMI-Version einleiten.
Für Auto Scaling Groups nutzt Slack AWS Instance Refresh, für Kubernetes-Worker Karpenter. Gondola abstrahiert die Details, sodass die Teams einen einheitlichen Mechanismus sehen, auch wenn die zugrundeliegende Technik variiert. Niemand muss mehr manuell auf Servern herumkommandieren. Änderungen werden systematisch und nachvollziehbar ausgerollt. Fehler haben minimalen Wirkungsbereich. Das Prinzip der Immutability wird konsequent durchgehalten – geflickt wird nicht, ersetzt wird.
Notfälle: Ausnahmen bestätigen die Regel
Es gibt Situationen, in denen man schnell handeln muss – ein kritischer Sicherheitspatch, ein Fehler, der erst in der Produktion auffällt. Shipyard erlaubt für solche Fälle gezielte Änderungen an laufenden Instanzen. Aber das sind Ausnahmen mit klarem Prozedere. Slack setzt dafür AWS Systems Manager mit einem festgelegten Dokument ein, das ausgewählte Chef-Rezepte ausführen kann. Solche Eingriffe sind nicht der neue Normalzustand. Die betroffenen Instanzen werden nach der Stabilisierung über die regulären Deployment-Pipelines ersetzt, damit sie in den gewünschten, unveränderlichen Zustand zurückkehren. Der Weg zurück zur Immutabilität ist immer Teil des Prozesses.
Peekaboo: Transparenz über die gesamte Fleet
Ein altes Problem bei großen EC2-Fleets ist mangelnde Transparenz. Früher verließ sich Slack auf den Chef Server als Quelle der Wahrheit – ungenau und langsam. Mit Shipyard kommt ein neues Inventarsystem namens Peekaboo. Es nutzt AWS EventBridge, OpenSearch und Lambda, um Ereignisse aus der Cloud direkt zu verarbeiten. Peekaboo liefert nahezu in Echtzeit einen Überblick über alle Instanzen, auch solche, die nicht über Shipyard verwaltet werden. Es gibt eine UI, eine API und eine CLI. Teams können den Zustand ihrer Fleet abfragen, ohne sich durch Logs zu wühlen oder auf veraltete Datenbanken angewiesen zu sein. Das erhöht die Sicherheit, weil man sofort erkennt, ob irgendwo eine unerwartete Instanz läuft, und erleichtert das Debugging.
Ein Paradigmenwechsel für EC2
Was Slack mit Shipyard geschaffen hat, ist mehr als ein neues Tool. Es ist ein kultureller Wandel im Umgang mit Infrastruktur. Administratoren basteln nicht mehr auf Servern herum und hoffen, dass nichts kaputtgeht. Stattdessen wird die gesamte Maschinenkonfiguration in ein deklaratives Artefakt gegossen, das durch CI/CD-Pipelines getestet und ausgerollt wird. Der Fokus verschiebt sich von der Wartung von Instanzen zum Bau von Images. Das macht das System sicherer, vorhersagbarer und einfacher zu debuggen – bei einer problematischen Instanz baut man einfach ein neues Image und tauscht sie aus.
Für Teams, die EC2 betreiben, ist das eine konkrete Antwort auf die Frage, wie man moderne Deployment-Praktiken auf nicht-containerisierbare Workloads anwendet. Man muss nicht auf Kubernetes umsteigen, um von Rolling Updates, automatischen Rollbacks und Metric-basierten Sicherheitschecks zu profitieren. Shipyard zeigt, dass sich dieselben Prinzipien auf virtuelle Maschinen übertragen lassen – mit durchdachtem Layering, effizienter Bauweise und einer Plattform, die die Komplexität verbirgt. Das könnte ein Signal für andere Unternehmen sein, die noch mit traditionellen Konfigurationsmanagement-Tools kämpfen.
Die Reise von Slack ist noch nicht zu Ende. Shipyard ist im produktiven Einsatz, aber das Team arbeitet kontinuierlich an Verbesserungen. Doch schon jetzt zeigt sich: Der Schritt von kontinuierlicher Konfiguration zu artifakt-basierten Deployments ist kein Luxus, sondern eine Notwendigkeit für zuverlässige, sichere und skalierbare Infrastruktur. Wenn deine eigenen Server noch wie handgepflegte Unikate aussehen, ist es vielleicht Zeit, über einen ähnlichen Paradigmenwechsel nachzudenken.
Quelle: slack.engineering
