9 min lecture • Guide 767 of 877
Gestion de Projet Infrastructure as Code
L'Infrastructure as Code (IaC) nécessite la même rigueur que le développement applicatif. GitScrum aide les équipes à gérer le travail d'infrastructure avec des processus de revue appropriés et un suivi des changements.
Structure des Tâches Infrastructure
Format de Tâche IaC
STRUCTURE DE TÂCHE INFRASTRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TÂCHE DE CHANGEMENT INFRASTRUCTURE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INFRA-100: Ajouter cluster Redis pour caching ││
│ │ ││
│ │ QUOI: ││
│ │ Provisionner cluster ElastiCache Redis (3 nœuds) ││
│ │ ││
│ │ POURQUOI: ││
│ │ Couche de cache applicatif pour PROJ-456 ││
│ │ Supporte: Stockage session, cache réponse API ││
│ │ ││
│ │ RESSOURCES: ││
│ │ • Cluster ElastiCache (cache.r6g.large x 3) ││
│ │ • Security group ││
│ │ • Parameter group ││
│ │ • Subnet group ││
│ │ ││
│ │ IMPACT COÛT: ││
│ │ Estimé: ~400€/mois ││
│ │ Approuvé: Oui (ticket BUDGET-123) ││
│ │ ││
│ │ RAYON D'IMPACT: ││
│ │ Nouvelles ressources uniquement - pas d'impact ││
│ │ ││
│ │ ROLLBACK: ││
│ │ terraform destroy pour nouvelles ressources ││
│ │ ││
│ │ FENÊTRE DE DÉPLOIEMENT: ││
│ │ N'importe quand (pas de downtime prévu) ││
│ │ ││
│ │ CHECKLIST: ││
│ │ ☐ Code Terraform ││
│ │ ☐ Revue de code ││
│ │ ☐ Apply en staging ││
│ │ ☐ Test connectivité ││
│ │ ☐ Apply en production ││
│ │ ☐ Mise à jour documentation ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Catégories de Changements
TYPES DE CHANGEMENTS INFRASTRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RISQUE BAS (Auto-approbation OK): │
│ • Nouvelles ressources (pas d'impact existant) │
│ • Changements de tags │
│ • Augmentation de capacité │
│ • Ajout de monitoring │
│ │
│ RISQUE MOYEN (Revue par pair requise): │
│ • Changements security group │
│ • Mises à jour policies IAM │
│ • Changements de configuration │
│ • Policies de scaling │
│ │
│ RISQUE ÉLEVÉ (Plusieurs reviewers + fenêtre): │
│ • Changements base de données │
│ • Changements réseau │
│ • Opérations destructrices │
│ • Secrets production │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TÂCHE RISQUE ÉLEVÉ: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 INFRA-150: Migration vers nouveau VPC ││
│ │ ││
│ │ Risque: ÉLEVÉ ││
│ │ Downtime: Prévu (fenêtre maintenance) ││
│ │ ││
│ │ APPROBATION REQUISE: ││
│ │ ☐ Revue lead DevOps ││
│ │ ☐ Revue sécurité (changement réseau) ││
│ │ ☐ Change advisory board ││
│ │ ││
│ │ DÉPLOIEMENT: ││
│ │ ☐ Fenêtre planifiée: Samedi 2h ││
│ │ ☐ Plan rollback documenté ││
│ │ ☐ Équipe astreinte notifiée ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Workflow Terraform
Flux de Tâche Terraform
WORKFLOW DE CHANGEMENT TERRAFORM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. CRÉER TÂCHE │
│ Documenter quoi/pourquoi/impact │
│ │
│ 2. DÉVELOPPER │
│ Écrire code Terraform │
│ terraform plan localement │
│ │
│ 3. REVUE DE CODE │
│ PR avec output terraform plan │
│ Réviser les changements soigneusement │
│ │
│ 4. APPLY STAGING │
│ terraform apply en staging │
│ Vérifier fonctionnalité │
│ │
│ 5. APPLY PRODUCTION │
│ Planifié si haut risque │
│ terraform apply en production │
│ Vérifier et monitorer │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CHECKLIST PR POUR TERRAFORM: │
│ │
│ ☐ terraform fmt appliqué │
│ ☐ terraform validate passe │
│ ☐ Output plan inclus dans PR │
│ ☐ Pas de secrets dans le code │
│ ☐ Estimation coût incluse (nouvelles ressources) │
│ ☐ Documentation mise à jour │
│ ☐ Plan rollback documenté │
│ │
│ OUTPUT PLAN DANS PR: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Plan: 3 à ajouter, 1 à modifier, 0 à détruire. ││
│ │ ││
│ │ + aws_elasticache_cluster.main ││
│ │ + aws_security_group.redis ││
│ │ + aws_elasticache_subnet_group.main ││
│ │ ~ aws_security_group.app (ajout règle egress) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Travail Kubernetes
Structure Tâche K8s
TÂCHE DE CHANGEMENT KUBERNETES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CHANGEMENT DÉPLOIEMENT K8S: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INFRA-200: Mise à jour config déploiement API ││
│ │ ││
│ │ CHANGEMENTS: ││
│ │ • Augmenter replicas: 3 → 5 ││
│ │ • Mise à jour limites ressources ││
│ │ • Ajouter readiness probe ││
│ │ ││
│ │ MANIFESTS AFFECTÉS: ││
│ │ • k8s/api/deployment.yaml ││
│ │ • k8s/api/hpa.yaml ││
│ │ ││
│ │ STRATÉGIE ROLLOUT: ││
│ │ Rolling update (pas de downtime) ││
│ │ ││
│ │ TESTS: ││
│ │ ☐ Apply au namespace staging ││
│ │ ☐ Vérifier pods healthy ││
│ │ ☐ Test de charge ││
│ │ ☐ Apply au namespace production ││
│ │ ││
│ │ ROLLBACK: ││
│ │ kubectl rollout undo deployment/api ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TÂCHE UPGRADE HELM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INFRA-210: Upgrade ingress-nginx vers 4.8.0 ││
│ │ ││
│ │ Actuel: 4.6.0 ││
│ │ Cible: 4.8.0 ││
│ │ ││
│ │ REVUE CHANGELOG: ││
│ │ • Breaking changes: Aucun ││
│ │ • Nouvelles features: Améliorations rate limiting ││
│ │ • Bug fixes: Fix fuite mémoire ││
│ │ ││
│ │ RISQUE: Moyen (ingress affecte tout le trafic) ││
│ │ ││
│ │ TESTS: ││
│ │ ☐ Upgrade en staging ││
│ │ ☐ Test toutes les routes ingress ││
│ │ ☐ Monitorer les erreurs ││
│ │ ☐ Upgrade en production ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Gestion des Changements
Processus de Changement Infrastructure
GESTION DES CHANGEMENTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CHANGE ADVISORY BOARD (pour haut risque): │
│ │
│ RÉUNION CAB HEBDOMADAIRE: │
│ Réviser les changements infrastructure haut risque │
│ │
│ TÂCHE REVUE CAB: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CAB-2024-05: Revue Migration VPC ││
│ │ ││
│ │ Changement: INFRA-150 (migration VPC) ││
│ │ Demandeur: @devops-lead ││
│ │ ││
│ │ ÉLÉMENTS DE REVUE: ││
│ │ ☐ Justification business ││
│ │ ☐ Approche technique ││
│ │ ☐ Évaluation risque ││
│ │ ☐ Plan rollback ││
│ │ ☐ Plan communication ││
│ │ ☐ Tests complétés ││
│ │ ││
│ │ DÉCISION: Approuvé / Changements requis / Rejeté ││
│ │ ││
│ │ CONDITIONS: ││
│ │ • Doit être complété pendant fenêtre maintenance ││
│ │ • Équipe database en standby ││
│ │ • Notification client envoyée ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FENÊTRES DE MAINTENANCE: │
│ │
│ Fenêtre standard: Samedi 2-6h │
│ Fenêtre urgence: Selon besoin avec approbation │
│ │
│ COMMUNICATION: │
│ ☐ Maintenance planifiée page statut │
│ ☐ Email client (si significatif) │
│ ☐ Notification Slack interne │
└─────────────────────────────────────────────────────────────┘
Documentation
Documentation Infrastructure
DOCUMENTATION INFRASTRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TÂCHE DOCUMENTATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INFRA-DOC-01: Documenter setup cluster Redis ││
│ │ ││
│ │ Créé après: INFRA-100 ││
│ │ ││
│ │ DOCUMENTATION: ││
│ │ ☐ Diagramme architecture ││
│ │ ☐ Détails configuration ││
│ │ ☐ Accès et credentials ││
│ │ ☐ Monitoring et alertes ││
│ │ ☐ Runbook problèmes courants ││
│ │ ☐ Disaster recovery ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TEMPLATE RUNBOOK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RUNBOOK CLUSTER REDIS ││
│ │ ││
│ │ PROBLÈMES COURANTS: ││
│ │ ││
│ │ Utilisation mémoire élevée: ││
│ │ 1. Vérifier quelles clés consomment la mémoire ││
│ │ 2. Réviser les paramètres TTL ││
│ │ 3. Scaler si croissance légitime ││
│ │ ││
│ │ Échecs de connexion: ││
│ │ 1. Vérifier règles security group ││
│ │ 2. Vérifier subnet app peut joindre subnet Redis ││
│ │ 3. Vérifier statut cluster Redis ││
│ │ ││
│ │ DISASTER RECOVERY: ││
│ │ 1. Snapshots: Automatique quotidien ││
│ │ 2. Restore: terraform apply avec snapshot_id ││
│ │ 3. RTO: 30 minutes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEFINITION OF DONE POUR INFRA: │
│ ☐ Code revu et mergé │
│ ☐ Appliqué avec succès │
│ ☐ Monitoring configuré │
│ ☐ Documentation mise à jour │
│ ☐ Runbook créé/mis à jour │
└─────────────────────────────────────────────────────────────┘