Dans un article de blog récent, Ingénierie Slack a détaillé des améliorations significatives de son Cuisinier infrastructure. Celui-ci gère des dizaines de milliers d’instances EC2 exécutant ses services, bases de données et applications, et est récemment passé d’une pile Chef unique à une infrastructure fragmentée plus résiliente.
En passant à une nouvelle architecture, Slack espérait résoudre un certain nombre de limitations, à savoir les domaines suivants qui s’avéraient difficiles avec la configuration précédente :
- Attribuer une partition à un nœud
- Découverte du quartier
- Recherche de chef
- Téléchargements de livres de recettes
Dans sa configuration précédente, Slack avait un seul Pile de chef dans trois environnements : Sandbox, Développement et Production. Cette architecture présentait des risques car les modifications étaient déployées simultanément dans les environnements, et tout problème avec la pile pouvait avoir un impact sur l’ensemble de leur infrastructure. Le système utilisait un processus nommé DishPig pour gérer les mises à jour des livres de recettes, qui étaient déclenchées toutes les heures.
L’équipe d’ingénierie a apporté un certain nombre de modifications clés pour remédier à ces limitations. Tout d’abord, ils ont créé plusieurs piles Chef pour répartir la charge et garantir la résilience du système. Les nouvelles instances sont attribuées à des partitions spécifiques à l’aide des enregistrements CNAME pondérés AWS Route53. L’équipe a également séparé l’infrastructure Chef de développement et de production en piles distinctes.
Pour résoudre le défi de la découverte de nœuds dans la nouvelle infrastructure partitionnée, l’équipe a commencé à utiliser Consul pour la découverte de services. Cela nécessitait une mise en œuvre minutieuse pour éviter les dépendances circulaires avec leur réseau de superposition Nebula. L’équipe a développé des fonctions de bibliothèque Chef personnalisées pour faciliter les recherches de nœuds basées sur divers critères, remplaçant ainsi leur précédente fonctionnalité de recherche Chef.
La société a également créé un nouveau service appelé Shearch (Sharded Chef Search) pour maintenir la possibilité de rechercher sur plusieurs piles Chef. Ce service consolide les résultats des requêtes exécutées sur différentes partitions. Ils ont également développé un nouvel outil nommé Gnife pour remplacer la commande traditionnelle Chef Knife, permettant des opérations sur plusieurs fragments.
L’équipe a remplacé le système DishPig par Chef Librarian. Ce service gère indépendamment la gestion des versions des livres de recettes et les mises à jour de l’environnement, permettant des déploiements plus contrôlés. Lorsque les modifications sont fusionnées, GitHub Actions crée une archive tar avec une copie complète du référentiel et les versions du livre de recettes sont mises à jour à l’aide d’un format basé sur l’horodatage (AAAAMMJJ.TIMESTAMP.0).
Chef Librarian fournit des points de terminaison d’API pour mettre à jour les environnements vers des versions spécifiques et faire correspondre les environnements les uns aux autres. L’utilisation de Chef Librarian a permis à Slack de tester les modifications dans les environnements sandbox et de développement avant de les promouvoir en production, réduisant ainsi le risque de modifications problématiques affectant simultanément tous les environnements. Le service stocke les versions des artefacts et les informations de déploiement dans DynamoDB pour un meilleur suivi et une meilleure visibilité.
Une application Slack informe les utilisateurs lorsque leurs modifications sont promues dans un environnement, en utilisant les informations de validation Git pour identifier et marquer les membres appropriés de l’équipe. Un CronJob Kubernetes gère la promotion des versions dans tous les environnements, avec des contrôles de sécurité pour empêcher les promotions si des problèmes sont détectés.
Slack a minimisé les risques pour les rôles de chef (qui ne peuvent pas être versionnés) en les réduisant aux informations de base et aux listes d’exécution. Les rôles ne sont téléchargés sur les piles Chef pertinentes que lorsque leurs environnements correspondants sont mis à jour.
Slack envisage de nouvelles améliorations de son infrastructure Chef. Une possibilité consiste à segmenter les environnements de production Chef par zones de disponibilité AWS, ce qui permettrait un contrôle plus granulaire sur le déploiement des modifications. Ils explorent également l’adoption de Chef PolicyFiles et PolicyGroups, bien que cela représenterait un changement important par rapport à leur configuration actuelle.
La popularité de Chef a diminué par rapport à son apogée du milieu des années 2010, potentiellement en raison de la montée en puissance d’outils alternatifs tels qu’Ansible et d’autres solutions cloud natives. L’évolution de l’industrie vers la conteneurisation a modifié la façon dont de nombreuses organisations ont abordé la gestion de la configuration, nombre d’entre elles ayant plutôt adopté Docker et Kubernetes. L’acquisition de l’outil par Progress Software en 2020 peut également avoir influencé son adoption à long terme.
Cependant, Chef maintient une base d’utilisateurs solide, en particulier parmi les organisations disposant déjà d’implémentations de Chef ou de cas d’utilisation spécifiques bien adaptés à l’approche de Chef.
