Shipyard : comment Slack a construit sa plateforme EC2 de nouvelle génération

• Slack est passé de son ancien modèle consistant à modifier en continu des EC2 longue durée à des déploiements par remplacement basés sur des AMI immuables, appliquant ainsi des pratiques de déploiement modernes même aux workloads difficiles à migrer vers des conteneurs
• Sur une image de base commune, slack-zero, Slack empile des images propres à chaque service ; la configuration lourde est traitée lors du baking de l’image, tandis que seuls les secrets propres à l’environnement et les métadonnées sont appliqués au démarrage
• L’orchestrateur de déploiement Gondola gère une AMI et un artefact Chef versionné comme une seule unité de déploiement, et effectue des déploiements progressifs pilotés par les métriques, des interruptions et des rollbacks automatiques
• Peekaboo fournit un inventaire quasi temps réel de l’ensemble des EC2, et The Reaper remplace les instances corrompues ou arrivées en fin de vie avec des limites de débit et des mécanismes de pause
• L’approche est efficace pour les services à courte durée de vie, mais les instances longue durée impossibles à remplacer rapidement, comme les nœuds de données, GitHub Enterprise ou Atlassian JIRA, nécessitent une méthode de patch distincte et des exécuteurs de déploiement dédiés

---

Les limites du modèle EC2 modifié en continu

• Slack a remplacé son ancienne pile Chef unique par une architecture multi-pile résiliente, introduit des déploiements de cookbooks versionnés et des procédures de promotion sûres, afin d’améliorer la fiabilité et le contrôle opérationnel de dizaines de milliers d’instances EC2
  • Le processus associé est décrit dans Advancing Our Chef Infrastructure
• Slack a ensuite introduit des environnements de production segmentés, des exécutions Chef déclenchées par signal et de meilleurs modes de rollout, réduisant fortement le rayon d’impact des incidents sans obliger les équipes à réécrire leurs cookbooks
  • L’étape Safety Without Disruption a permis de maintenir la stabilité de la plateforme legacy tout en donnant le temps de planifier l’architecture future
• Mais le modèle consistant à mettre à jour en continu des instances longue durée rendait les déploiements par service difficiles, ne permettait pas d’éviter le drift d’infrastructure, et devenait de plus en plus complexe à mesure qu’il fallait coordonner les changements sur plusieurs couches
• Les conteneurs ont résolu une partie des problèmes pour certains workloads, mais tous les systèmes ne pouvaient pas être migrés facilement ; Slack avait donc besoin d’une plateforme appliquant directement à EC2 l’immuabilité, les déploiements progressifs et les garde-fous automatiques

Le modèle d’exploitation EC2 proposé par Shipyard

• Shipyard est la plateforme EC2 de nouvelle génération de Slack, qui traite l’infrastructure comme des artefacts déployables plutôt que comme des instances à modifier en continu
• Elle combine les déploiements par service avec des systèmes de build et d’orchestration, afin d’appliquer aux mises à jour EC2 le même niveau de sûreté et de prévisibilité qu’aux plateformes de déploiement applicatif

• Prise en charge de plusieurs architectures et systèmes d’exploitation

  • Elle prend en charge plusieurs architectures CPU, dont AMD64 et les Graviton basés sur ARM, ainsi qu’Ubuntu, RHEL et Amazon Linux
  • Les équipes peuvent choisir leurs instances et systèmes d’exploitation selon le coût, les performances et la compatibilité, sans implémentation de plateforme séparée
  • C’est particulièrement adapté aux composants d’infrastructure, aux nœuds workers Kubernetes et aux piles réseau egress difficiles à migrer vers des conteneurs

• Déploiements sûrs pilotés par les métriques

  • Chaque service s’intègre à Gondola pour exécuter des rollouts progressifs incluant des contrôles de sécurité automatiques basés sur les métriques
  • Selon les signaux d’état du service, le déploiement peut être automatiquement interrompu ou faire l’objet d’un rollback automatique vers la dernière version saine

• Provisioning rapide et prévisible

  • Shipyard utilise une structure d’images en couches similaire aux conteneurs pour construire des images propres à chaque service sur une image de base golden commune
  • En réduisant le travail à effectuer à l’exécution, les instances démarrent rapidement et de façon cohérente dans plusieurs régions

• Gestion de configuration simplifiée

  • Auparavant, des tâches Chef planifiées vérifiaient périodiquement la configuration et la réappliquaient, ramenant les changements manuels ou inattendus vers l’état souhaité
  • Avec Shipyard, la configuration n’est appliquée qu’à des étapes de cycle de vie explicites, comme le baking de l’image et le provisioning initial
  • Les outils de gestion de configuration servent principalement à déployer des services, plutôt qu’à modifier en continu tout le système
  • Cela réduit la charge en arrière-plan et les écrasements involontaires, et rend le comportement plus facile à raisonner car les instances ne changent pas continuellement avec le temps

• Instances à durée de vie limitée

  • Chaque instance reçoit une durée de vie limitée et est automatiquement remplacée à intervalles réguliers
  • Cela réduit la fenêtre pendant laquelle des vulnérabilités potentielles peuvent poser problème, et incite les équipes à remplacer les instances en cours d’exécution plutôt qu’à les modifier

Inventaire Peekaboo et visibilité sur toute la flotte

• Peekaboo est un système d’inventaire qui utilise les événements cloud et les métadonnées d’instances, plutôt que Chef Server, pour afficher l’état de la flotte EC2 presque en temps réel
• Il suit aussi les instances déployées en dehors de Shipyard, afin de visualiser toute la flotte au même endroit
• Il est construit avec AWS EventBridge, OpenSearch et Lambda, et fournit les interfaces suivantes
  • Une UI pour explorer la flotte
  • Une API pour les intégrations système
  • Une CLI pour des vérifications rapides en ligne de commande
• En centralisant les informations EC2, il unifie la télémétrie et les points de gestion à l’échelle des environnements

Image de base golden slack-zero

• slack-zero est une image machine commune créée par la Compute Platform Team et cogérée avec les équipes sécurité et monitoring
• C’est une base standardisée et fiable dont héritent tous les services, les équipes service configurant leur propre environnement d’exécution par-dessus
• L’image inclut les éléments suivants
  • Baseline du système d’exploitation et paramètres de durcissement de sécurité
  • Configuration réseau et service discovery
  • Agents de monitoring et de sécurité
  • Outils communs et configuration des systèmes de base
• L’image de base est traitée comme une cible immuable et éphémère
  • Lorsqu’un patch de sécurité, une mise à jour de monitoring ou une amélioration réseau est nécessaire, une nouvelle image slack-zero est créée
  • Les images des services descendants sont reconstruites sur cette nouvelle base pour hériter des corrections

• Pourquoi AWS Image Builder a été choisi

  • slack-zero est construit avec AWS Image Builder, à la place de l’ancien Packer
  • Les politiques de cycle de vie nettoient automatiquement les anciennes AMI, réduisant les coûts de stockage
  • À chaque création d’une nouvelle image, un paramètre AWS Systems Manager (SSM) pointant vers la dernière AMI de chaque compte est mis à jour ; les pipelines de service le lisent pour utiliser la base la plus récente
  • Quand le baking d’image réussit, EventBridge et Lambda lancent automatiquement les sous-pipelines dans les comptes des propriétaires de services
  • Avant de publier une AMI, des tests de validation sont exécutés sur une instance temporaire afin de réduire les risques des rollouts en production

Baking et provisioning des images de service

• Chaque équipe service crée sa propre AMI à partir de slack-zero, héritant des composants communs de plateforme tout en contrôlant son environnement d’exécution
• Le pipeline d’image de service définit les éléments suivants
  • Les logiciels à installer
  • La façon de configurer le service
  • La procédure d’initialisation des instances de ce service
• La plupart de la configuration est incluse dans l’image afin d’améliorer la vitesse d’exécution et la cohérence, et de minimiser le drift de configuration

• Séparation des rôles en deux étapes

  • À l’étape de baking, les packages et la configuration commune entre environnements sont installés, de sorte que l’instance dispose déjà d’un état largement prêt et sain avant l’exécution
  • À l’étape de provisioning, seuls les paramètres dépendants de l’environnement sont appliqués au démarrage, comme les secrets, la configuration propre à la région et les métadonnées de déploiement
  • En général, elle ne fait que placer les fichiers de configuration, récupérer les secrets et démarrer le service
  • En déplaçant les tâches lourdes comme l’installation de packages vers le baking, les instances peuvent devenir opérationnelles en quelques secondes plutôt qu’en plusieurs minutes
  • Un démarrage rapide est important pour les événements de scaling, les déploiements séquentiels et le remplacement automatique d’instances ; un provisioning minimal limite aussi le drift généré par l’adaptation à l’exécution

Mises à jour de flotte centrées sur le remplacement d’AMI

• Les changements sont déployés en créant une nouvelle AMI puis en la diffusant via le pipeline de déploiement ; la flotte est mise à jour par remplacement contrôlé, sans patcher les instances existantes
• Les Auto Scaling Groups (ASG) utilisent AWS Instance Refresh, et les flottes de workers Kubernetes utilisent Karpenter
• Les services ayant des besoins de déploiement spécifiques peuvent ajouter des exécuteurs séparés, Gondola unifiant ces différents modèles dans une expérience de déploiement cohérente

• Chemin de correctif d’urgence

  • En situation d’urgence, des changements de configuration limités peuvent être appliqués à des instances en cours d’exécution, mais ces instances doivent ensuite être remplacées via le pipeline de déploiement normal
  • Des documents prédéfinis AWS Systems Manager exécutent des recipes Chef sélectionnées pour appliquer un correctif d’urgence
  • Une fois le système stabilisé, les instances sont recyclées afin de revenir à l’état immuable prévu

Déploiements progressifs de Gondola

• Les pipelines client peuvent être composés de plusieurs étapes adaptées aux besoins du service et de l’exploitation
• Chaque étape Gondola représente une unité de déploiement, comme un ASG, un cluster Kubernetes ou un groupe d’instances EC2
• L’Egress Team place des ASG canary et production séparés dans chaque zone de disponibilité, et organise les étapes pour que les mises à jour se propagent séquentiellement
• Gondola surveille les métriques clés pendant la mise à jour de chaque étape et effectue un rollback automatique si un problème est détecté, empêchant la propagation des incidents

• Artefacts de déploiement et exécuteurs

  • Le package de déploiement créé par Gondola comporte deux parties
    • L’AMI à déployer sur la flotte
    • L’artefact Chef contenant des recipes versionnées liées à un commit Git
  • Ces deux éléments sont traités comme une seule unité de déploiement, et chaque étape est déployée via l’exécuteur défini par le service
  • Pour un déploiement ASG, l’exécuteur met à jour le launch template avec la nouvelle AMI et la nouvelle configuration
  • Le code Chef est packagé dans Amazon S3
  • Le bootstrapper intégré de la nouvelle instance récupère le bon artefact et exécute les recipes pertinentes
  • Les métadonnées de configuration permettent de n’appliquer que les paramètres adaptés à ce rôle
  • Dans les flottes de workers Kubernetes, l’exécuteur transmet à Karpenter l’AMI à utiliser ainsi que les mêmes métadonnées de configuration, et les nœuds sont bootstrappés de la même manière
  • Même lorsque des exécuteurs sont ajoutés pour des déploiements spéciaux, le modèle reste le même : AMI, artefact de configuration versionné et bootstrap basé sur les métadonnées

Partage des responsabilités entre équipes plateforme et équipes service

• Les équipes Compute, Security et Monitoring gèrent les composants d’infrastructure globaux de la couche de base, les correctifs de sécurité et les paramètres obligatoires
• Les équipes service construisent par-dessus cette base des AMI qui ajoutent leurs propres logiciels et paramètres propres au service
• Quand l’équipe Compute déploie un correctif de sécurité, un agent de monitoring ou un changement réseau, les équipes service doivent intégrer l’image de base mise à jour dans leurs propres AMI
• Ce modèle de responsabilité partagée préserve l’autonomie des services tout en maintenant la cohérence, la sécurité et la fiabilité de la flotte

Une exception aux infrastructures totalement immuables : les secrets

• Les packages et la configuration des instances Shipyard sont majoritairement figés au moment du baking, mais les secrets font exception
• Le service Consul Template de chaque instance déploie les nouveaux secrets depuis Vault sans remplacer la flotte
• Comme les identifiants et certificats peuvent être renouvelés dynamiquement, Shipyard est une infrastructure semi-immuable où seuls les systèmes cœur et la couche service sont figés
• Cela permet de maintenir la stabilité et la prévisibilité tout en mettant à jour les secrets d’exécution critiques lorsque nécessaire

Politique de remplacement de The Reaper

• The Reaper détermine les instances à remplacer à partir de deux types d’entrées
  • Des signaux de contamination envoyés par des systèmes externes, comme des outils de sécurité ou des événements AWS EC2, indiquant qu’une instance s’écarte de l’état souhaité
  • Des contrôles périodiques vérifiant si l’instance fonctionne depuis plus longtemps que la durée de vie maximale autorisée
• Si l’une de ces conditions est remplie, le remplacement de l’instance est planifié selon la politique du service
• L’accès distant manuel est autorisé pour les urgences, mais une connexion directe à un nœud de niveau production génère un signal qui marque l’instance comme future candidate au remplacement
• En s’intégrant à Peekaboo, il suit l’âge des instances dans toute la flotte ; les nœuds ayant atteint leur durée de vie maximale suivent la même procédure d’arrêt propre et de remplacement
• À l’avenir, Slack prévoit d’ajouter une prise en compte du contexte afin que seules les modifications significatives, comme les mises à jour logicielles ou le drift de configuration, déclenchent un remplacement, tandis que les opérations en lecture seule ou à faible risque n’entraînent pas de rotation inutile

• Vitesse de remplacement et contrôles d’urgence

  • Des limites de débit intégrées définissent le nombre d’instances pouvant être remplacées simultanément par service, région et zone de disponibilité, afin d’éviter un impact soudain sur la capacité
  • Un mécanisme global de pause, le “big red button”, place un objet de contrôle dans S3 pour interrompre toute activité de Reaper en cas d’incident ou pendant une période à risque élevé
  • La CLI permet de gérer les limites de débit, de vérifier la configuration, et d’activer ou désactiver la pause globale
  • Dans les situations break-glass nécessitant une investigation approfondie, des méthodes d’accès contrôlées comme des certificats SSH à courte durée de vie peuvent être utilisées

Tests d’infrastructure réelle avec Ship Quick

• Ship Quick est un workflow développeur qui permet aux équipes plateforme et aux propriétaires de services d’exécuter des tests réalistes de baking et de provisioning sur une infrastructure réelle avant de merger une pull request
• Les développeurs exécutent une commande CLI depuis le dépôt de cookbooks et définissent les cas de test dans un fichier YAML
• Ship Quick procède dans l’ordre suivant
  • Il package le cookbook et l’upload dans S3
  • Il envoie un message de workflow dans une file
  • Une instance worker gérée par Longshoremen récupère la tâche
  • Le worker est détaché de l’Auto Scaling Group et exécute le workflow Chef
  • Les logs sont streamés vers la CLI, puis l’instance se termine ; le développeur peut aussi choisir de la conserver pour débogage

• Flottes de workers par couche de base

  • En raison de la structure de bootstrap, deux flottes de workers distinctes sont exploitées
  • La flotte Ubuntu de base bake et teste l’image de base depuis une AMI Ubuntu propre, car slack-zero ne peut pas être construit au-dessus de lui-même
  • La flotte slack-zero teste les cookbooks des équipes service qui dépendent d’un slack-zero déjà baké
  • Elle valide le provisioning sur la même base qu’en production
  • Elle est continuellement mise à jour avec les dernières images pour refléter l’environnement de production actuel
  • Les deux flottes scalent automatiquement selon la demande
  • Les équipes qui créent des images dans leur propre compte AWS peuvent configurer une flotte de workers dédiée et envoyer les tâches Ship Quick vers cette flotte pour préserver l’isolation

Extension aux workloads longue durée

• Shipyard fonctionne actuellement efficacement pour les services à courte durée de vie, et Slack continue d’onboarder les équipes de la plateforme EC2 legacy
• Le prochain défi concerne les instances longue durée qui ne peuvent pas être recyclées rapidement
  • Nœuds de données Slack
  • Services singleton comme GitHub Enterprise
  • Instances de technologies business tierces comme Atlassian JIRA
• Ces workloads nécessitent des méthodes sûres de patch et de mise à jour, ainsi que des politiques de cycle de vie que The Reaper puisse gérer correctement
• Slack travaille avec les équipes service au développement d’exécuteurs pour workloads longue durée pour Gondola, et prévoit de continuer à améliorer les outils, les workflows développeur et l’expérience de déploiement à mesure que l’adoption s’étend
• Slack prévoit d’aborder séparément à l’avenir l’API Shipyard, les pipelines d’images, les workflows développeur, les composants du système d’inventaire et les problèmes rencontrés lors de l’extension de la plateforme