Shipyard: Wie Slack seine EC2-Plattform der nächsten Generation aufgebaut hat

• Slack hat vom bisherigen Modell der fortlaufend angepassten, langlebigen EC2-Instanzen auf ersetzende Deployments auf Basis unveränderlicher AMIs umgestellt und damit moderne Deployment-Methoden auch auf Workloads angewandt, die sich nur schwer in Container verlagern lassen
• Auf dem gemeinsamen Basis-Image slack-zero werden service-spezifische Images aufgebaut; aufwendige Konfiguration wird bereits beim Image-Baking erledigt, während umgebungsspezifische Geheimnisse und Metadaten erst beim Booten angewendet werden
• Der Deployment-Orchestrator Gondola verwaltet AMIs und versionierte Chef-Artefakte als eine gemeinsame Deployment-Einheit und führt schrittweise, metrikenbasierte Rollouts, Abbrüche und automatische Rollbacks aus
• Peekaboo stellt nahezu in Echtzeit das vollständige EC2-Inventar bereit, und The Reaper ersetzt verunreinigte oder veraltete Instanzen mit Rate-Limits und Pausenmechanismen
• Für kurzlebige Services ist das effektiv, doch langlebige Instanzen, die sich nicht schnell ersetzen lassen, etwa Datenknoten, GitHub Enterprise oder Atlassian JIRA, benötigen eigene Patch-Methoden und Deployment-Runner

---

Grenzen des fortlaufend modifizierten EC2-Modells

• Slack wandelte seinen bisherigen einzelnen Chef-Stack in eine belastbare Multi-Stack-Struktur um und führte versionierte Cookbook-Deployments sowie sichere Promotionsverfahren ein, wodurch Zuverlässigkeit und operative Kontrolle für Zehntausende EC2-Instanzen verbessert wurden
  • Der zugehörige Prozess ist in Advancing Our Chef Infrastructure beschrieben
• Anschließend wurden segmentierte Produktionsumgebungen, signalbasierte Chef-Ausführung und verbesserte Rollout-Methoden eingeführt, sodass Teams den Wirkungsbereich von Ausfällen stark reduzieren konnten, ohne Cookbooks neu zu schreiben
  • In der Phase Safety Without Disruption gewann Slack Spielraum, um die Legacy-Plattform stabil zu halten und gleichzeitig die künftige Architektur zu planen
• Das Modell, langlebige Instanzen laufend zu aktualisieren, erschwerte jedoch Deployments auf Service-Ebene, machte Infrastructure Drift unvermeidbar und wurde mit der Koordination von Änderungen über mehrere Schichten hinweg immer komplexer
• Container lösten zwar einen Teil dieser Probleme für einige Workloads, doch nicht alle Systeme ließen sich leicht migrieren; daher war eine Plattform nötig, die Unveränderlichkeit, schrittweise Deployments und automatische Sicherheitsmechanismen direkt auf EC2 anwendet

Das von Shipyard bereitgestellte EC2-Betriebsmodell

• Shipyard ist Slacks EC2-Plattform der nächsten Generation, die Infrastruktur nicht als fortlaufend zu modifizierende Instanzen, sondern als deploybare Artefakte behandelt
• Durch die Kopplung von Deployments auf Service-Ebene mit Build- und Orchestrierungssystemen bringt sie dieselbe Sicherheit und Vorhersagbarkeit wie eine Anwendungs-Deployment-Plattform auf EC2-Updates

• Unterstützung mehrerer Architekturen und Betriebssysteme

  • Unterstützt werden mehrere CPU-Architekturen einschließlich AMD64 und ARM-basiertem Graviton; als Betriebssysteme stehen Ubuntu, RHEL und Amazon Linux zur Verfügung
  • Teams können Instanztypen und Betriebssysteme nach Kosten, Leistung und Kompatibilität wählen, ohne separate Plattformimplementierungen zu benötigen
  • Besonders geeignet ist das für Infrastrukturkomponenten, Kubernetes-Worker-Nodes und den Egress-Netzwerk-Stack, die sich nur schwer in Container verlagern lassen

• Sichere Deployments auf Basis von Metriken

  • Jeder Service ist in Gondola integriert und führt schrittweise Rollouts aus, einschließlich automatischer Sicherheitsprüfungen auf Metrikenbasis
  • Abhängig von den Gesundheitssignalen des Services können Deployments automatisch angehalten oder auf eine zuvor stabile Version automatisch zurückgesetzt werden

• Schnelles und vorhersagbares Provisioning

  • Mit einer geschichteten Image-Struktur ähnlich der von Containern werden service-spezifische Images auf einem gemeinsamen Golden Base Image aufgebaut
  • Weil zur Laufzeit weniger Arbeit anfällt, starten Instanzen in mehreren Regionen schnell und konsistent

• Vereinfachtes Konfigurationsmanagement

  • Früher prüften geplante Chef-Jobs die Konfiguration periodisch und setzten sie erneut durch, um manuelle oder unerwartete Änderungen auf den gewünschten Zustand zurückzuführen
  • In Shipyard wird Konfiguration nur noch in klar definierten Lebenszyklusphasen angewendet, etwa beim Image-Baking und bei der initialen Bereitstellung
  • Konfigurationsmanagement-Werkzeuge werden primär für Service-Deployments genutzt, statt das gesamte System fortlaufend zu verändern
  • Dadurch sinken Hintergrundlast und unbeabsichtigte Überschreibungen, und weil sich Instanzen nicht ständig über die Zeit verändern, lässt sich ihr Verhalten leichter nachvollziehen

• Instanzen mit begrenzter Lebensdauer

  • Jede Instanz erhält eine begrenzte Lebensdauer und wird regelmäßig automatisch ersetzt
  • Das verkürzt die Zeitspanne, in der potenzielle Schwachstellen Probleme verursachen könnten, und lenkt Teams dazu, laufende Instanzen zu ersetzen statt sie zu verändern

Peekaboo-Inventar und Transparenz über die gesamte Flotte

• Peekaboo ist ein Inventarsystem, das statt des Chef Server Cloud-Ereignisse und Instanz-Metadaten nutzt, um den Zustand der EC2-Flotte nahezu in Echtzeit anzuzeigen
• Auch außerhalb von Shipyard bereitgestellte Instanzen werden verfolgt, sodass die gesamte Flotte an einem Ort sichtbar ist
• Es basiert auf AWS EventBridge, OpenSearch und Lambda und bietet folgende Schnittstellen
  • eine UI zum Erkunden der Flotte
  • eine API für Systemintegrationen
  • eine CLI für schnelle Prüfungen auf der Kommandozeile
• Durch die Zentralisierung der EC2-Informationen werden Telemetrie und Verwaltungspunkte über die gesamte Umgebung hinweg vereinheitlicht

slack-zero als Golden Base Image

• slack-zero ist ein gemeinsames Maschinen-Image, das vom Compute Platform Team erstellt und gemeinsam mit den Security- und Monitoring-Teams betrieben wird
• Es bildet die standardisierte und vertrauenswürdige Basis, von der alle Services erben, während Service-Teams darauf ihre eigene Runtime-Umgebung aufbauen
• Das Image enthält folgende Elemente
  • OS-Baseline und Einstellungen zur Härtung der Sicherheit
  • Konfiguration für Networking und Service Discovery
  • Monitoring- und Security-Agenten
  • gemeinsame Werkzeuge und grundlegende Systemkonfiguration
• Das Basis-Image wird als unveränderliches und vergängliches Objekt behandelt
  • Wenn Sicherheits-Patches, Monitoring-Updates oder Verbesserungen am Networking nötig sind, wird ein neues slack-zero-Image erstellt
  • Nachgelagerte Service-Images werden auf der neuen Basis neu gebaut und erben so die Änderungen

• Warum AWS Image Builder gewählt wurde

  • slack-zero wird statt mit Packer nun mit AWS Image Builder erstellt
  • Lebenszyklusregeln bereinigen automatisch veraltete AMIs und senken damit Speicherkosten
  • Wenn ein neues Image erzeugt wird, aktualisiert das System den AWS Systems Manager(SSM)-Parameter, der pro Account auf das neueste AMI verweist; Service-Pipelines lesen diesen aus und verwenden so stets die aktuelle Basis
  • Nach erfolgreichem Image-Baking starten EventBridge und Lambda automatisch nachgelagerte Pipelines in den Accounts der Service-Eigentümer
  • Vor der Veröffentlichung eines AMI laufen Verifikationstests auf temporären Instanzen, um das Risiko bei Produktiv-Rollouts zu verringern

Baking und Provisioning von Service-Images

• Jedes Service-Team erstellt auf Basis von slack-zero ein eigenes AMI, übernimmt damit die gemeinsamen Plattformkomponenten und behält gleichzeitig die Kontrolle über seine Runtime-Umgebung
• Die Pipeline für Service-Images definiert folgende Punkte
  • welche Software installiert wird
  • wie der Service konfiguriert wird
  • welches Initialisierungsverfahren für die Instanzen dieses Services gilt
• Der Großteil der Konfiguration wird bereits ins Image eingebaut, um Laufzeitgeschwindigkeit und Konsistenz zu erhöhen und Configuration Drift zu minimieren

• Rollentrennung in zwei Phasen

  • In der Baking-Phase werden Pakete und umgebungsübergreifend gemeinsame Konfiguration installiert, damit die Instanz schon vor dem Start weitgehend in einem betriebsbereiten Zustand ist
  • In der Provisioning-Phase werden beim Booten nur noch umgebungsabhängige Einstellungen angewendet, etwa Geheimnisse, regionsspezifische Konfiguration oder Deployment-Metadaten
  • Typischerweise umfasst das nur das Platzieren von Konfigurationsdateien, das Abrufen von Geheimnissen und das Starten von Services
  • Durch die Verlagerung schwergewichtiger Aufgaben wie Paketinstallationen in die Baking-Phase können Instanzen in Sekunden statt in Minuten starten
  • Schnelle Starts sind wichtig für Skalierungsereignisse, sequenzielle Deployments und den automatischen Instanzersatz, und minimales Provisioning dämpft Drift, der während der Laufzeitanpassung entstehen würde

Flotten-Updates mit Fokus auf AMI-Ersatz

• Änderungen werden durch das Erstellen eines neuen AMI und den Rollout über die Deployment-Pipeline ausgebracht; die Flotte wird per kontrolliertem Ersatz statt durch Patchen bestehender Instanzen aktualisiert
• Auto Scaling Group(ASG) verwendet AWS Instance Refresh, Kubernetes-Worker-Flotten nutzen Karpenter
• Services mit besonderen Deployment-Anforderungen können eigene Runner hinzufügen; Gondola vereinheitlicht dabei verschiedene Muster zu einem konsistenten Deployment-Erlebnis

• Pfad für Notfallkorrekturen

  • In Notfällen können auf laufende Instanzen begrenzte Konfigurationsänderungen angewendet werden, anschließend müssen diese Instanzen jedoch über die normale Deployment-Pipeline ersetzt werden
  • Mit vordefinierten Dokumenten von AWS Systems Manager werden ausgewählte Chef-Rezepte ausgeführt, um Notfallkorrekturen anzuwenden
  • Sobald das System wieder stabil ist, werden die Instanzen rotiert, um zum beabsichtigten unveränderlichen Zustand zurückzukehren

Gondolas schrittweise Deployments

• Kunden-Pipelines können aus mehreren Phasen bestehen, die auf Service- und Betriebsanforderungen zugeschnitten sind
• Jede Gondola-Phase repräsentiert eine Deployment-Einheit wie eine ASG, einen Kubernetes-Cluster oder eine EC2-Instanzgruppe
• Das Egress Team betreibt pro Availability Zone getrennte Canary- und Produktions-ASGs und ordnet die Phasen so an, dass Updates sequenziell weitergegeben werden
• Gondola überwacht bei der Aktualisierung jeder Phase die wichtigsten Metriken und führt bei Problemen automatische Rollbacks aus, um die Ausbreitung von Ausfällen zu verhindern

• Deployment-Artefakte und Runner

  • Das von Gondola erzeugte Deployment-Paket besteht aus zwei Teilen
    • dem AMI, das in die Flotte ausgerollt wird
    • dem Chef-Artefakt mit versionierten Recipes, verknüpft mit einem Git-Commit
  • Beide Elemente werden als eine gemeinsame Deployment-Einheit behandelt, und jede Phase rollt sie über den vom Service definierten Runner aus
  • Bei ASG-Deployments aktualisiert der Runner das Launch Template mit dem neuen AMI und der neuen Konfiguration
  • Chef-Code wird in Amazon S3 paketiert
  • Der integrierte Bootstrapper neuer Instanzen holt das richtige Artefakt und führt die zugehörigen Recipes aus
  • Anhand von Konfigurationsmetadaten werden nur die Einstellungen angewendet, die zu der jeweiligen Rolle passen
  • In Kubernetes-Worker-Flotten übergibt der Runner an Karpenter das zu verwendende AMI und dieselben Konfigurationsmetadaten; auch die Nodes werden auf diese Weise gebootstrapped
  • Selbst wenn Runner für Spezial-Deployments hinzukommen, bleiben AMI, versioniertes Konfigurationsartefakt und metadatenbasiertes Bootstrap-Verfahren unverändert

Aufgabenteilung zwischen Plattform- und Service-Teams

• Die Teams für Compute, Security und Monitoring verwalten globale Infrastrukturkomponenten der Basisschicht, Sicherheits-Patches und verpflichtende Einstellungen
• Service-Teams bauen darauf aufbauend AMIs, die ihre eigene Software und service-spezifische Konfiguration ergänzen
• Wenn das Compute-Team Sicherheits-Patches, Monitoring-Agenten oder Änderungen am Networking ausrollt, müssen die Service-Teams das aktualisierte Basis-Image in ihre eigenen AMIs übernehmen
• Dieses Shared-Responsibility-Modell verbindet service-spezifische Autonomie mit Konsistenz, Sicherheit und Zuverlässigkeit über die gesamte Flotte hinweg

Geheimnisse als Ausnahme von vollständiger Unveränderlichkeit

• Pakete und Konfiguration von Shipyard-Instanzen werden größtenteils schon beim Baking festgelegt, doch Geheimnisse bilden eine Ausnahme
• Der Consul-Template-Service jeder Instanz verteilt neue Geheimnisse aus Vault, ohne dass dafür die Flotte ersetzt werden muss
• Da Anmeldedaten und Zertifikate dynamisch aktualisiert werden können, ist Shipyard nur für Kernsysteme und die Service-Schicht eine semi-unveränderliche Infrastruktur
• So bleiben Stabilität und Vorhersagbarkeit erhalten, während wichtige Runtime-Geheimnisse bei Bedarf aktualisiert werden können

Die Ersatzrichtlinien von The Reaper

• The Reaper bestimmt Ersetzungskandidaten anhand von zwei Arten von Eingaben
  • Verunreinigungssignalen aus externen Systemen wie Security-Werkzeugen oder AWS-EC2-Ereignissen, die melden, dass eine Instanz vom gewünschten Zustand abgewichen ist
  • regelmäßigen Prüfungen, ob die Instanz länger als die maximal erlaubte Lebensdauer läuft
• Wenn eine der Bedingungen erfüllt ist, wird entsprechend der Service-Richtlinie ein Instanzersatz eingeplant
• Manuelle Remote-Zugriffe bleiben für Notfälle erlaubt, doch direkter Zugriff auf produktionsreife Nodes erzeugt ein Signal, das die betreffende Instanz für einen späteren Ersatz markiert
• In Integration mit Peekaboo wird das Alter von Instanzen über die gesamte Flotte hinweg verfolgt, und Nodes, die ihre maximale Lebensdauer erreichen, durchlaufen denselben geregelten Terminierungs- und Ersatzprozess
• Künftig soll Kontextbewusstsein ergänzt werden, sodass nur bedeutsame Änderungen wie Software-Updates oder Configuration Drift zu einem Ersatz führen, während schreibgeschützte oder risikoarme Tätigkeiten keine unnötigen Rotationen auslösen

• Ersatzgeschwindigkeit und Notfallkontrolle

  • Eingebaute Rate-Limits legen pro Service, Region und Availability Zone fest, wie viele Instanzen gleichzeitig ersetzt werden dürfen, um plötzliche Kapazitätsauswirkungen zu verhindern
  • Mit einem globalen Pausenmechanismus namens „big red button“, der über ein Steuerobjekt in S3 aktiviert wird, lassen sich alle Aktivitäten von Reaper während Störungen oder Hochrisikophasen stoppen
  • Über die CLI können Rate-Limits verwaltet, Konfigurationen geprüft sowie die globale Pause aktiviert und aufgehoben werden
  • Für Break-Glass-Situationen, die tiefere Untersuchungen erfordern, können kontrollierte Zugriffsverfahren wie kurzlebige SSH-Zertifikate verwendet werden

Realistische Infrastrukturtests mit Ship Quick

• Ship Quick ist ein Entwickler-Workflow, mit dem Plattform-Teams und Service-Eigentümer vor dem Merge eines Pull Requests realistische Baking- und Provisioning-Tests auf echter Infrastruktur ausführen können
• Entwickler führen in einem Cookbook-Repository einen CLI-Befehl aus und definieren Testfälle in einer YAML-Datei
• Ship Quick verarbeitet dann in folgender Reihenfolge
  • das Cookbook wird paketiert und nach S3 hochgeladen
  • eine Workflow-Nachricht wird an eine Queue gesendet
  • von Longshoremen verwaltete Worker-Instanzen holen den Auftrag ab
  • der Worker wird aus der Auto Scaling Group herausgelöst und führt den Chef-Workflow aus
  • Logs werden an die CLI gestreamt, anschließend wird die Instanz beendet; optional kann der Entwickler sie zur Fehlersuche bestehen lassen

• Worker-Flotten nach Basisschicht

  • Aufgrund der Bootstrap-Struktur werden zwei getrennte Worker-Flotten betrieben
  • Die Ubuntu-Basisflotte backt und testet das Basis-Image auf einem sauberen Ubuntu-AMI, da slack-zero nicht auf sich selbst gebaut werden kann
  • Die slack-zero-Flotte testet Cookbooks von Service-Teams, die auf einem vorgebackenen slack-zero basieren
  • Das Provisioning wird auf derselben Basis wie in der Produktion validiert
  • Die Flotten werden laufend mit aktuellen Images aktualisiert und spiegeln so die aktuelle Produktionsumgebung wider
  • Beide Flotten skalieren automatisch entsprechend der Nachfrage
  • Teams, die Images in ihrem eigenen AWS-Account erstellen, können eine dedizierte Worker-Flotte konfigurieren und Ship-Quick-Jobs dorthin leiten, um die Isolation zu wahren

Ausweitung auf langlebige Workloads

• Shipyard funktioniert derzeit effektiv für kurzlebige Services und onboardet weiterhin Teams von der Legacy-EC2-Plattform
• Die nächste Herausforderung sind langlebige Instanzen, die sich nicht schnell rotieren lassen
  • Slack-Datenknoten
  • Singleton-Services wie GitHub Enterprise
  • Business-Tech-Instanzen von Drittanbietern wie Atlassian JIRA
• Diese Workloads benötigen sichere Patch- und Update-Methoden sowie Lebenszyklusregeln, die The Reaper korrekt verarbeiten kann
• In Zusammenarbeit mit Service-Teams entwickelt Slack dafür Runner für langlebige Workloads für Gondola und plant, Werkzeuge, Entwickler-Workflows und das Deployment-Erlebnis mit wachsender Verbreitung weiter zu verbessern
• Künftig sollen Shipyard-API, Image-Pipelines, Entwickler-Workflows, Komponenten des Inventarsystems und die beim Ausbau der Plattform aufgetretenen Probleme separat behandelt werden