Blog

De l'IRL à l'IAC : votre environnement vers PagerDuty via Terraform

par Murs de Mandi 2 mai 2024 | 9 minutes de lecture

Introduction

Comprendre comment représenter votre environnement tel que construit dans PagerDuty peut être déroutant pour les nouveaux utilisateurs. PagerDuty comporte de nombreux composants qui aideront votre équipe à gérer efficacement les incidents, à s'intégrer aux autres systèmes de votre environnement, à exécuter des workflows et à utiliser l'automatisation. Votre organisation peut en compter de nombreux : utilisateurs, équipes, services, intégrations, orchestrations, etc.

Pour gérer des environnements PagerDuty plus grands ou plus complexes de manière programmatique, nous vous recommandons d'utiliser L'infrastructure en tant que code des outils comme Terraform ou Pulumi Les deux solutions proposent des fournisseurs PagerDuty . Dans cet exemple, nous examinerons Terraform et vous pourrez trouvez leur fournisseur PagerDuty ici . (Nous examinerons Pulumi dans un prochain article.) Si vous êtes nouveau sur Terraform, HashiCorp a de la documentation pour vous aider à démarrer et il existe de nombreuses excellentes vidéos d'introduction sur YouTube, y compris ce tutoriel de TechWorld avec Nana .

Démarrer avec PagerDuty est un processus prescriptif. Certaines structures doivent être créées dans un ordre précis lors de la création d'un compte, et des étapes dans l'interface web vous guideront. Pour les exemples ci-dessous, nous partons du principe que vous possédez un compte PagerDuty et que vos utilisateurs sont déjà inscrits. Pour plus d'informations sur la prise en main de PagerDuty, consultez notre formation en ligne : Université PagerDuty .

Objectifs

Pour cette incursion dans Terraform, je suppose qu'un environnement de production est déjà en place. J'utiliserai les services inclus dans GCP. microservices-démo Ce projet me permettra de travailler avec un outil concret. Cette démo est suffisamment complexe pour créer des services, des dépendances et des intégrations ! Le diagramme de services du fichier README sera utile pour définir les services et leurs relations.

Une fois terminé, je souhaite disposer d'un ensemble complet de services reproduisant l'environnement de démonstration des microservices, avec des dépendances définies. Chaque service disposera également d'un point de terminaison d'intégration générique défini pour recevoir des alertes.

Tu peux voir tout le code de cet exemple sur mon compte GitHub .

Informations de base dont vous aurez besoin

Je vais inclure les membres de mon équipe comme données locales dans mes fichiers Terraform. Si votre équipe utilise déjà Terraform, vous utilisez peut-être des modules de données ou des fichiers locaux pour stocker les données, et c'est tout à fait possible. Si vous prévoyez d'utiliser Terraform pour gérer les utilisateurs, consultez la documentation du fournisseur. pagerduty_user .

Pour inclure vos utilisateurs en tant que données locales, vous n'aurez besoin que de leurs identifiants d'utilisateur.

Ordre des ressources

Une fois qu'un compte PagerDuty compte des utilisateurs, l'étape suivante consiste à créer au moins un planning et une politique d'escalade. Nous le faisons avant de créer un service, car une politique d'escalade est indispensable à sa création. Vous pouvez créer une nouvelle politique d'escalade pour chaque service, mais je vais la créer explicitement. Chaque politique d'escalade comprend au moins un planning. Vous pouvez également créer des politiques d'escalade individuelles.

Horaires et politiques d'escalade

Voici à quoi ressemble l'un de mes plannings, y compris les données locales des membres de l'équipe, en utilisant le pagerduty_schedule ressource:

 locaux   { 
       dbre_team     =   ['PC6K5C9',   [PULO4NW] 
       équipe_de_démo     =   « POJW28N » 
       app_team =   ['PC6K5C9',   'PULO4NW',   [P73R26T] 
 } 

 ressource   « pagerduty_schedule »   « msd_apps_sched »   { 
       nom         =   'Application   Équipe   Microservices   Démo' 
       fuseau horaire     =   'Amérique/New_York' 
       équipes         =   [local.demo_team] 
       couche   { 
           nom                             =   'Application   Développeurs' 
         commencer                             =   '2024-01-01T00:08:00-05:00' 
           rotation_virtual_start           =   '2024-01-01T00:08:00-05:00'  
           rotation_tour_longueur_secondes     =   604800 
           utilisateurs                             =   local.app_team 
       } 
 } 

Seuls quelques arguments sont nécessaires : le fuseau horaire (voir le Documentation de l'API PagerDuty pour les zones prises en charge) ; et au moins un couche qui nécessite commencer , rotation_virtual_start , rotation_tour_longueur_secondes , et utilisateurs .

Vous pouvez également inclure des restrictions et d’autres fonctionnalités dans vos horaires. Consultez la documentation du fournisseur pour plus d'informations .

Je peux alors me référer à cela pagerduty_schedule ressource lorsque je crée ma politique d'escalade, en utilisant le politique d'escalade des droits de page ressource:

 ressource   « pagerduty_escalation_policy »   « msd_apps »   { 
       nom         =   'Application   Équipe   Microservices   Démo' 
       nombre_boucles   =   1 
       équipes       =   [local.demo_team] 
       règle   { 
         escalade_delay_in_minutes   =   10 
           cible   { 
               taper   =   « référence_horaire » 
               identifiant     =   pagerduty_schedule.msd_apps_sched.id 
           } 
       } 
 } 

Le politique d'escalade des droits de page la ressource n'a également que quelques exigences : une nom et un ou plusieurs règle blocs qui contiennent escalade_delay_in_minutes et un cible . Le cible nécessite un identifiant , c'est là que je l'ai lié au calendrier que j'ai défini ci-dessus : pagerduty_schedule.msd_apps_sched.id .

Services

Maintenant que j'ai une politique d'escalade, je peux créer mes services. Consultez la documentation relative à la démonstration de microservices , il y a 12 services potentiels dans l'environnement. Je vais laisser de côté générateur de charge Je vais donc créer 11 services techniques adaptés à l'environnement. Je vais également en créer un. services aux entreprises pour représenter l'ensemble de l'environnement de démonstration dans mon graphique de service .

J'utilise la configuration la plus basique pour mes services. Vous pouvez consulter la documents du fournisseur pour tous les arguments de ressources. Je peux toujours modifier mes services ultérieurement avec Terraform si besoin est.

Les services ne nécessitent en réalité qu'un nom , et un politique d'escalade . Le création_d'alerte L'argument est obsolète au moment de la rédaction de cet article, le nouveau paramètre étant créer_des_alertes_et_des_incidents Pour tous les services, vous n'en aurez peut-être pas besoin dans votre code. Je vais commencer par créer tous mes services de la même manière, ils ressembleront donc tous à ceci :

 #   Redis   Cache 
 ressource   « pagerduty_service »   « Demo_Redis_Cache »   { 
       nom                 =   'Redis   Cache   -   Microservices   Démo' 
       politique d'escalade   =   pagerduty_escalation_policy.msd_dbre.id 
       création_d'alerte       =   « créer_des_alertes_et_des_incidents » 
 } 

 #   Achats   Panier 
 ressource   « pagerduty_service »   'Demo_Cart'   { 
       nom                 =   'Achats   Panier   -   Microservices   Démo' 
       politique d'escalade   =   pagerduty_escalation_policy.msd_apps.id 
       création_d'alerte       =   « créer_des_alertes_et_des_incidents » 
 } 

 

Parce que mon politique d'escalade les ressources ont été créées avec Terraform, je peux inclure leurs identifiant s Directement via la référence de ressource. Je peux également utiliser différentes politiques d'escalade pour chaque service si je le souhaite, mais ici, je n'en ai créé que deux : une pour l'équipe DBRE et une pour l'équipe Application.

Comme je l'ai mentionné ci-dessus, je vais également créer un services aux entreprises Pour représenter la pile applicative dans son ensemble. Les services métier aident les autres services de mon organisation à identifier les incidents impactant les applications destinées aux utilisateurs, et ceux-ci apparaîtront sur la page du graphique des services. On peut considérer le service métier comme représentant Utilisateur sur le diagramme d'environnement d'origine !

Le service_d'entreprise_pagerduty La ressource ressemble un peu à la ressource pour les services techniques, mais elle n'a pas de ressource associée. politique d'escalade :

 ressource   « pagerduty_business_service »   « Microservices_Démo »   { 
       nom           =   « Microservices »   Démo' 
       description   =   'Services   aligné   derrière   le   En ligne   Boutique   Démo' 
       équipe           =   équipe_de_démo_locale 
 } 

 

Il n'y a que quelques arguments supplémentaires disponibles pour le service_d'entreprise_pagerduty ressource, vous pouvez les voir dans le documents du fournisseur .

Dépendances de service

Une fois que j'ai défini tous les services de mon environnement, je peux ajouter leurs relations en utilisant dépendances de service Les dépendances aideront mon équipe à déterminer l’impact potentiel des incidents sur les services.

Chaque dépendance doit être définie individuellement comme une relation entre un service_dépendant et un service_de_soutien . En utilisant la convention du diagramme graphique dans le fichier README de la démonstration des microservices, un service_dépendant sera avant tout de son service_de_soutien s , mais ci-dessous tous les services qui en dépendent. Je vais également créer une dépendance entre L'extrémité avant service et mon Démo de microservices service aux entreprises.

La ressource suivante crée la dépendance entre mon L'extrémité avant et Vérifier services:

 ressource   « pagerduty_service_dependency »   'fe_to_checkout'   { 
       dépendance   { 
           service_dépendant   { 
               identifiant     =   pagerduty_service.Demo_Frontend.id 
               taper   =   pagerduty_service.Demo_Frontend.type 
           }            service_de_soutien   { 
               identifiant     =   pagerduty_service.Demo_Checkout.id 
               taper   =   pagerduty_service.Demo_Checkout.type 
           } 
       } 
 } 

Je peux me référer au identifiant et taper caractéristiques de ces services puisqu'ils ont tous deux été créés avec Terraform.

La dépendance qui lie le service métier à mes services techniques semble légèrement différente en raison de la service_d'entreprise_pagerduty ressource:

 ressource   « pagerduty_service_dependency »   'biz_to_fe'   { 
       dépendance   { 
           service_dépendant   { 
               identifiant     =   pagerduty_business_service.Microservices_Demo.id 
               taper   =   pagerduty_business_service.Microservices_Demo.type 
           } 
           service_de_soutien   { 
               identifiant     =   pagerduty_service.Demo_Frontend.id 
               taper   =   pagerduty_service.Demo_Frontend.type 
           } 
       } 
 } 

Une fois toutes mes dépendances de service définies, je peux utiliser l'interface utilisateur Web pour les comparer au diagramme de topologie d'application d'origine, tel qu'il figure dans le fichier README. Je peux déplacer les objets sur le graphique pour les aligner comme l'original :

PagerDuty web UI screen capture of the service graph representation of this environment. It is oriented with the business service “Microservices Demo” at the top and the technical service “Redis Cache” at the bottom. Technical services are represented with circles with green checks in them to represent the OK status of the services. The business service also has a green check but is represented by a square. The relationships among the services are represented by blue lines.

Intégrations

Enfin, je souhaite activer tous mes services pour recevoir des alertes. Il existe de nombreux types d'alertes. intégrations qui peut être configuré sur les services PagerDuty , mais je vais commencer par une configuration de base API d'événements v2 intégration pour chaque service. Vous trouverez plus d'informations sur la définition d'autres types d'intégration, notamment les intégrations de messagerie et le référencement de services spécifiques. vendeurs , dans le documents du fournisseur .

 ressource   « pagerduty_service_integration »   'events_msd_frontend'   { 
     nom       =   'API   V2' 
     taper       =   « events_api_v2_inbound_integration » 
     service     =   pagerduty_service.Demo_Frontend.id 
 } 

Prochaines étapes

Maintenant que mes services sont définis dans PagerDuty et qu'ils disposent tous d'intégrations pour recevoir des événements, je suis prêt à utiliser les fonctionnalités de base. Je peux également utiliser ces ressources de base pour intégrer des solutions utiles, comme orchestrations d'événements et actions d'automatisation ainsi que des intégrations plus sophistiquées pour répondre aux besoins de mon équipe.

Pour obtenir les dernières informations sur le fournisseur PagerDuty Terraform, consultez toujours le documentation du fournisseur Notre mainteneur, José Antonio Reyes, présente Terraform Time sur le PagerDuty Twitch Le mercredi à 16 h (heure de l'Est), nous organisons une table ronde trimestrielle. Pour toute question, n'hésitez pas à nous contacter à l'adresse suivante : community-team@pagerduty.com .