Il s’agit du premier article d’une série en plusieurs parties sur certains des défis opérationnels que l’équipe de PagerDuty résout.

Chez PagerDuty , nous visons une haute disponibilité à chaque couche de notre pile. Nous y parvenons en développant des logiciels résilients qui s'exécutent ensuite sur une infrastructure résiliente. Nous en tenons compte lors de la conception de l'automatisation de notre infrastructure. Nous partons du principe que des éléments tomberont en panne et qu'il faudra les remplacer ou les reconstruire rapidement.

Dans ce premier article consacré à notre équipe d'ingénierie opérationnelle, nous aborderons la manière dont nous automatisons notre infrastructure grâce à Chef, un outil de gestion de configuration hautement extensible, basé sur Ruby et piloté par la recherche, ainsi que les pratiques que nous avons apprises. Nous aborderons également notre flux de travail habituel et comment nous garantissons le déploiement en toute sécurité d'une nouvelle infrastructure résiliente et prévisible.

L'équipe

Avant d'entrer dans les détails techniques, commençons par un peu de contexte concernant l'équipe qui se cache derrière cette magie. Notre équipe d'ingénierie opérationnelle chez PagerDuty est actuellement composée de quatre ingénieurs. L'équipe est responsable de plusieurs domaines : l'automatisation de l'infrastructure, la sécurité au niveau de l'hôte, la persistance/les magasins de données et les outils de productivité. L'équipe est composée de généralistes, chacun ayant un ou deux domaines de spécialisation. Si l'équipe d'ingénierie opérationnelle dispose de sa propre rotation d'astreinte PagerDuty , chaque équipe d'ingénieurs de PagerDuty participe également aux astreintes.

Le matériel

Nous possédons actuellement plus de 150 serveurs répartis sur plusieurs fournisseurs cloud. Ces serveurs sont répartis en plusieurs environnements (pré-production, test de charge et production) et services (serveurs d'applications, serveurs de persistance, équilibreurs de charge et serveurs de messagerie). Chacun de nos trois environnements dispose d'un serveur chef dédié pour éviter que les hôtes ne polluent les autres environnements.

Le flux de travail

La base de code du chef a 3 ans et compte environ 3,5 000 commits.

Voici le squelette de notre référentiel de chefs :

• dépôt git
  • livres de cuisine (stocke les livres de cuisine communautaires qui contiennent nos personnalisations)
  • site-coobooks (stocke nos wrappers autour des livres de cuisine communautaires, nos livres de cuisine personnalisés, lwrps, etc.)
  • data_bags (stocke tous les sacs de données qui ne sont pas chiffrés)
  • lib (bibliothèques Ruby utilisées dans les plugins site-cookbook/* et knife)
  • rôles (stocke tous les rôles)

Nous utilisons le workflow standard des branches de fonctionnalités pour notre dépôt. Une fonctionnalité peut être une tâche tactique (création d'un nouveau type de service), de maintenance (mise à niveau/correctif) ou stratégique (améliorations d'infrastructure, refactorisation à grande échelle, etc.). Les branches de fonctionnalités sont testées unitairement via Jenkins, qui surveille en permanence les modifications sur GitHub. Nous utilisons ensuite l'environnement de test pour les tests d'intégration. Les branches de fonctionnalités qui réussissent les tests sont ensuite déployées sur le serveur Chef de l'environnement de test. Cela dépend de la fonctionnalité, mais la plupart des branches font l'objet d'une revue de code via une pull request. Cette revue de code est volontairement manuelle et nous nous assurons qu'au moins un autre membre de l'équipe donne son avis positif sur le code. Si le code fait l'objet d'un débat plus large, nous bloquons du temps lors de nos réunions d'équipe pour en discuter. Ensuite, la branche de fonctionnalités est fusionnée et nous appelons notre script de restauration pour supprimer tous les livres de recettes existants du serveur Chef et télécharger tous les rôles, environnements et livres de recettes depuis le serveur principal. Généralement, le processus de restauration prend moins d'une minute. Nous ne suivons pas de calendrier de déploiement strict ; nous préférons déployer dès que possible. Sauf en cas de correctif, nous préférons effectuer les déploiements pendant les heures de bureau, lorsque tout le monde est réveillé. Nous exécutons Chef-client une fois par jour toute la semaine via cron. Si nous avons besoin d'une exécution Chef à la demande, nous utilisons pssh ou knife ssh avec un niveau de concurrence contrôlé.

Tests de chef

Tous les livres de recettes personnalisés PagerDuty ont un répertoire de spécifications qui contient des tests basés sur ChefSpec et nous avons récemment migré vers ChefSpec 3 Nous utilisons Chefspec et Rspec Les capacités de stubbing sont très étendues, car la grande majorité de nos recettes personnalisées utilisent la recherche, des sacs de données chiffrés, etc. Outre les tests unitaires spécifiques aux livres de recettes, situés dans le sous-répertoire spec de chaque livre de recettes, nous disposons d'un répertoire spec de niveau supérieur, qui contient des tests fonctionnels et unitaires. Les tests unitaires sont principalement basés sur des assertions de rôle ou d'environnement basées sur ChefSpec, tandis que les tests fonctionnels sont tous basés sur LXC et Rspec. La suite de tests fonctionnels utilise Chef Zero pour créer un serveur en mémoire, puis utilise le script de restauration et le plugin Chef Restoration Knife pour émuler un serveur de test ou de production. Nous générons ensuite des tests individuels. lxc Par rôle, en utilisant le même processus d'amorçage que nos serveurs de production. Une fois la convergence d'un nœud réussie, nous appliquons une assertion basée sur le rôle. Par exemple, une spécification fonctionnelle de Zookeeper s'exécutera localement via Telnet. « statistiques » pour vérifier si les requêtes peuvent être traitées. Ceci couvre la majeure partie de notre base de code, à l'exception de l'intégration avec les différents fournisseurs de cloud.

Gestion des livres de recettes

Nous utilisons beaucoup les livres de recettes communautaires. Nous évitons de créer des livres de recettes s'il existe une alternative open source bien gérée. Nous préférons écrire des livres de recettes wrapper avec un préfixe « pd » qui prend en compte nos personnalisations par rapport aux livres de recettes communautaires. Par exemple, pd-memcached cookbook englobe les livres de recettes communautaires memcached et fournit des iptables et d'autres personnalisations spécifiques à PagerDuty .

Les livres de cuisine communautaires ainsi que nos livres de cuisine personnalisés PagerDuty sont gérés par Berkshelf . Tous les livres de recettes personnalisés (pd-*) restent dans le répertoire site-cookbooks dans chef repo Nous utilisons plusieurs plugins Knife personnalisés. Deux d'entre eux, Chef Restore et Chef Backup, prennent en charge la sauvegarde et la restauration complètes de notre serveur Chef (nœuds, clients, bases de données). Grâce à cela, nous pouvons facilement déplacer les serveurs Chef d'un hôte à un autre. D'autres plugins Knife permettent de générer des serveurs, d'effectuer des suppressions et de vérifier l'état des services tiers.

Gagner en confiance grâce aux tests et à la prévisibilité

Actuellement, nous sommes confiants quant à notre capacité à déployer et à démanteler notre infrastructure en toute sécurité une fois les tests appropriés en place. Lorsque nous avons initialement pris une décision TDD L'approche de notre infrastructure a nécessité un apprentissage intensif pour l'équipe. Nous rencontrons encore des problèmes lorsque nous utilisons des nœuds sur plusieurs fournisseurs et que nous dépendons de configurations externes (par exemple, services de surveillance hébergés, services de gestion des journaux). Nous avons donc introduit des modes de défaillance et des exigences de sécurité supplémentaires. Nous avons répondu à ces défis en adoptant une approche agressive. mémorisation techniques, introduction d'outils d'automatisation des tests de sécurité (par exemple gant ) dans la boîte à outils des opérations (plus d'informations à ce sujet dans un prochain article).

Un défi majeur demeure la gestion des versions entre composants et la mise à jour proactive et en amont des dépendances. Certains problèmes liés à la qualité du code, issus des guides de la communauté, nous ont également freinés. Nous comprenons cependant qu'il s'agit de problèmes complexes et limités dans le temps. Nous faisons partie de la communauté chargée de les résoudre.