Comment implémenter Opsgenie Terraform 2026

Introduction

Opsgenie, solution Atlassian pour la gestion d'incidents, excelle dans les environnements SRE avancés grâce à ses API REST et son provider Terraform officiel. En 2026, avec la maturité de l'IaC, provisionner des équipes, politiques d'alerte, intégrations (Prometheus, Slack) et heartbeats via code devient standard pour scaler sans erreurs manuelles.

Ce tutoriel avancé vous guide pas à pas pour implémenter une configuration Opsgenie complète : du setup Terraform à la création de ressources productisables. Imaginez comme un circuit électrique : le provider est la source, les ressources les composants interconnectés. Résultat ? Une stack reproductible, auditable et versionnée, réduisant les MTTR de 40% en prod. Idéal pour les équipes gérant 100+ alertes/jour. Prêt à transformer vos on-call en machine bien huilée ? (128 mots)

Prérequis

Compte Opsgenie Enterprise (trial OK pour tests)
Terraform 1.9+ installé
API token Opsgenie (généré via UI > Settings > API Key Integrations)
Connaissances avancées en HCL/Terraform et REST API
Outils : curl, Git pour versionning

Installer le provider Terraform Opsgenie

main.tf

terraform {
  required_providers {
    opsgenie = {
      source  = "registry.terraform.io/atlassian/opsgenie"
      version = "~> 0.4.0"
    }
  }
}

provider "opsgenie" {
  api_key = var.opsgenie_api_key
}

variable "opsgenie_api_key" {
  type        = string
  description = "API key Opsgenie"
  sensitive   = true
}

variable "team_name" {
  type    = string
  default = "SRE-Team"
}

Ce bloc initialise le provider Atlassian Opsgenie, version stable 2026. La variable api_key est sensible pour la sécurité CI/CD. Définissez-la via terraform.tfvars ou env var TF_VAR_opsgenie_api_key. Évitez les hardcodings : un leak expose toutes vos ressources.

Provisionner une équipe SRE

Pourquoi une équipe d'abord ? Opsgenie route les alertes via équipes, comme un hub central. Post-provisioning, assignez users et schedules.

Créer l'équipe et un utilisateur

team.tf

resource "opsgenie_team" "sre_team" {
  name        = var.team_name
  description = "Équipe SRE pour incidents critiques"
  members {
    id = opsgenie_user.sre_oncall.id
  }
}

resource "opsgenie_user" "sre_oncall" {
  username   = "oncall@example.com"
  full_name  = "SRE On-Call"
  role       = "owner"
  source     = "email"
}

L'équipe SRE intègre un user on-call via ID dynamique. Le rôle 'owner' donne droits admin. Piège : sans depends_on, l'ordre de création échoue ; Terraform gère via références implicites, mais testez avec plan.

Configurer une intégration Prometheus

Les intégrations capturent alertes externes. Prometheus push via webhook Opsgenie : filtrez par severity pour éviter alert fatigue.

Ajouter intégration API générique

integration.tf

resource "opsgenie_team_integration" "prometheus" {
  team_id = opsgenie_team.sre_team.id
  type    = "Prometheus"
  name    = "Prometheus Alerts"
  is_enabled = true

  prometheus_config {
    endpoint {
      method = "POST"
      uri    = "/v2/alerts/prometheus"
    }
  }

  filter {
    type  = "match-all"
    order = 1
  }
}

Intégration Prometheus native : endpoint v2 pour alertes riches (labels, annotations). Le filtre 'match-all' route tout ; raffinez avec conditions pour prod. Vérifiez is_enabled pour activer sans downtime.

Déclencher une alerte via API

create-alert.sh

#!/bin/bash
API_KEY="your-api-key-here"
TEAM_ID="$(terraform output team_id)"

curl -X POST "https://api.opsgenie.com/v2/alerts" \
  -H "Authorization: GenieKey $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "CPU > 90% sur prod-app",
    "alias": "cpu-high-prod",
    "description": "Métrique Prometheus: cpu_usage=95%",
    "teams": ["'$TEAM_ID'"],
    "priority": "P2",
    "tags": ["prometheus", "cpu"],
    "details": {
      "host": "app-01",
      "value": 95
    }
  }'

Script bash fonctionnel pour tester : route alerte vers équipe Terraform. Utilisez alias pour idempotence (supprime doublons). Remplacez vars ; en prod, intégrez à webhook Prometheus. Piège : sans teams, alerte orpheline.

Définir une politique d'escalation

Politiques avancées : Round-robin sur schedules, delay conditionnel. Analogie : comme un relais de course, passe la baton si non résolu.

Politique d'alerte avec escalations

policy.tf

resource "opsgenie_notification_policy" "sre_policy" {
  team_id     = opsgenie_team.sre_team.id
  name        = "SRE Escalation Policy"
  description = "Escalade P1 après 5min"
  is_default  = false

  policy_v2_rule {
    type     = "source"
    key      = "teams"
    is_block = false
    value_v2 {
      type  = "contains"
      value = var.team_name
    }
  }

  notify {
    id            = opsgenie_notification_rule.escalation.id
    delay_in_min  = 5
    condition     = "If not acknowledged"
  }
}

resource "opsgenie_notification_rule" "escalation" {
  name      = "Escalade On-Call"
  direction = "RR"
  notify {
    id   = opsgenie_user.sre_oncall.id
    type = "users"
  }
}

Policy V2 filtre par équipe, notifie via round-robin après delay. condition prévient escalades inutiles. Complexité : dépendances circulaires évitées par refs explicites ; appliquez terraform apply itératif.

Configurer un heartbeat

heartbeat.tf

resource "opsgenie_heartbeat" "sre_heartbeat" {
  name        = "SRE Prod Heartbeat"
  description = "Vérifie connectivité Prometheus->Opsgenie"
  enabled     = true
  interval    = 60
  grace       = 300
  tags        = ["sre", "monitoring"]

  teams = [opsgenie_team.sre_team.id]

  alert_message = "Heartbeat manquant : SRE Prod down ?"
  alert_priority = "P3"
}

Heartbeat ping toutes les 60s, alerte si >5min silence (grace). Lie à équipe pour auto-escalade. En prod, script cron appelle /v2/heartbeats/{name}/ping ; Terraform gère lifecycle.

Appliquer et outputs

Exécutez terraform init && plan && apply. Outputs utiles : team_id, integration_id. Versionnez en Git, CI/CD via Atlantis.

Outputs et script d'application

outputs.tf

output "team_id" {
  value = opsgenie_team.sre_team.id
}

output "policy_id" {
  value = opsgenie_notification_policy.sre_policy.id
}

output "heartbeat_name" {
  value = opsgenie_heartbeat.sre_heartbeat.name
}

Outputs exposent IDs pour scripts/orchestration. Sensible pour GitHub Actions. Post-apply : terraform output -json pour pipelines.

Bonnes pratiques

IaC modulaire : Séparez modules.tf pour réutiliser équipes/policies.
Secrets management : Utilisez Vault/Terraform Cloud, jamais tfvars en repo.
State backend : S3 + DynamoDB pour collab multi-devs.
Tests : terratest pour valider alertes post-apply.
Drift detection : plan hebdo en cron pour détecter UI changes.

Erreurs courantes à éviter

API key périmée : Regen via UI, pas rétroactif ; terraform refresh.
Limites rate : 100 req/min ; batch via count/for_each.
Policy V1 vs V2 : V2 obligatoire 2026 ; migratez legacy.
No depends_on : Ajoutez explicitement pour users->teams.

Pour aller plus loin

Approfondissez avec Terraform Registry Opsgenie. Intégrez PagerDuty hybrid. Découvrez nos formations Learni DevOps pour SRE certifiant. Lisez docs Atlassian 2026 sur Webhooks avancés.

Comment implémenter Opsgenie avec Terraform en 2026