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 avec succès les incidents, à s'intégrer à d'autres systèmes de votre environnement, à exécuter des flux de travail et à utiliser l'automatisation. Votre organisation peut comporter un grand nombre de ces composants : 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 disposent de 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 vidéos d'introduction intéressantes 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 particulier lors de la création d'un nouveau compte, et il y aura des étapes dans l'interface utilisateur Web pour vous guider. Pour les exemples ci-dessous, je suppose que vous disposez d'un compte PagerDuty et que vos utilisateurs sont déjà intégrés. Pour plus d'informations sur la façon de démarrer avec PagerDuty, assurez-vous de consulter notre apprentissage en ligne sur Université PagerDuty .

Objectifs

Pour cette incursion dans Terraform, je vais supposer qu'un environnement de production est déjà en cours d'exécution. Je vais utiliser les services inclus dans GCP microservices-démo projet pour me donner quelque chose avec quoi travailler. Il y a suffisamment de complexité dans cette démo pour créer des services, des dépendances et des intégrations ! Le diagramme de service dans le fichier README sera utile pour définir les services et leurs relations.

Une fois terminé, je souhaite disposer d'un ensemble complet de services imitant 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 afin de pouvoir 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 en tant que 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 conserver les données, et c'est également très bien. Si vous envisagez d'utiliser Terraform pour gérer les utilisateurs, consultez la documentation du fournisseur pour 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, les étapes suivantes consistent à créer au moins une stratégie de planification et d'escalade. Nous faisons cela avant de créer un service, car avoir une politique d'escalade est une condition nécessaire pour créer un service. Vous pouvez créer une nouvelle politique de remontée d'informations pour chaque service, mais je vais créer explicitement mes politiques de remontée d'informations. Chaque politique d’escalade comporte au moins un calendrier inclus. Vous pouvez également créer des politiques de remontée d’informations avec des individus.

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:

 des locaux   { 
       équipe_dbre     =   ['PC6K5C9',   ['PULO4NW'] 
       équipe_de_démo     =   'POJW28N' 
       équipe_application =   ['PC6K5C9',   'PULO4NW',   ['P73R26T'] 
 } 

 Ressource   « pagerduty_schedule »   'msd_apps_sched'   { 
       nom         =   'Application   Équipe   Microservices   Démo' 
       fuseau horaire     =   'Amérique/New_York' 
       équipes         =   [équipe de démonstration locale] 
       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                             =   équipe_d'application_locale 
       } 
 } 

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

Vous pouvez également inclure des restrictions et d’autres fonctionnalités dans vos plannings. 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_de_boucles   =   1 
       équipes       =   [équipe de démonstration locale] 
       règle   { 
         escalade_delay_in_minutes   =   dix 
           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 planning que j'ai défini ci-dessus : pagerduty_schedule.msd_apps_sched.id .

Prestations de service

Maintenant que j'ai une politique d'escalade, je peux créer mes services. En regardant la documentation de la démonstration de microservices , il y a 12 services potentiels dans l'environnement. Je vais laisser de côté le générateur de charge service, je vais donc créer 11 services techniques pour correspondre à l'environnement. Je vais également en créer un Service d'affaires 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 plus tard avec Terraform si j'ai besoin de changer ou d'ajouter quelque chose.

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 donc peut-être pas besoin dans votre code. Je vais créer tous mes services de la même manière pour commencer, ils ressembleront donc tous à ceci :

 #   Redis   Cache 
 Ressource   'pagerduty_service'   'Démo_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   Chariot 
 Ressource   'pagerduty_service'   'Démo_Panier'   { 
       nom                 =   'Achats   Chariot   -   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 les inclure identifiant m 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 Service d'affaires pour représenter la pile d'applications dans son ensemble. Les services métier aident les autres parties de mon organisation à identifier les incidents qui ont un impact sur les applications destinées aux utilisateurs, et ils apparaîtront sur la page Service Graph. Vous pouvez considérer le service métier comme représentant la pile d'applications dans son ensemble. 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 politique_d'escalade :

 Ressource   'pagerduty_business_service'   « Microservices_Démo »   { 
       nom           =   « Microservices   Démo' 
       description   =   'Prestations de service   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 démonstration des microservices, un service_dépendant sera avant tout de son service_de_soutien m , mais ci-dessous tous les services qui en dépendent. Je vais également créer une dépendance entre le L'extrémité avant service et mon Démonstration des microservices Service d'affaires.

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

 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 à la 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 du fichier README. Je peux déplacer les objets sur le graphique pour les aligner comme l'original :

Intégrations

Enfin, je souhaite permettre à tous mes services de 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 un basique API d'événements v2 intégration pour chaque service. Vous pouvez trouver plus d'informations sur la façon de définir d'autres types d'intégrations, y compris les intégrations de messagerie et le référencement de services spécifiques vendeurs , dans le documents du fournisseur .

 Ressource   « pagerduty_service_integration »   'événements_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 ont tous des 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 telles que 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 à 16h00, heure de l'Est, et organise une table ronde trimestrielle. Si vous avez d'autres questions, nous serions ravis de vous aider ! Vous pouvez nous contacter à équipe-communautaire@pagerduty.com .