⚙️DevOps – Terraform, State, GitLab CI/CD & Gestion d'incidents (Part 2)

Structure standard

# Runbook : titre court

                            ## Objectif
                            Décrire le problème que ce runbook permet de traiter.

                            ## Symptômes
                            - Alerte :
                            - Logs :
                            - Métriques :
                            - Comportement utilisateur :

                            ## Impact possible
                            - Services touchés :
                            - Utilisateurs touchés :
                            - Données / sécurité :
                            - Niveau de gravité probable :

                            ## Pré-requis
                            - Accès nécessaires :
                            - Outils :
                            - Variables :
                            - Dashboards :

                            ## Étapes de diagnostic
                            1. ...
                            2. ...
                            3. ...

                            ## Actions de mitigation
                            1. ...
                            2. ...
                            3. ...

                            ## Validation du retour au nominal
                            - Healthcheck :
                            - Logs :
                            - Métriques :
                            - Test métier :

                            ## Rollback
                            - Action de retour arrière :
                            - Risque :
                            - Vérification :

                            ## Escalade
                            - Qui contacter :
                            - Quand escalader :

                            ## Notes post-incident
                            - Ticket :
                            - Post-mortem :
                            - Actions préventives :

Qualité attendue

Diagramme d’utilisation

Alerte déclenchée
                            │
                            ▼
                            Identifier runbook correspondant
                            │
                            ▼
                            Lire prérequis et risques
                            │
                            ▼
                            Exécuter diagnostic
                            │
                            ▼
                            Choisir mitigation
                            │
                            ▼
                            Valider retour nominal
                            │
                            ▼
                            Documenter résultat
                            │
                            ▼
                            Mettre à jour runbook si manque détecté

Procédure

1. Déclarer l'incident si impact production.
                            2. Identifier le dernier apply Terraform.
                            3. Identifier le commit, la MR et le plan appliqué.
                            4. Lire les logs du job apply.
                            5. Lancer un plan refresh-only si nécessaire.
                            6. Déterminer si rollback complet ou patch minimal.
                            7. Revenir au commit précédent ou créer un correctif ciblé.
                            8. Générer un nouveau plan.
                            9. Vérifier qu'il ne détruit pas de ressource critique.
                            10. Faire relire le plan.
                            11. Appliquer avec approval.
                            12. Vérifier logs, métriques, health checks.
                            13. Documenter l'incident et la cause.

Commandes utiles

# Identifier l'état courant
                            terraform state list
                            terraform plan -refresh-only

                            # Revenir à un commit précédent
                            git revert <commit_id>
                            git push origin main

                            # Générer un plan de rollback
                            terraform plan -out=tfplan -var-file="prod.tfvars"
                            terraform show -no-color tfplan > rollback-plan.txt

                            # Appliquer après review
                            terraform apply tfplan

Validation post-rollback

Diagnostic avant restart

# État du service
                            systemctl status app.service --no-pager

                            # Logs récents
                            journalctl -u app.service -n 100 --no-pager

                            # Ressources système
                            uptime
                            free -h
                            df -h

                            # Processus
                            ps aux | grep app
                            top

Procédure restart

1. Confirmer impact et nécessité du restart.
                            2. Vérifier s'il existe plusieurs instances.
                            3. Prévenir dans le canal incident si production.
                            4. Capturer logs avant restart.
                            5. Redémarrer une instance à la fois si possible.
                            6. Vérifier status systemd.
                            7. Vérifier healthcheck applicatif.
                            8. Surveiller logs et métriques.
                            9. Documenter l'action.

Commandes restart

# Restart contrôlé
                            sudo systemctl restart app.service

                            # Vérifier état
                            sudo systemctl status app.service --no-pager

                            # Suivre logs
                            sudo journalctl -u app.service -f

                            # Vérifier healthcheck
                            curl -fsS http://127.0.0.1:8000/health/
                            curl -fsS https://example.com/health/

Quand éviter un restart immédiat ?

Commandes diagnostic rapides

# Charge système
                            uptime
                            top
                            ps aux --sort=-%cpu | head
                            ps aux --sort=-%mem | head

                            # Mémoire
                            free -h
                            dmesg | grep -i "killed process"

                            # Disque
                            df -h
                            df -i
                            du -sh /var/log/* | sort -h
                            du -sh /tmp/* | sort -h

                            # Erreurs système
                            journalctl -p err -n 100 --no-pager

                            # Services critiques
                            systemctl status nginx --no-pager
                            systemctl status app.service --no-pager

Diagnostic par symptôme

Mitigation disque plein

1. Identifier le volume plein avec df -h.
                            2. Identifier gros dossiers avec du.
                            3. Vérifier logs applicatifs et Nginx.
                            4. Compresser ou purger uniquement fichiers sûrs.
                            5. Redémarrer service seulement si nécessaire.
                            6. Ajouter logrotate ou corriger rétention.
                            7. Ajouter alerte disque 75/85/95%.

Symptômes fréquents

Commandes génériques Linux côté DB

# Ressources serveur
                            top
                            free -h
                            df -h
                            iostat -xz 1 5

                            # Logs
                            journalctl -u postgresql -n 100 --no-pager
                            journalctl -u mysql -n 100 --no-pager
                            journalctl -u mariadb -n 100 --no-pager

Procédure DB

1. Confirmer impact applicatif : 5xx, latence, timeouts.
                            2. Vérifier connexions DB et saturation.
                            3. Identifier requêtes lentes ou locks.
                            4. Vérifier dernier déploiement ou migration.
                            5. Éviter restart DB brutal sauf nécessité critique.
                            6. Mitiger : rollback app, réduire workers, tuer requête fautive si validé.
                            7. Vérifier retour métriques DB.
                            8. Documenter requête, index, migration ou config responsable.

Mitigations possibles

Commandes diagnostic

# DNS
                            dig example.com
                            dig +short example.com
                            nslookup example.com

                            # HTTP / TLS
                            curl -v https://example.com/
                            curl -fsS https://example.com/health/
                            openssl s_client -connect example.com:443 -servername example.com

                            # Connectivité port
                            nc -vz db.internal 5432
                            nc -vz redis.internal 6379

                            # Routes locales
                            ip addr
                            ip route
                            ss -tulpn

Symptômes fréquents

Procédure réseau

Incident réseau détecté
                            │
                            ▼
                            Identifier couche
                            ├── DNS
                            ├── TLS
                            ├── Load balancer
                            ├── Security group / firewall
                            ├── Route table
                            └── Backend service
                            │
                            ▼
                            Tester depuis plusieurs points
                            ├── local
                            ├── serveur
                            ├── réseau interne
                            └── externe
                            │
                            ▼
                            Relier à un changement récent
                            ├── Terraform apply
                            ├── certificat renouvelé
                            ├── DNS modifié
                            └── service déployé
                            │
                            ▼
                            Mitigation ciblée

Mitigations typiques

Procédure pipeline bloqué

1. Identifier le job exact en échec.
                            2. Lire les logs depuis le début.
                            3. Vérifier runner disponible et tags.
                            4. Vérifier image CI et version Terraform.
                            5. Vérifier variables accessibles à la branche.
                            6. Vérifier terraform init et backend.
                            7. Vérifier state lock.
                            8. Vérifier artifact tfplan si apply.
                            9. Corriger la cause minimale.
                            10. Relancer uniquement le job nécessaire.
                            11. Informer l'équipe si production concernée.

Commandes utiles

# Runner
                            gitlab-runner verify
                            gitlab-runner list

                            # Terraform
                            terraform --version
                            terraform providers
                            terraform init
                            terraform validate
                            terraform plan -refresh-only
                            terraform state list

                            # Lock, seulement après analyse
                            terraform force-unlock LOCK_ID

Diagnostic par symptôme

Flux décisionnel

Pipeline échoué
                            │
                            ▼
                            Est-ce un job prod ?
                            │
                            ├── Oui : informer équipe + prudence renforcée
                            └── Non : diagnostic standard
                            │
                            ▼
                            Erreur runner, variable, backend, lock ou provider ?
                            │
                            ▼
                            Corriger cause minimale
                            │
                            ▼
                            Relancer plan
                            │
                            ▼
                            Relancer apply uniquement si plan OK

Procédure immédiate

1. Identifier le secret exposé.
                            2. Déterminer son périmètre : dev, staging, prod.
                            3. Révoquer ou désactiver le secret.
                            4. Créer un nouveau secret avec droits minimaux.
                            5. Mettre à jour GitLab/Vault/Secret Manager.
                            6. Relancer les pipelines nécessaires.
                            7. Vérifier que les services fonctionnent.
                            8. Auditer les logs d'utilisation.
                            9. Nettoyer logs/artifacts si possible.
                            10. Documenter incident et prévention.

Priorité selon secret

Prévention

• Secret detection activée sur merge requests.
• Variables masked/protected/scoped.
• OIDC ou credentials courts si possible.
• Pas de echo $SECRET ni env dans les jobs.
• Artifacts explicitement listés.
• Rotation documentée.

Critères de qualité

Revue périodique

Tous les 3 mois :
                            [ ] Vérifier commandes.
                            [ ] Vérifier noms de services.
                            [ ] Vérifier liens dashboards.
                            [ ] Vérifier contacts d'escalade.
                            [ ] Vérifier accès nécessaires.
                            [ ] Tester en staging si possible.
                            [ ] Mettre à jour après incidents récents.

Exercice GameDay

Simulation contrôlée
                            │
                            ▼
                            Choisir scénario
                            ├── disque presque plein
                            ├── service down
                            ├── pipeline lock
                            └── DB lente
                            │
                            ▼
                            Suivre runbook
                            │
                            ▼
                            Mesurer
                            ├── temps diagnostic
                            ├── clarté étapes
                            ├── erreurs rencontrées
                            └── manque documentaire
                            │
                            ▼
                            Améliorer runbook

Où stocker les runbooks ?

Checklist création

Checklist runbooks prioritaires

Mini-cheat-sheet

Runbook = symptômes + impact + diagnostic + action + validation + rollback + escalade

                            Toujours préciser :
                            [ ] Quand utiliser
                            [ ] Quand ne pas utiliser
                            [ ] Commandes exactes
                            [ ] Risques
                            [ ] Signaux de succès
                            [ ] Qui appeler
                            [ ] Quoi documenter après action

Niveau 1 : Junior opérationnel

Niveau 2 : DevOps autonome

Niveau 3 : DevOps confirmé / SRE

Niveau 4 : Platform Engineer

Ordre d’apprentissage

Exercices Terraform progressifs

Exercice 1 :
                            Créer une ressource simple avec tags.

                            Exercice 2 :
                            Ajouter variables.tf, outputs.tf, locals.tf.

                            Exercice 3 :
                            Créer dev.tfvars et prod.tfvars.

                            Exercice 4 :
                            Créer un module network.

                            Exercice 5 :
                            Créer un module compute qui consomme network outputs.

                            Exercice 6 :
                            Configurer backend distant.

                            Exercice 7 :
                            Simuler drift et le corriger proprement.

                            Exercice 8 :
                            Ajouter prevent_destroy sur ressource critique.

Compétence attendue

Compétences CI/CD à acquérir

Pipeline cible

Merge Request
                            │
                            ├── terraform fmt
                            ├── terraform validate
                            ├── scan sécurité
                            └── terraform plan
                            │
                            ▼
                            Review du plan
                            │
                            ▼
                            Merge main
                            │
                            ▼
                            Plan production
                            │
                            ▼
                            Approval
                            │
                            ▼
                            Apply manuel
                            │
                            ▼
                            Post-checks

Exercices CI/CD

Exercice 1 :
                            Créer pipeline avec stages lint/validate.

                            Exercice 2 :
                            Ajouter terraform plan avec artifact plan.txt.

                            Exercice 3 :
                            Ajouter checkov ou trivy config.

                            Exercice 4 :
                            Ajouter apply manuel en staging.

                            Exercice 5 :
                            Protéger variables et environnement production.

                            Exercice 6 :
                            Ajouter post_deploy_checks avec curl /health.

                            Exercice 7 :
                            Simuler state lock et écrire runbook.

                            Exercice 8 :
                            Factoriser jobs avec includes/templates.

Maturité CI/CD

Fondations Linux

Commandes indispensables

systemctl status nginx
                            journalctl -u nginx -n 100 --no-pager
                            df -h
                            du -sh /var/log/* | sort -h
                            free -h
                            top
                            ss -tulpn
                            curl -v https://example.com/
                            dig example.com
                            nc -vz host 443

Fondations Cloud

Mini-architecture à construire

Internet
                            │
                            ▼
                            DNS + TLS
                            │
                            ▼
                            Load Balancer
                            │
                            ▼
                            Application VM / Container
                            │
                            ├── logs
                            ├── metrics
                            └── healthcheck
                            │
                            ▼
                            Database managed
                            │
                            ├── backups
                            ├── private access
                            └── monitoring

Progression observabilité

Golden signals

Latency:
                            p50, p95, p99

                            Traffic:
                            requests/sec, jobs/min

                            Errors:
                            HTTP 5xx, exceptions, failed jobs

                            Saturation:
                            CPU, RAM, disk, DB connections, queue backlog

Dashboard cible

Production Overview
                            │
                            ├── Availability
                            ├── HTTP 5xx
                            ├── Latency p95 / p99
                            ├── Traffic
                            ├── CPU / RAM / Disk
                            ├── Database health
                            ├── Queue backlog
                            ├── Last deployments
                            └── Active alerts

Alertes minimales

Compétences incident à acquérir

Exercices simulation

Simulation 1 :
                            Healthcheck applicatif KO.
                            Objectif : diagnostiquer logs + restart contrôlé.

                            Simulation 2 :
                            Disque presque plein.
                            Objectif : identifier dossier, mitigation, prévention.

                            Simulation 3 :
                            Terraform state lock.
                            Objectif : identifier job détenteur, éviter force-unlock abusif.

                            Simulation 4 :
                            Security group DB cassé.
                            Objectif : rollback règle réseau.

                            Simulation 5 :
                            Déploiement app provoque 5xx.
                            Objectif : rollback + post-mortem.

Process incident cible

Alerte
                            │
                            ▼
                            Déclaration incident
                            │
                            ├── gravité
                            ├── canal
                            ├── Incident Commander
                            └── timeline
                            │
                            ▼
                            Mitigation
                            ├── rollback
                            ├── scale
                            ├── feature flag
                            └── patch minimal
                            │
                            ▼
                            Vérification retour nominal
                            │
                            ▼
                            Communication de stabilisation
                            │
                            ▼
                            Post-mortem
                            │
                            ├── RCA
                            ├── actions préventives
                            └── suivi

Maturité SRE

Projet 1 : mini plateforme web

Projet 2 : backend distant Terraform

Projet 3 : pipeline infra complet

Projet 4 : simulation incident

Niveaux de maturité équipe

RoadMap équipe en 5 étapes

Étape 1 : Stop ClickOps
                            ├── inventorier infra
                            ├── créer Terraform baseline
                            └── remote state

                            Étape 2 : CI/CD minimale
                            ├── fmt
                            ├── validate
                            └── plan en MR

                            Étape 3 : Contrôle production
                            ├── branches protégées
                            ├── variables protégées
                            ├── apply manuel
                            └── approvals

                            Étape 4 : Observabilité
                            ├── logs
                            ├── metrics
                            ├── dashboards
                            └── alertes

                            Étape 5 : SRE
                            ├── runbooks
                            ├── post-mortems
                            ├── SLO
                            └── GameDays

KPIs de maturité

Checklist compétences individuelles

Checklist plateforme production-ready

Mini-cheat-sheet RoadMap

1. Linux + réseau
                            2. Cloud basics
                            3. Terraform basics
                            4. Modules Terraform
                            5. Remote state + locking
                            6. GitLab CI/CD infra
                            7. Secrets + IAM least privilege
                            8. Environnements dev/staging/prod
                            9. Déploiement contrôlé
                            10. Observabilité
                            11. Runbooks
                            12. Incidents + post-mortems + SRE

Cycle standard

# Initialiser le dossier Terraform
                            terraform init

                            # Formater le code
                            terraform fmt -recursive
                            terraform fmt -check -recursive

                            # Valider la configuration
                            terraform validate

                            # Générer un plan
                            terraform plan

                            # Générer un plan sauvegardé
                            terraform plan -out=tfplan

                            # Lire un plan binaire en texte
                            terraform show -no-color tfplan

                            # Appliquer le plan exact
                            terraform apply tfplan

                            # Appliquer directement
                            terraform apply

                            # Afficher les outputs
                            terraform output

Commandes avec variables

# Plan avec fichier variables
                            terraform plan -var-file="dev.tfvars"
                            terraform plan -var-file="staging.tfvars"
                            terraform plan -var-file="prod.tfvars"

                            # Plan sauvegardé avec tfvars
                            terraform plan -var-file="prod.tfvars" -out=tfplan

                            # Variable inline
                            terraform plan -var="environment=prod"

                            # Utiliser une variable d'environnement
                            export TF_VAR_environment="prod"
                            terraform plan

Lecture rapide du plan

Inspection du state

# Lister les ressources connues du state
                            terraform state list

                            # Afficher une ressource précise
                            terraform state show aws_instance.web

                            # Afficher les outputs
                            terraform output

                            # Exporter le state courant localement
                            terraform state pull > state-backup.json

                            # Pousser un state modifié
                            # À éviter sauf procédure contrôlée
                            terraform state push state-backup.json

Drift detection

# Voir les écarts entre state et infrastructure réelle
                            terraform plan -refresh-only

                            # Appliquer uniquement la mise à jour du state
                            terraform apply -refresh-only

Import / move / remove

# Importer une ressource existante dans Terraform
                            terraform import aws_security_group.web sg-0123456789abcdef0

                            # Déplacer une ressource dans le state
                            terraform state mv aws_instance.web aws_instance.app

                            # Retirer une ressource du state sans la détruire
                            terraform state rm aws_instance.web

State lock

# Déverrouiller un lock orphelin
                            # Seulement après preuve qu'aucun apply n'est actif
                            terraform force-unlock LOCK_ID

Remote state

data "terraform_remote_state" "network" {
                            backend = "s3"

                            config = {
                            bucket = "company-terraform-state-prod"
                            key    = "prod/network/terraform.tfstate"
                            region = "eu-west-3"
                            }
                            }

Git essentiel pour infra

# État du repo
                            git status

                            # Créer une branche
                            git checkout -b infra/change-name

                            # Voir les changements
                            git diff
                            git diff --staged

                            # Ajouter / commit
                            git add .
                            git commit -m "Update Terraform infrastructure"

                            # Historique
                            git log --oneline -10

                            # Revenir à un commit par revert
                            git revert <commit_id>

                            # Voir fichiers modifiés
                            git show --stat

GitLab Runner

# Vérifier runners
                            gitlab-runner verify
                            gitlab-runner list

                            # Service runner
                            systemctl status gitlab-runner --no-pager
                            journalctl -u gitlab-runner -n 100 --no-pager
                            journalctl -u gitlab-runner -f

Template pipeline Terraform minimal

stages:
                            - lint
                            - validate
                            - plan
                            - apply

                            variables:
                            TF_IN_AUTOMATION: "true"
                            TF_INPUT: "false"
                            TF_ROOT: "infra/live/prod/app"

                            default:
                            image: hashicorp/terraform:1.6.6
                            before_script:
                            - cd "$TF_ROOT"
                            - terraform init

                            terraform_fmt:
                            stage: lint
                            script:
                            - terraform fmt -check -recursive

                            terraform_validate:
                            stage: validate
                            script:
                            - terraform validate

                            terraform_plan:
                            stage: plan
                            script:
                            - terraform plan -out=tfplan
                            - terraform show -no-color tfplan > plan.txt
                            artifacts:
                            paths:
                            - "$TF_ROOT/tfplan"
                            - "$TF_ROOT/plan.txt"
                            expire_in: 3 days

                            terraform_apply:
                            stage: apply
                            script:
                            - terraform apply tfplan
                            when: manual
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'

État système

# Charge et uptime
                            uptime

                            # CPU / process
                            top
                            ps aux --sort=-%cpu | head
                            ps aux --sort=-%mem | head

                            # Mémoire
                            free -h
                            dmesg | grep -i "killed process"

                            # Disque
                            df -h
                            df -i
                            du -sh /var/log/* | sort -h
                            du -sh /tmp/* | sort -h

                            # Réseau local
                            ss -tulpn
                            ip addr
                            ip route

Services systemd

# Statut service
                            systemctl status nginx --no-pager
                            systemctl status app.service --no-pager

                            # Redémarrage contrôlé
                            sudo systemctl restart app.service

                            # Activer/désactiver au boot
                            sudo systemctl enable app.service
                            sudo systemctl disable app.service

Logs

# Logs service
                            journalctl -u app.service -n 100 --no-pager
                            journalctl -u app.service -f

                            # Erreurs système récentes
                            journalctl -p err -n 100 --no-pager

                            # Nginx
                            tail -f /var/log/nginx/access.log
                            tail -f /var/log/nginx/error.log

                            # Chercher erreurs HTTP 500
                            grep " 500 " /var/log/nginx/access.log | tail

                            # Logs depuis une heure
                            journalctl --since "1 hour ago" --no-pager

Saturation disque

df -h
                            du -sh /var/log/* | sort -h
                            journalctl --disk-usage

                            # Nettoyage journal systemd contrôlé
                            sudo journalctl --vacuum-time=7d

                            # Attention : vérifier avant suppression manuelle

DNS

# Résolution DNS
                            dig example.com
                            dig +short example.com
                            nslookup example.com

                            # Vérifier un record précis
                            dig A example.com
                            dig CNAME www.example.com
                            dig TXT example.com

                            # Voir TTL
                            dig example.com

HTTP / HTTPS

# Tester endpoint
                            curl -v https://example.com/
                            curl -fsS https://example.com/health/

                            # Voir headers
                            curl -I https://example.com/

                            # Tester avec host header
                            curl -H "Host: example.com" http://IP_ADDRESS/

                            # Mesurer temps
                            curl -w "@curl-format.txt" -o /dev/null -s https://example.com/

TLS / certificats

# Vérifier certificat TLS
                            openssl s_client -connect example.com:443 -servername example.com

                            # Dates certificat
                            echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
                            | openssl x509 -noout -dates

                            # Certbot
                            sudo certbot certificates
                            sudo certbot renew --dry-run

Connectivité ports

# Tester port TCP
                            nc -vz example.com 443
                            nc -vz db.internal 5432
                            nc -vz redis.internal 6379

                            # Ports ouverts localement
                            ss -tulpn

                            # Routes
                            ip route
                            traceroute example.com

Avant apply production

Pendant apply

# Ne pas lancer plusieurs apply
                            # Surveiller logs du job
                            # Noter toute ressource en erreur
                            # Ne pas force-unlock sans preuve
                            # Si échec partiel : relancer plan avant correction

Après apply production

# Outputs Terraform
                            terraform output

                            # Health checks
                            curl -fsS https://example.com/health/
                            curl -fsS https://example.com/api/status/

                            # Logs applicatifs
                            journalctl -u app.service -n 100 --no-pager

                            # Nginx errors
                            tail -n 100 /var/log/nginx/error.log

                            # Vérifier erreurs 5xx
                            grep " 500 " /var/log/nginx/access.log | tail

Signaux de santé

Pipeline bloqué ou failed

Méthode de debug

Job échoué
                            │
                            ▼
                            Lire logs depuis le début
                            │
                            ├── image Docker
                            ├── dossier courant
                            ├── variables non sensibles
                            ├── terraform version
                            ├── terraform init
                            ├── provider error
                            └── backend / state
                            │
                            ▼
                            Corriger cause minimale
                            │
                            ▼
                            Relancer plan
                            │
                            ▼
                            Apply seulement si plan OK

Commandes debug CI sûres

# Afficher contexte non sensible
                            echo "Branch: $CI_COMMIT_BRANCH"
                            echo "Environment: $CI_ENVIRONMENT_NAME"
                            echo "Terraform root: $TF_ROOT"
                            terraform --version

                            # Vérifier présence variable sans l'afficher
                            if [ -z "$AWS_ACCESS_KEY_ID" ]; then
                            echo "AWS_ACCESS_KEY_ID is missing"
                            exit 1
                            else
                            echo "AWS_ACCESS_KEY_ID is present"
                            fi

                            # Terraform debug utile
                            terraform providers
                            terraform validate
                            terraform plan -refresh-only

À ne pas faire

# Dangereux : affiche secrets potentiels
                            env
                            printenv
                            echo "$AWS_SECRET_ACCESS_KEY"

                            # Dangereux en job sensible
                            set -x

                            # Dangereux sans analyse
                            terraform force-unlock LOCK_ID

Secrets GitLab / CI

Secret scanning local

# Exemples d'outils possibles
                            gitleaks detect
                            trufflehog filesystem .
                            detect-secrets scan

                            # Recherche simple à la main
                            grep -R "AWS_SECRET" .
                            grep -R "PRIVATE KEY" .
                            grep -R "password" .

Scan IaC

# Checkov
                            checkov -d .

                            # tfsec
                            tfsec .

                            # Trivy config
                            trivy config .

                            # Terraform format/validate
                            terraform fmt -check -recursive
                            terraform validate

Audit rapide après incident

Terraform

J’utilise Terraform pour décrire l’infrastructure as code,
                            avec une structure claire en modules, variables, outputs et environnements séparés.
                            Je fais toujours relire le plan avant apply, surtout en production.
                            Je fais attention au remote state, au locking, au drift et aux risques de destroy/replace.
                            Mon approche est de rendre l’infrastructure reproductible, traçable et contrôlée.

GitLab CI/CD infra

Oui, j’ai travaillé sur des pipelines GitLab CI/CD orientés infrastructure.
                            Je structure les étapes fmt, validate, security scan, plan, review et apply manuel.
                            J’utilise des artifacts pour conserver le plan, des variables protégées et des branches protégées.
                            En production, l’apply doit être contrôlé, approuvé et vérifié après exécution.

State Terraform

Je considère le state Terraform comme un composant critique.
                            En production, il doit être distant, chiffré, verrouillé, versionné et isolé par environnement.
                            Je fais attention au drift, aux imports et aux opérations sensibles comme state rm ou force-unlock.
                            Je ne commite jamais de tfstate dans Git.

Incidents production

Oui, j’ai déjà géré des incidents production.
                            Ma méthode est de qualifier l’impact, stabiliser, mitiger, restaurer le service,
                            puis analyser la cause racine à froid.
                            Je privilégie rollback, contournement ou correction minimale selon le contexte.
                            Après incident, je formalise un post-mortem avec actions préventives.

Secrets et sécurité CI

Je fais attention à ne jamais stocker de secrets dans Git.
                            J’utilise des variables GitLab masked, protected et scopées par environnement.
                            Je privilégie les credentials courts, OIDC ou secret manager lorsque c’est possible.
                            Côté cloud, j’applique le principe du moindre privilège avec des rôles séparés par environnement.

Observabilité

Je mets en place logs, métriques, alertes et dashboards pour piloter la production.
                            Les signaux importants sont les 5xx, la latence p95/p99, la saturation système,
                            les connexions DB, les queues et les échecs pipeline.
                            Une bonne alerte doit être actionnable et liée à un runbook.

Avant merge request infra

Avant apply production

Après apply production

Ultra cheat-sheet

terraform fmt -check -recursive
                            terraform validate
                            terraform plan -out=tfplan
                            terraform show -no-color tfplan > plan.txt
                            terraform apply tfplan
                            terraform plan -refresh-only
                            terraform state list

                            git status
                            git diff
                            git log --oneline -10

                            systemctl status app.service
                            journalctl -u app.service -n 100
                            df -h
                            free -h
                            curl -fsS https://example.com/health/
                            dig example.com
                            nc -vz host port

Convention recommandée

locals {
                            name_prefix = "${var.project}-${var.environment}-${var.component}"

                            common_tags = {
                            Project     = var.project
                            Environment = var.environment
                            Component   = var.component
                            ManagedBy   = "terraform"
                            Owner       = var.owner
                            }
                            }

Exemples de noms

Variables de naming

variable "project" {
                            description = "Project name used in resource naming."
                            type        = string
                            }

                            variable "environment" {
                            description = "Environment name."
                            type        = string

                            validation {
                            condition     = contains(["dev", "staging", "prod"], var.environment)
                            error_message = "Environment must be dev, staging, or prod."
                            }
                            }

                            variable "component" {
                            description = "Application or infrastructure component."
                            type        = string
                            }

                            variable "owner" {
                            description = "Team or owner responsible for this resource."
                            type        = string
                            }

Nommage : erreurs fréquentes

Exemple propre de locals.tf

locals {
                            name_prefix = "${var.project}-${var.environment}-${var.component}"

                            common_tags = merge(
                            {
                            Project     = var.project
                            Environment = var.environment
                            Component   = var.component
                            ManagedBy   = "terraform"
                            },
                            var.extra_tags
                            )

                            is_prod = var.environment == "prod"

                            default_backup_retention_days = local.is_prod ? 14 : 3
                            default_deletion_protection   = local.is_prod ? true : false
                            }

Utilisation dans une ressource

resource "aws_security_group" "web" {
                            name        = "${local.name_prefix}-web-sg"
                            description = "Security group for web traffic"
                            vpc_id      = var.vpc_id

                            tags = local.common_tags
                            }

Cas d’usage des locals

Locals à éviter

# Mauvais : local trop magique et illisible
                            locals {
                            everything = {
                            for x in var.services :
                            x.name => merge(x, {
                            final_name = "${var.project}-${var.environment}-${x.name}"
                            enabled    = try(x.enabled, true)
                            settings   = try(x.settings, {})
                            })
                            }
                            }

Validation d’environnement

variable "environment" {
                            description = "Deployment environment."
                            type        = string

                            validation {
                            condition     = contains(["dev", "staging", "prod"], var.environment)
                            error_message = "Environment must be dev, staging, or prod."
                            }
                            }

Validation CIDR

variable "vpc_cidr" {
                            description = "CIDR block for the VPC."
                            type        = string

                            validation {
                            condition     = can(cidrhost(var.vpc_cidr, 0))
                            error_message = "vpc_cidr must be a valid CIDR block."
                            }
                            }

Validation taille instance

variable "instance_type" {
                            description = "EC2 instance type."
                            type        = string

                            validation {
                            condition = contains([
                            "t3.micro",
                            "t3.small",
                            "t3.medium"
                            ], var.instance_type)

                            error_message = "Instance type must be one of the approved values."
                            }
                            }

Validations utiles en production

Validation objet complexe

variable "services" {
                            description = "Map of services to deploy."
                            type = map(object({
                            image         = string
                            desired_count = number
                            public        = bool
                            }))

                            validation {
                            condition = alltrue([
                            for service in var.services :
                            service.desired_count >= 1
                            ])
                            error_message = "Each service must have desired_count greater than or equal to 1."
                            }
                            }

count : simple mais fragile

resource "aws_subnet" "private" {
                            count = length(var.private_subnets)

                            vpc_id     = var.vpc_id
                            cidr_block = var.private_subnets[count.index]

                            tags = merge(local.common_tags, {
                            Name = "${local.name_prefix}-private-${count.index + 1}"
                            })
                            }

Quand utiliser count ?

for_each : recommandé pour les collections stables

variable "private_subnets" {
                            type = map(object({
                            cidr_block        = string
                            availability_zone = string
                            }))
                            }

                            resource "aws_subnet" "private" {
                            for_each = var.private_subnets

                            vpc_id            = var.vpc_id
                            cidr_block        = each.value.cidr_block
                            availability_zone = each.value.availability_zone

                            tags = merge(local.common_tags, {
                            Name = "${local.name_prefix}-private-${each.key}"
                            })
                            }

Exemple tfvars

private_subnets = {
                            "a" = {
                            cidr_block        = "10.20.11.0/24"
                            availability_zone = "eu-west-3a"
                            }

                            "b" = {
                            cidr_block        = "10.20.12.0/24"
                            availability_zone = "eu-west-3b"
                            }
                            }

prevent_destroy

resource "aws_db_instance" "main" {
                            identifier = "${local.name_prefix}-db"

                            lifecycle {
                            prevent_destroy = true
                            }
                            }

Très utile pour les ressources critiques : bases de données, buckets contenant des données, clés KMS, volumes persistants.

create_before_destroy

resource "aws_launch_template" "app" {
                            name_prefix = "${local.name_prefix}-"

                            lifecycle {
                            create_before_destroy = true
                            }
                            }

Utile quand on veut réduire le downtime en créant la nouvelle ressource avant de supprimer l’ancienne.

ignore_changes

resource "aws_autoscaling_group" "app" {
                            name = "${local.name_prefix}-asg"

                            desired_capacity = var.desired_capacity

                            lifecycle {
                            ignore_changes = [
                            desired_capacity
                            ]
                            }
                            }

Peut être utile si l’autoscaling modifie une valeur que Terraform ne doit pas corriger à chaque plan.

Lifecycle : cas d’usage

Dépendance implicite recommandée

resource "aws_security_group" "web" {
                            name   = "${local.name_prefix}-web-sg"
                            vpc_id = aws_vpc.main.id
                            }

                            resource "aws_instance" "web" {
                            ami                    = var.ami_id
                            instance_type          = var.instance_type
                            vpc_security_group_ids = [aws_security_group.web.id]
                            }

Ici, l’instance dépend automatiquement du security group parce qu’elle référence son ID.

depends_on explicite

resource "aws_instance" "app" {
                            ami           = var.ami_id
                            instance_type = var.instance_type

                            depends_on = [
                            aws_cloudwatch_log_group.app
                            ]
                            }

Quand utiliser depends_on ?

Diagramme du graphe

aws_vpc.main
                            │
                            ▼
                            aws_subnet.private
                            │
                            ▼
                            aws_security_group.app
                            │
                            ▼
                            aws_instance.app
                            │
                            ▼
                            aws_lb_target_group_attachment.app

Pièges de dépendances

Contrat d’un module

Module spécialisé

module "api_service" {
                            source = "../../modules/compute-service"

                            project      = var.project
                            environment  = var.environment
                            component    = "api"
                            image        = var.api_image
                            desired_count = 3

                            vpc_id     = module.network.vpc_id
                            subnet_ids = module.network.private_subnet_ids

                            tags = local.common_tags
                            }

Module trop générique : danger

module "universal_resource"
                            │
                            ├── create_vpc
                            ├── create_db
                            ├── create_lb
                            ├── create_dns
                            ├── enable_cache
                            ├── enable_iam
                            ├── enable_monitoring
                            ├── 80 variables
                            └── 25 conditions

Bon découpage

modules/
                            ├── network
                            ├── security-group
                            ├── load-balancer
                            ├── compute-service
                            ├── database-postgres
                            ├── redis-cache
                            ├── dns-record
                            └── monitoring-alarm

Règles de design module

Garde-fous production

Exemple DB production

resource "aws_db_instance" "main" {
                            identifier              = "${local.name_prefix}-db"
                            engine                  = "postgres"
                            instance_class          = var.instance_class
                            allocated_storage       = var.allocated_storage
                            backup_retention_period = local.default_backup_retention_days
                            deletion_protection     = local.is_prod ? true : var.deletion_protection

                            lifecycle {
                            prevent_destroy = true
                            }

                            tags = local.common_tags
                            }

Review production du plan

terraform plan
                            │
                            ▼
                            Review obligatoire
                            ├── destroy ?
                            ├── replace ?
                            ├── DB touchée ?
                            ├── IAM modifié ?
                            ├── réseau ouvert ?
                            ├── DNS changé ?
                            ├── secrets affichés ?
                            └── coût modifié ?
                            │
                            ▼
                            Décision
                            ├── OK : apply contrôlé
                            └── KO : correction avant merge

Production design checklist

Checklist code

Checklist review production

Mini-cheat-sheet

# Naming
                            local.name_prefix = "${var.project}-${var.environment}-${var.component}"

                            # Validation
                            contains(["dev", "staging", "prod"], var.environment)

                            # Prefer stable keys
                            for_each = var.services

                            # Optional resource
                            count = var.enabled ? 1 : 0

                            # Critical resource protection
                            lifecycle {
                            prevent_destroy = true
                            }

                            # Safer production flow
                            terraform fmt -check -recursive
                            terraform validate
                            terraform plan -out=tfplan
                            terraform show -no-color tfplan
                            terraform apply tfplan

Ce qu’il faut inventorier

Template d’inventaire

Resource inventory:
                            - Cloud provider:
                            - Account / project:
                            - Environment:
                            - Resource type:
                            - Resource name:
                            - Provider ID:
                            - Owner:
                            - Criticality:
                            - Dependencies:
                            - Data risk:
                            - Current tags:
                            - Import target address:
                            - Validation command:
                            - Rollback / mitigation:

Ordre recommandé d’import

1. Ressources de base
                            ├── VPC
                            ├── subnets
                            ├── route tables
                            └── security groups

                            2. Ressources partagées
                            ├── IAM roles
                            ├── KMS
                            ├── DNS zones
                            └── certificates

                            3. Ressources applicatives
                            ├── load balancer
                            ├── target groups
                            ├── compute
                            └── autoscaling

                            4. Ressources data
                            ├── databases
                            ├── buckets
                            ├── volumes
                            └── caches

Critères de priorité

Processus import standard

# 1. Écrire le bloc resource minimal
                            resource "aws_security_group" "web" {
                            name   = "prod-web-sg"
                            vpc_id = var.vpc_id
                            }

                            # 2. Importer la ressource existante
                            terraform import aws_security_group.web sg-0123456789abcdef0

                            # 3. Inspecter la ressource importée
                            terraform state show aws_security_group.web

                            # 4. Lancer un plan
                            terraform plan

                            # 5. Compléter le code jusqu'à réduire le diff
                            terraform plan

Exemple import security group

resource "aws_security_group" "api" {
                            name        = "${local.name_prefix}-api-sg"
                            description = "Security group for API service"
                            vpc_id      = var.vpc_id

                            tags = local.common_tags
                            }

                            # Commande import
                            terraform import aws_security_group.api sg-0abc123456789def0

                            # Vérification
                            terraform state show aws_security_group.api
                            terraform plan

Exemple import DNS record

resource "aws_route53_record" "api" {
                            zone_id = var.zone_id
                            name    = "api.example.com"
                            type    = "A"

                            alias {
                            name                   = aws_lb.api.dns_name
                            zone_id                = aws_lb.api.zone_id
                            evaluate_target_health = true
                            }
                            }

                            # L'ID d'import dépend du provider et du type de record.
                            terraform import aws_route53_record.api ZONEID_api.example.com_A

Bloc import

import {
                            to = aws_security_group.api
                            id = "sg-0abc123456789def0"
                            }

                            resource "aws_security_group" "api" {
                            name   = "prod-api-sg"
                            vpc_id = var.vpc_id
                            }

Workflow avec import block

Écrire resource minimal
                            │
                            ▼
                            Ajouter bloc import
                            │
                            ▼
                            terraform plan
                            │
                            ├── vérifie import
                            ├── montre diff restant
                            └── permet review MR
                            │
                            ▼
                            terraform apply
                            │
                            └── state mis à jour
                            │
                            ▼
                            Retirer bloc import après réussite
                            │
                            ▼
                            Commit final propre

Générer une configuration initiale

# Exemple conceptuel
                            terraform plan -generate-config-out=generated.tf

La génération de configuration peut aider à démarrer, mais le fichier généré doit être nettoyé, simplifié, commenté et adapté aux conventions du projet.

Après génération

Détection du drift

# Voir les écarts entre state et infrastructure réelle
                            terraform plan -refresh-only

                            # Mettre à jour le state avec la réalité observée
                            terraform apply -refresh-only

                            # Plan standard après refresh
                            terraform plan

Exemple de drift

Code Terraform
                            instance_type = "t3.small"

                            State Terraform
                            instance_type = "t3.small"

                            Cloud réel
                            instance_type = "t3.medium"

                            Résultat :
                            terraform plan propose de revenir à t3.small
                            ou de modifier le state selon refresh

Causes fréquentes

Décision sur drift

Drift détecté
                            │
                            ▼
                            Changement légitime ?
                            │
                            ├── Oui
                            │     ├── intégrer dans le code
                            │     ├── valider en MR
                            │     └── appliquer proprement
                            │
                            └── Non
                            ├── restaurer état Terraform
                            ├── supprimer changement manuel
                            └── renforcer garde-fou
                            │
                            ▼
                            Documenter la décision

Commandes state utiles

# Lister les ressources
                            terraform state list

                            # Inspecter une ressource
                            terraform state show aws_instance.web

                            # Sauvegarder localement le state
                            terraform state pull > state-backup.json

                            # Déplacer une ressource dans le state
                            terraform state mv aws_instance.web aws_instance.app

                            # Retirer une ressource du state sans la détruire
                            terraform state rm aws_instance.web

Renommer une ressource proprement

# Ancien nom dans le state
                            aws_security_group.web

                            # Nouveau nom dans le code
                            aws_security_group.api

                            # Déplacement state
                            terraform state mv aws_security_group.web aws_security_group.api

                            # Vérification
                            terraform plan

Quand utiliser state mv ?

Quand utiliser state rm ?

Règles production

Change request import prod

Title: Import existing production API security group

                            Scope:
                            - Resource: aws_security_group.api
                            - Provider ID: sg-0abc123456789def0
                            - Environment: production
                            - State: prod/network/terraform.tfstate

                            Risk:
                            - Bad code alignment could create unexpected diff.
                            - Future plans may modify existing SG.

                            Validation:
                            - terraform state show
                            - terraform plan
                            - no unexpected destroy or replace
                            - rules match current production

                            Rollback:
                            - state backup available
                            - terraform state rm if import mapping is wrong

Production import workflow

Inventaire validé
                            │
                            ▼
                            Bloc resource minimal
                            │
                            ▼
                            Import en staging si possible
                            │
                            ▼
                            Review MR
                            │
                            ├── adresse Terraform
                            ├── ID provider
                            ├── backend state
                            ├── lifecycle
                            └── plan attendu
                            │
                            ▼
                            Import production
                            │
                            ▼
                            terraform plan
                            │
                            ├── zéro destroy
                            ├── zéro replace inattendu
                            └── diff expliqué
                            │
                            ▼
                            Commit documentation

Ressources à traiter avec prudence

Sources d’audit

Questions d’audit drift

- Quelle ressource a changé ?
                            - Le code Terraform a-t-il changé ?
                            - Le state a-t-il changé ?
                            - Le cloud réel a-t-il changé ?
                            - Qui a fait l'action ?
                            - Était-ce un hotfix ?
                            - Y a-t-il un ticket ou incident associé ?
                            - Faut-il garder le changement ?
                            - Faut-il le reporter dans Terraform ?
                            - Faut-il renforcer un garde-fou ?

Décision après audit

Drift identifié
                            │
                            ▼
                            Audit
                            ├── action humaine ?
                            ├── action pipeline ?
                            ├── provider externe ?
                            ├── autoscaling normal ?
                            └── incident hotfix ?
                            │
                            ▼
                            Décision
                            ├── codifier dans Terraform
                            ├── restaurer état souhaité
                            ├── ignorer volontairement
                            ├── déplacer ownership
                            └── créer garde-fou
                            │
                            ▼
                            MR + documentation

Exemples de décisions

Procédure import contrôlé

1. Identifier la ressource existante et son ID provider.
                            2. Confirmer environnement, compte cloud et state cible.
                            3. Sauvegarder le state si production.
                            4. Écrire un bloc resource minimal.
                            5. Ajouter lifecycle si ressource critique.
                            6. Lancer terraform import ou utiliser un bloc import.
                            7. Vérifier terraform state list.
                            8. Inspecter terraform state show.
                            9. Lancer terraform plan.
                            10. Ajuster le code jusqu'à diff maîtrisé.
                            11. Vérifier absence de destroy/replace inattendu.
                            12. Documenter mapping resource address ↔ provider ID.
                            13. Faire relire en MR.
                            14. Importer la ressource suivante seulement après validation.

Runbook : traiter un drift

1. Lancer terraform plan -refresh-only.
                            2. Identifier les ressources en drift.
                            3. Vérifier changements récents : Git, pipeline, audit cloud.
                            4. Classer le drift : légitime, accidentel, provider, autoscaling.
                            5. Décider : intégrer dans code ou restaurer état Terraform.
                            6. Créer une MR si changement durable.
                            7. Relire plan standard.
                            8. Appliquer uniquement après validation.
                            9. Documenter cause et action.
                            10. Ajouter garde-fou si nécessaire.

Commandes essentielles

terraform state list
                            terraform state show RESOURCE
                            terraform import RESOURCE PROVIDER_ID
                            terraform plan
                            terraform plan -refresh-only
                            terraform apply -refresh-only
                            terraform state mv OLD NEW
                            terraform state rm RESOURCE
                            terraform state pull > state-backup.json

Checklist avant import

Checklist après import

Checklist drift

Mini-cheat-sheet

# Import classique
                            terraform import RESOURCE_ADDRESS PROVIDER_ID

                            # Inspecter
                            terraform state list
                            terraform state show RESOURCE_ADDRESS

                            # Détecter drift
                            terraform plan -refresh-only

                            # Plan standard
                            terraform plan -out=tfplan
                            terraform show -no-color tfplan

                            # State operations sensibles
                            terraform state pull > state-backup.json
                            terraform state mv OLD_ADDRESS NEW_ADDRESS
                            terraform state rm RESOURCE_ADDRESS

                            # Règle production
                            # Importer petit, planifier souvent, documenter toujours.

Symptômes d’un mauvais modèle CI

Évolution typique de la dette CI

Projet A crée un pipeline
    │
    ▼
Projet B copie le pipeline
    │
    ▼
Projet C adapte une version ancienne
    │
    ▼
Un bug est corrigé dans A seulement
    │
    ▼
Projet B garde une faille
    │
    ▼
Projet C casse production
    │
    ▼
Décision : créer templates communs

Ce qu’un template doit éviter

Include local

include:
  - local: ".gitlab/ci/terraform.yml"
  - local: ".gitlab/ci/security.yml"
  - local: ".gitlab/ci/deploy.yml"

Include depuis un projet central

include:
  - project: "platform/gitlab-ci-templates"
    ref: "v1.4.2"
    file:
      - "/templates/terraform.yml"
      - "/templates/security.yml"
      - "/templates/deploy.yml"

Include remote

include:
  - remote: "https://example.com/gitlab/templates/terraform.yml"

Quel type d’include choisir ?

Structure recommandée

platform/gitlab-ci-templates
    │
    ├── templates/
    │   ├── terraform.yml
    │   ├── security.yml
    │   ├── docker.yml
    │   ├── deploy.yml
    │   └── rules.yml
    │
    ├── examples/
    │   ├── terraform-project.yml
    │   ├── app-project.yml
    │   └── monorepo.yml
    │
    └── CHANGELOG.md

Template caché

.terraform_base:
  image: hashicorp/terraform:1.6.6
  variables:
    TF_IN_AUTOMATION: "true"
    TF_INPUT: "false"
  before_script:
    - cd "$TF_ROOT"
    - terraform --version
    - terraform init -input=false

Job concret qui étend

terraform_validate:
  extends: .terraform_base
  stage: validate
  script:
    - terraform fmt -check -recursive
    - terraform validate

Job plan spécifique

terraform_plan_staging:
  extends: .terraform_base
  stage: plan
  variables:
    TF_ROOT: "infra/live/staging/app"
  script:
    - terraform plan -out=tfplan
    - terraform show -no-color tfplan > plan.txt
  artifacts:
    paths:
      - "$TF_ROOT/tfplan"
      - "$TF_ROOT/plan.txt"
    expire_in: 3 days

Ce que l’on met dans le template

Héritage mental

.terraform_base
    ├── image
    ├── variables communes
    ├── before_script
    └── init

terraform_plan_prod
    ├── extends .terraform_base
    ├── stage plan
    ├── TF_ROOT prod
    ├── plan + artifacts
    └── rules main only

Exemple de bibliothèque de jobs cachés

.rules_merge_request:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

.rules_main:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

.debug_context:
  before_script:
    - echo "Job=$CI_JOB_NAME"
    - echo "Branch=$CI_COMMIT_BRANCH"
    - echo "Source=$CI_PIPELINE_SOURCE"
    - echo "TF_ROOT=${TF_ROOT:-not-set}"

.terraform_base:
  image: hashicorp/terraform:1.6.6
  variables:
    TF_INPUT: "false"
    TF_IN_AUTOMATION: "true"
  before_script:
    - cd "$TF_ROOT"
    - terraform init -input=false

Job final

terraform_plan:
  extends:
    - .terraform_base
    - .rules_merge_request
  stage: plan
  script:
    - terraform plan -out=tfplan
    - terraform show -no-color tfplan > plan.txt

Naming recommandé

Découpage propre

templates/
    ├── rules.yml
    │   ├── .rules_mr
    │   ├── .rules_main
    │   └── .rules_tag
    │
    ├── terraform.yml
    │   ├── .terraform_base
    │   ├── .terraform_validate
    │   ├── .terraform_plan
    │   └── .terraform_apply
    │
    └── security.yml
        ├── .checkov
        ├── .trivy_config
        └── .secret_scan

Variables communes recommandées

Variables au niveau projet

variables:
  APP_NAME: "api"
  TF_ROOT: "infra/live/staging/api"
  DEPLOY_ENV: "staging"
  TF_IN_AUTOMATION: "true"
  TF_INPUT: "false"

Override contrôlé par job

terraform_plan_prod:
  extends: .terraform_plan
  variables:
    TF_ROOT: "infra/live/prod/api"
    DEPLOY_ENV: "production"
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Variables sensibles

Debug sûr

echo "APP_NAME=$APP_NAME"
echo "DEPLOY_ENV=$DEPLOY_ENV"
echo "TF_ROOT=$TF_ROOT"

if [ -z "$AWS_ACCESS_KEY_ID" ]; then
  echo "AWS_ACCESS_KEY_ID is missing"
else
  echo "AWS_ACCESS_KEY_ID is present"
fi

Template Terraform central

.terraform_base:
  image: hashicorp/terraform:1.6.6
  variables:
    TF_INPUT: "false"
    TF_IN_AUTOMATION: "true"
  before_script:
    - echo "TF_ROOT=$TF_ROOT"
    - cd "$TF_ROOT"
    - terraform --version
    - terraform init -input=false

.terraform_validate:
  extends: .terraform_base
  stage: validate
  script:
    - terraform fmt -check -recursive
    - terraform validate

.terraform_plan:
  extends: .terraform_base
  stage: plan
  script:
    - terraform plan -input=false -out=tfplan
    - terraform show -no-color tfplan > plan.txt
    - terraform show -json tfplan > plan.json
  artifacts:
    paths:
      - "$TF_ROOT/tfplan"
      - "$TF_ROOT/plan.txt"
      - "$TF_ROOT/plan.json"
    expire_in: 3 days

.terraform_apply:
  extends: .terraform_base
  stage: apply
  script:
    - terraform apply -input=false tfplan
  when: manual
  allow_failure: false

Utilisation dans un projet

include:
  - project: "platform/gitlab-ci-templates"
    ref: "v1.4.2"
    file:
      - "/templates/terraform.yml"

stages:
  - validate
  - plan
  - apply

variables:
  TF_ROOT: "infra/live/staging/api"

terraform_validate:
  extends: .terraform_validate

terraform_plan:
  extends: .terraform_plan

terraform_apply:
  extends: .terraform_apply
  environment:
    name: staging
  dependencies:
    - terraform_plan

Production protégée

terraform_apply_prod:
  extends: .terraform_apply
  variables:
    TF_ROOT: "infra/live/prod/api"
  environment:
    name: production
  dependencies:
    - terraform_plan_prod
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  tags:
    - protected
    - terraform
    - prod

Risques principaux

Template debug sécurisé

.safe_debug_context:
  script:
    - echo "Job=$CI_JOB_NAME"
    - echo "Branch=$CI_COMMIT_BRANCH"
    - echo "Source=$CI_PIPELINE_SOURCE"
    - echo "Environment=${CI_ENVIRONMENT_NAME:-not-set}"
    - echo "TF_ROOT=${TF_ROOT:-not-set}"
    - pwd
    - ls -la

Contrôles de sécurité à standardiser

Règles de protection

Template repository
    ├── protected main
    ├── MR obligatoire
    ├── approvals DevOps/Security
    ├── tags de release
    ├── changelog
    └── tests d’exemples

Project repository
    ├── include ref tag stable
    ├── variables protected
    ├── environments protected
    └── runner protected for prod

Bon include versionné

include:
  - project: "platform/gitlab-ci-templates"
    ref: "v1.5.0"
    file:
      - "/templates/terraform.yml"
      - "/templates/security.yml"

Mauvais include non maîtrisé

include:
  - project: "platform/gitlab-ci-templates"
    ref: "main"
    file: "/templates/terraform.yml"

Stratégie de versions

Process release template

Modifier template
    │
    ▼
Tester exemples
    │
    ▼
MR review DevOps/Security
    │
    ▼
Merge main
    │
    ▼
Créer tag vX.Y.Z
    │
    ▼
Publier changelog
    │
    ▼
Projets consommateurs migrent volontairement

Changelog minimal

## v1.5.0
Added:
- New .terraform_plan_json job
- New .trivy_config template

Changed:
- Terraform image updated to 1.6.6

Fixed:
- Artifact path handling for nested TF_ROOT

Migration:
- No breaking change

Checklist design template

Checklist projet consommateur

Checklist release template

Mini-cheat-sheet

# Include central
include:
  - project: "platform/gitlab-ci-templates"
    ref: "v1.5.0"
    file:
      - "/templates/terraform.yml"

# Hidden job
.terraform_base:
  image: hashicorp/terraform:1.6.6
  before_script:
    - cd "$TF_ROOT"
    - terraform init

# Extends
terraform_plan:
  extends: .terraform_plan
  variables:
    TF_ROOT: "infra/live/staging/api"

# Must have
- include versionné
- jobs cachés simples
- variables documentées
- artifacts standards
- no secrets in YAML
- protected apply production
- changelog template

Pyramide de tests IaC

Tests post-apply / runtime
                            ├── healthcheck
                            ├── connectivité
                            ├── DNS/TLS
                            └── métriques

                            Tests d'intégration
                            ├── sandbox apply
                            ├── Terratest
                            ├── outputs
                            └── destroy

                            Tests de plan
                            ├── no destroy
                            ├── no public exposure
                            ├── diff attendu
                            └── review humaine

                            Tests statiques
                            ├── terraform fmt
                            ├── terraform validate
                            ├── tflint
                            ├── checkov
                            └── trivy config

Tableau des niveaux

Stratégie par criticité

Commandes locales essentielles

# Initialisation
                            terraform init

                            # Formatage
                            terraform fmt -recursive
                            terraform fmt -check -recursive

                            # Validation syntaxe / providers / modules
                            terraform validate

                            # Voir providers utilisés
                            terraform providers

                            # Plan local avec variables
                            terraform plan -var-file="dev.tfvars"

                            # Plan sauvegardé
                            terraform plan -var-file="dev.tfvars" -out=tfplan
                            terraform show -no-color tfplan

Script local de validation

#!/usr/bin/env bash
                            set -euo pipefail

                            echo "[1/4] terraform fmt"
                            terraform fmt -check -recursive

                            echo "[2/4] terraform init"
                            terraform init

                            echo "[3/4] terraform validate"
                            terraform validate

                            echo "[4/4] terraform plan"
                            terraform plan -var-file="dev.tfvars" -out=tfplan

                            echo "Validation completed."

Erreurs détectées localement

Commandes plan

# Plan standard
                            terraform plan -var-file="prod.tfvars"

                            # Plan sauvegardé
                            terraform plan -var-file="prod.tfvars" -out=tfplan

                            # Plan lisible
                            terraform show -no-color tfplan > plan.txt

                            # Plan JSON pour analyse automatisée
                            terraform show -json tfplan > plan.json

Ce que l’on cherche dans un plan

Tests automatisables sur plan JSON

Exemple de commentaire MR

Terraform plan summary:
                            - Environment: staging
                            - Resources to add: 2
                            - Resources to change: 1
                            - Resources to destroy: 0
                            - Replace: 0
                            - Security impact: no public ingress
                            - Data impact: none
                            - Rollback: revert MR and re-apply previous plan

Diagramme review du plan

Plan généré
                            │
                            ▼
                            Résumé humain
                            │
                            ├── add
                            ├── change
                            ├── replace
                            └── destroy
                            │
                            ▼
                            Contrôles risques
                            ├── réseau
                            ├── IAM
                            ├── DB
                            ├── DNS
                            └── coûts
                            │
                            ▼
                            Approval ou correction

Caractéristiques d’une bonne sandbox

Workflow sandbox

terraform init
                            terraform plan -var-file="sandbox.tfvars" -out=tfplan
                            terraform apply tfplan

                            # Vérifications
                            terraform output
                            curl -fsS https://sandbox.example.com/health/

                            # Nettoyage
                            terraform destroy -var-file="sandbox.tfvars"

Cycle apply / verify / destroy

Sandbox state
                            │
                            ▼
                            terraform apply
                            │
                            ├── ressources créées
                            ├── outputs produits
                            └── tags appliqués
                            │
                            ▼
                            Vérifications
                            ├── cloud resource exists
                            ├── security rules OK
                            ├── DNS/TLS si concerné
                            ├── healthcheck
                            └── logs clean
                            │
                            ▼
                            terraform destroy
                            │
                            ├── nettoyage réussi
                            └── aucun résidu coûteux

Risques sandbox

Contrat à tester

Structure de test module

modules/
                            network/
                            main.tf
                            variables.tf
                            outputs.tf
                            README.md
                            examples/
                            basic/
                            main.tf
                            terraform.tfvars
                            multi_az/
                            main.tf
                            terraform.tfvars
                            tests/
                            README.md

Exemple d’example module

module "network" {
                            source = "../../"

                            project     = "demo"
                            environment = "sandbox"
                            vpc_cidr    = "10.50.0.0/16"

                            private_subnets = {
                            "a" = {
                            cidr_block        = "10.50.1.0/24"
                            availability_zone = "eu-west-3a"
                            }
                            "b" = {
                            cidr_block        = "10.50.2.0/24"
                            availability_zone = "eu-west-3b"
                            }
                            }
                            }

Tests simples sans Terratest

cd modules/network/examples/basic

                            terraform init
                            terraform fmt -check -recursive
                            terraform validate
                            terraform plan -out=tfplan
                            terraform apply tfplan
                            terraform output
                            terraform plan
                            terraform destroy

Quand utiliser Terratest ?

Cycle Terratest

go test
                            │
                            ▼
                            terraform init
                            │
                            ▼
                            terraform apply
                            │
                            ▼
                            Assertions
                            ├── outputs
                            ├── cloud resources
                            ├── HTTP endpoint
                            ├── tags
                            └── security rules
                            │
                            ▼
                            terraform destroy
                            │
                            ▼
                            test result

Exemple Terratest simplifié

package test

                            import (
                            "testing"

                            "github.com/gruntwork-io/terratest/modules/terraform"
                            "github.com/stretchr/testify/assert"
                            )

                            func TestNetworkModule(t *testing.T) {
                            t.Parallel()

                            options := &terraform.Options{
                            TerraformDir: "../examples/basic",
                            Vars: map[string]interface{}{
                            "project":     "demo",
                            "environment": "test",
                            },
                            }

                            defer terraform.Destroy(t, options)

                            terraform.InitAndApply(t, options)

                            vpcId := terraform.Output(t, options, "vpc_id")
                            assert.NotEmpty(t, vpcId)
                            }

Précautions Terratest

Outils fréquents

Commandes scan

# Checkov
                            checkov -d .

                            # tfsec
                            tfsec .

                            # Trivy IaC
                            trivy config .

                            # TFLint
                            tflint --init
                            tflint

Contrôles sécurité à bloquer

Politique d’exception

Exception security scan:
                            - Rule:
                            - Resource:
                            - Environment:
                            - Reason:
                            - Risk accepted by:
                            - Expiration date:
                            - Compensating control:
                            - Ticket:

Pipeline GitLab Terraform tests

stages:
                            - lint
                            - validate
                            - security
                            - plan
                            - integration

                            variables:
                            TF_IN_AUTOMATION: "true"
                            TF_INPUT: "false"
                            TF_ROOT: "infra/live/staging/app"

                            default:
                            image: hashicorp/terraform:1.6.6
                            before_script:
                            - cd "$TF_ROOT"
                            - terraform init

                            terraform_fmt:
                            stage: lint
                            script:
                            - terraform fmt -check -recursive

                            terraform_validate:
                            stage: validate
                            script:
                            - terraform validate

                            terraform_security:
                            stage: security
                            image: bridgecrew/checkov:latest
                            before_script: []
                            script:
                            - checkov -d infra
                            allow_failure: false

                            terraform_plan:
                            stage: plan
                            script:
                            - terraform plan -out=tfplan
                            - terraform show -no-color tfplan > plan.txt
                            artifacts:
                            paths:
                            - "$TF_ROOT/tfplan"
                            - "$TF_ROOT/plan.txt"
                            expire_in: 3 days

Job Terratest optionnel

terratest_network:
                            stage: integration
                            image: golang:1.22
                            before_script:
                            - apt-get update && apt-get install -y unzip
                            - cd modules/network/tests
                            script:
                            - go test -v -timeout 45m
                            rules:
                            - changes:
                            - modules/network/**/*
                            when: manual

Stratégie CI recommandée

Checklist avant MR

Checklist module

Checklist sandbox / intégration

Mini-cheat-sheet

# Local
                            terraform fmt -check -recursive
                            terraform init
                            terraform validate
                            terraform plan -out=tfplan
                            terraform show -no-color tfplan

                            # Security
                            checkov -d .
                            tfsec .
                            trivy config .
                            tflint --init
                            tflint

                            # Sandbox
                            terraform apply tfplan
                            terraform output
                            curl -fsS https://sandbox.example.com/health/
                            terraform destroy

                            # Terratest
                            go test -v -timeout 45m

                            # Plan JSON
                            terraform show -json tfplan > plan.json

Principales sources de coût

Exemples de pièges coûteux

• Une NAT gateway créée en dev alors qu’elle n’est pas nécessaire.
• Des logs debug envoyés en continu vers une plateforme payante.
• Une base de données staging dimensionnée comme la production.
• Des snapshots conservés indéfiniment sans policy de rétention.
• Des environnements de test créés par CI mais jamais détruits.
• Un load balancer par petite application au lieu d’une mutualisation réfléchie.

Tableau coût / risque / contrôle

Diagramme des coûts invisibles

Terraform apply
    │
    ├── ressource principale visible
    │     └── instance / DB / LB
    │
    └── coûts associés parfois oubliés
          ├── stockage attaché
          ├── snapshots
          ├── logs
          ├── trafic sortant
          ├── NAT
          ├── monitoring
          ├── backups
          └── IP publiques

Tags obligatoires recommandés

Locals Terraform pour tags

locals {
  common_tags = merge(
    {
      Project     = var.project
      Environment = var.environment
      Owner       = var.owner
      CostCenter  = var.cost_center
      ManagedBy   = "terraform"
    },
    var.extra_tags
  )
}

Application des tags

resource "aws_instance" "app" {
  ami           = var.ami_id
  instance_type = var.instance_type

  tags = merge(local.common_tags, {
    Name = "${local.name_prefix}-app"
  })
}

Politique de tags

Contrôle CI possible

# Exemple principe :
# Bloquer si une ressource taggable n'a pas les tags obligatoires :
# - Project
# - Environment
# - Owner
# - CostCenter
# - ManagedBy

Questions coût dans une review de plan

Résumé MR recommandé

Cost impact:
- Environment: staging
- New resources: 1 load balancer, 2 instances
- Removed resources: none
- Monthly cost impact: estimated +120 EUR/month
- Main cost drivers: load balancer + compute
- Tags: Project, Environment, Owner, CostCenter OK
- Budget alert: existing staging budget
- Cleanup: not temporary

Diagramme review coût

terraform plan
    │
    ▼
Identifier ressources coûteuses
    ├── compute
    ├── DB
    ├── NAT
    ├── LB
    ├── logs
    ├── storage
    └── egress
          │
          ▼
Évaluer
    ├── coût mensuel
    ├── coût variable
    ├── coût fixe
    ├── owner
    └── durée de vie
          │
          ▼
Décision
    ├── OK
    ├── réduire sizing
    ├── mutualiser
    ├── ajouter TTL
    └── refuser / revoir design

Diff Terraform à surveiller

Outils liés à Terraform

Exemple Infracost en CI

# Exemple conceptuel
terraform plan -out=tfplan
terraform show -json tfplan > plan.json

infracost breakdown \
  --path plan.json \
  --format table

infracost diff \
  --path plan.json \
  --format json \
  --out-file infracost.json

Outils cloud natifs

Architecture FinOps

Terraform plan
    │
    ├── Infracost estimate
    ├── policy-as-code
    └── MR comment
          │
          ▼
Cloud billing
    ├── budgets
    ├── anomaly detection
    ├── cost explorer
    └── billing export
          │
          ▼
FinOps dashboard
    ├── coût par projet
    ├── coût par environnement
    ├── coût par équipe
    └── dérives mensuelles

Seuils de budget recommandés

Exemple de politique budget

Budget policy:
- Project: ideo-platform
- Environment: staging
- Monthly budget: 300 EUR
- Warning: 75%
- Critical: 100%
- Owner: platform-team
- Notification: Slack #finops-alerts
- Review frequency: weekly
- Action: identify top cost drivers and cleanup unused resources

Détection d’anomalie coût

Facture quotidienne
    │
    ▼
Comparaison baseline
    │
    ├── coût normal
    ├── hausse progressive
    └── pic brutal
          │
          ▼
Analyse
    ├── nouvelle ressource Terraform
    ├── trafic réseau
    ├── logs volumineux
    ├── DB storage
    ├── sandbox oubliée
    └── incident applicatif
          │
          ▼
Action
    ├── cleanup
    ├── resize
    ├── retention
    ├── rollback
    └── validation owner

Actions après alerte budget

Variables contrôlées

variable "instance_type" {
  description = "Approved instance type."
  type        = string

  validation {
    condition = contains([
      "t3.micro",
      "t3.small",
      "t3.medium"
    ], var.instance_type)

    error_message = "Instance type is not approved."
  }
}

variable "log_retention_days" {
  description = "Log retention in days."
  type        = number
  default     = 14

  validation {
    condition     = var.log_retention_days <= 30
    error_message = "Log retention must be lower than or equal to 30 days."
  }
}

Defaults selon environnement

locals {
  is_prod = var.environment == "prod"

  default_instance_type = local.is_prod ? "t3.medium" : "t3.micro"
  backup_retention_days = local.is_prod ? 14 : 3
  log_retention_days    = local.is_prod ? 30 : 7
}

Tags + TTL pour ressources temporaires

locals {
  common_tags = merge(
    {
      Project     = var.project
      Environment = var.environment
      Owner       = var.owner
      CostCenter  = var.cost_center
      ManagedBy   = "terraform"
    },
    var.temporary ? {
      Temporary = "true"
      ExpireAt  = var.expire_at
    } : {}
  )
}

Patterns FinOps Terraform

Pipeline FinOps type

Merge Request
    │
    ▼
terraform fmt / validate
    │
    ▼
terraform plan -out=tfplan
    │
    ▼
plan.json
    │
    ├── scan sécurité
    ├── contrôle tags
    ├── estimation coût
    └── policy-as-code
          │
          ▼
MR comment
    ├── delta coût
    ├── ressources coûteuses
    ├── tags manquants
    └── risques FinOps
          │
          ▼
Approval ou correction

Exemple job coût

terraform_cost_estimate:
  stage: plan
  image: infracost/infracost:ci-0.10
  script:
    - terraform show -json tfplan > plan.json
    - infracost breakdown --path plan.json --format table
  dependencies:
    - terraform_plan
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Contrôles CI FinOps

Exemple commentaire MR

FinOps review:
- Monthly cost delta: +85 EUR
- Main driver: new staging load balancer
- Required tags: OK
- Temporary resource: no
- Budget impact: within staging budget
- Recommendation: accepted if LB cannot be shared

Optimisations production raisonnables

Workflow optimisation prod

Coût élevé détecté
    │
    ▼
Identifier cost driver
    ├── compute
    ├── DB
    ├── network
    ├── storage
    └── logs
          │
          ▼
Analyser usage réel
    ├── 7 jours
    ├── 30 jours
    ├── pics
    └── saisonnalité
          │
          ▼
Proposer changement
    ├── gain attendu
    ├── risque
    ├── rollback
    └── owner
          │
          ▼
Apply contrôlé
          │
          ▼
Surveillance post-change

Post-check après optimisation

Checklist review Terraform

Checklist optimisation

Checklist CI/CD FinOps

Mini-cheat-sheet

# Terraform plan cost flow
terraform plan -out=tfplan
terraform show -json tfplan > plan.json
terraform show -no-color tfplan > plan.txt

# Cost tools
infracost breakdown --path plan.json
checkov -d .
trivy config .

# Tags minimum
Project
Environment
Owner
CostCenter
ManagedBy

# Review questions
- What is the monthly delta?
- What is the main cost driver?
- Is the resource temporary?
- Are tags complete?
- Is a budget alert configured?
- Is the size justified by metrics?

Template MR recommandé

## Context
Why is this change needed?
- Business / technical reason:
- Related ticket:
- Target environment:
- Affected service:

## Scope
What changes?
- Terraform root:
- Modules changed:
- Resources affected:
- Cloud account / region:

## Terraform plan summary
- To add:
- To change:
- To destroy:
- To replace:
- Sensitive resources touched:

## Risk analysis
- Availability impact:
- Security impact:
- Data impact:
- Cost impact:
- Operational complexity:

## Validation
- terraform fmt: OK
- terraform validate: OK
- security scan: OK
- terraform plan reviewed: OK
- staging tested: yes / no / not applicable

## Rollback / mitigation
- Rollback method:
- Mitigation if rollback is not immediate:
- Owner during deployment:

## Production window
- Required: yes / no
- Preferred window:
- People required:

## Post-checks
- Health checks:
- Logs:
- Metrics:
- Alerts:
- Business test:

## Notes for reviewers
- Specific lines or resources to review:
- Known limitations:
- Questions:

Version courte pour petits changements

## Summary
Short description of the infrastructure change.

## Environment
dev / staging / prod

## Plan
Add:
Change:
Destroy:
Replace:

## Risk
Low / Medium / High
Reason:

## Validation
- fmt OK
- validate OK
- plan reviewed
- no unexpected destroy

## Rollback
How to revert or mitigate.

## Post-check
What to verify after apply.

Quand utiliser quel template ?

Commandes de plan recommandées

terraform fmt -check -recursive
terraform validate

terraform plan -var-file="prod.tfvars" -out=tfplan
terraform show -no-color tfplan > plan.txt
terraform show -json tfplan > plan.json

Résumé de plan à mettre dans la MR

Terraform plan summary:
- Environment: production
- Terraform root: infra/live/prod/api
- Resources to add: 2
- Resources to change: 1
- Resources to destroy: 0
- Resources to replace: 0

Sensitive areas:
- Network: no public ingress added
- IAM: no wildcard permission
- Database: not touched
- DNS: not touched
- Cost impact: estimated +40 EUR/month

Plan artifact:
- plan.txt attached in pipeline artifacts

Lecture du plan : symboles

Zones sensibles à extraire

Grille de risque

Bloc “Risk analysis” prêt à coller

Risk analysis:
- Availability impact: low / medium / high
- Security impact: low / medium / high
- Data impact: none / low / medium / high
- Cost impact: none / low / medium / high
- Rollback complexity: simple / moderate / complex
- Production window required: yes / no

Risk explanation:
This change modifies ...
The main risk is ...
The mitigation is ...

Diagramme de décision

MR Terraform
    │
    ▼
Touche production ?
    │
    ├── Non
    │     └── review standard
    │
    └── Oui
          │
          ▼
Touche DB, IAM, réseau, DNS ou state ?
          │
          ├── Oui
          │     ├── review senior
          │     ├── approval renforcé
          │     ├── rollback documenté
          │     └── fenêtre si nécessaire
          │
          └── Non
                ├── plan review
                └── post-checks

Questions de risque obligatoires

Rollback par type de changement

Bloc MR rollback

Rollback / mitigation:
- Preferred rollback:
  Revert this MR and apply the previous Terraform plan.

- If immediate rollback is unsafe:
  Apply a minimal mitigation:
  - restore previous security group rule
  - disable new listener rule
  - switch DNS back to previous target

- Validation after rollback:
  - health endpoint OK
  - 5xx rate stable
  - latency p95 stable
  - no new critical alert

- Owner during rollback:
  Platform team / on-call DevOps

Diagramme rollback

Incident après apply
    │
    ▼
Identifier changement responsable
    │
    ▼
Rollback simple possible ?
    │
    ├── Oui
    │     ├── revert commit
    │     ├── terraform plan
    │     ├── review du rollback plan
    │     └── terraform apply
    │
    └── Non
          ├── mitigation minimale
          ├── correction ciblée
          ├── backup / restore si data
          └── escalade expert
    │
    ▼
Post-checks
    ├── health
    ├── logs
    ├── metrics
    └── alerts

Commandes de rollback contrôlé

# Revenir au commit précédent par revert
git revert <commit_id>
git push origin main

# Générer un plan de rollback
terraform plan -var-file="prod.tfvars" -out=tfplan
terraform show -no-color tfplan > rollback-plan.txt

# Appliquer seulement après review
terraform apply tfplan

Checklist reviewer

Commentaires reviewer utiles

Good review comments:

- The plan shows a replacement of the load balancer.
  Is this expected? What is the downtime risk?

- This security group opens port 5432 to a broad CIDR.
  Can we restrict it to the application security group?

- The new database has deletion protection disabled.
  Is this intentional for production?

- This resource is missing CostCenter and Owner tags.

- Rollback mentions revert only.
  Can you add the exact validation steps after rollback?

Questions à poser

Matrice d’approbation

Critères Go / No-Go

Flux approval production

MR ouverte
    │
    ▼
Pipeline vert
    │
    ├── fmt
    ├── validate
    ├── security scan
    ├── plan
    └── cost estimate
          │
          ▼
Review technique
          │
          ▼
Review risque
    ├── réseau
    ├── IAM
    ├── data
    ├── state
    └── coût
          │
          ▼
Approval
          │
          ▼
Merge
          │
          ▼
Apply manuel protégé

GitLab protections utiles

Pipeline MR recommandé

stages:
  - lint
  - validate
  - security
  - plan
  - cost

variables:
  TF_IN_AUTOMATION: "true"
  TF_INPUT: "false"
  TF_ROOT: "infra/live/staging/app"

default:
  image: hashicorp/terraform:1.6.6
  before_script:
    - cd "$TF_ROOT"
    - terraform init

terraform_fmt:
  stage: lint
  script:
    - terraform fmt -check -recursive

terraform_validate:
  stage: validate
  script:
    - terraform validate

terraform_plan:
  stage: plan
  script:
    - terraform plan -out=tfplan
    - terraform show -no-color tfplan > plan.txt
    - terraform show -json tfplan > plan.json
  artifacts:
    paths:
      - "$TF_ROOT/tfplan"
      - "$TF_ROOT/plan.txt"
      - "$TF_ROOT/plan.json"
    expire_in: 3 days

Contrôles CI à inclure

Debug CI sécurisé

echo "Branch: $CI_COMMIT_BRANCH"
echo "Environment: $CI_ENVIRONMENT_NAME"
echo "Terraform root: $TF_ROOT"
terraform --version

# Vérifier présence sans exposer
if [ -z "$AWS_ACCESS_KEY_ID" ]; then
  echo "AWS_ACCESS_KEY_ID is missing"
  exit 1
else
  echo "AWS_ACCESS_KEY_ID is present"
fi

Exemple 1 : ajout d’une alarme CloudWatch / monitoring

Summary:
Add CPU and HTTP 5xx alerts for production API.

Environment:
production

Plan:
- Add: 2 monitoring alarms
- Change: 0
- Destroy: 0
- Replace: 0

Risk:
Low. No runtime resource is modified.
Only monitoring resources are added.

Validation:
- terraform fmt OK
- terraform validate OK
- terraform plan reviewed
- no destroy
- alert names and thresholds checked

Rollback:
Revert MR and apply previous plan.

Post-check:
- Alarms visible in monitoring console
- Notification channel receives test event

Exemple 2 : modification security group DB

Summary:
Allow API service security group to reach PostgreSQL on port 5432.

Environment:
production

Plan:
- Add: 1 ingress rule
- Change: 1 security group
- Destroy: 0
- Replace: 0

Risk:
Medium/high. Network access to DB is modified.
No public CIDR is introduced.
Source is restricted to API security group.

Validation:
- plan reviewed
- no 0.0.0.0/0
- staging connectivity tested
- DB logs monitored

Rollback:
Remove the ingress rule by reverting this MR.
If urgent, apply minimal SG rule rollback.

Post-check:
- API can connect to DB
- no new DB connection errors
- 5xx stable

Exemple 3 : changement de taille instance

Summary:
Increase staging worker instance type from t3.micro to t3.small.

Environment:
staging

Reason:
Current workers show sustained CPU saturation during batch tests.

Plan:
- Change: worker launch template instance_type
- Replace: rolling replacement through autoscaling
- Destroy: 0 direct unmanaged destroy

Risk:
Medium. Temporary capacity fluctuation during rollout.

Cost impact:
Estimated +25 EUR/month in staging.

Rollback:
Revert instance_type to t3.micro and apply.
If saturation returns, reduce batch concurrency.

Post-check:
- workers healthy
- queue backlog decreasing
- CPU below 70%
- no failed jobs

Exemple 4 : import ressource existante

Summary:
Import existing production API security group into Terraform state.

Environment:
production

Resource:
- Terraform address: aws_security_group.api
- Provider ID: sg-0abc123456789def0
- State key: prod/network/terraform.tfstate

Plan:
- Import only
- Expected diff: tags normalization
- Destroy: 0
- Replace: 0

Risk:
Medium. Future plans may modify this SG if code is not aligned.

Validation:
- state backup created
- terraform state show reviewed
- plan reviewed
- no unexpected rule deletion

Rollback:
terraform state rm aws_security_group.api if mapping is wrong,
using state backup if needed.

Checklist auteur de MR

Checklist reviewer

Checklist production

Mini-cheat-sheet MR infra

MR Terraform must include:
- Context
- Environment
- Terraform root
- Plan summary
- Risk analysis
- Security impact
- Cost impact
- Rollback / mitigation
- Post-checks
- Reviewers / approvals

Commands:
terraform fmt -check -recursive
terraform validate
terraform plan -out=tfplan
terraform show -no-color tfplan > plan.txt
terraform show -json tfplan > plan.json

Politique de branches recommandée

Règles à appliquer sur main

• Interdire le push direct.
• Autoriser le merge seulement aux Maintainers ou Owners.
• Exiger pipeline vert avant merge.
• Exiger une ou plusieurs approvals.
• Empêcher la suppression de la branche.
• Limiter les variables production aux branches protégées.

Flux Git attendu

feature/infra-change
    │
    ▼
Merge Request
    │
    ├── pipeline MR
    ├── plan artifact
    ├── review
    └── approval
          │
          ▼
main protected
    │
    ▼
Pipeline production
    │
    ├── plan final
    ├── apply manual
    └── protected environment

Erreurs fréquentes

Modèle d’environnements

Job apply production

terraform_apply_prod:
  stage: apply
  environment:
    name: production
  script:
    - terraform apply tfplan
  when: manual
  allow_failure: false
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  tags:
    - protected
    - terraform
    - prod

Chaîne environment protection

main protected
    │
    ▼
pipeline production
    │
    ▼
manual job apply_prod
    │
    ├── environment: production
    ├── protected environment
    ├── protected variables
    ├── protected runner
    └── authorized deployers only
          │
          ▼
terraform apply production

À protéger explicitement

Matrice d’approbation infra

Règle simple

Low risk:
  1 reviewer

Medium risk:
  1 DevOps reviewer + plan artifact

High risk:
  2 reviewers + rollback documented

Critical:
  2 reviewers + expert approval + production window + post-checks

Décision approval par impact

MR Terraform
    │
    ▼
Environment = production ?
    │
    ├── No
    │     └── standard approval
    │
    └── Yes
          │
          ▼
Touches sensitive area ?
    ├── IAM
    ├── network
    ├── DNS
    ├── database
    ├── state
    └── secrets
          │
          ▼
Yes: expert reviewer required
No: standard prod reviewer
          │
          ▼
Pipeline green + approval
          │
          ▼
Merge / apply manual

Approval ne doit pas être automatique

Modèle de rôles recommandé

Séparer contribution et exécution

Developer
    ├── écrit Terraform
    ├── ouvre MR
    └── lit le plan

Reviewer
    ├── relit code
    ├── relit plan
    └── approuve

Authorized deployer
    ├── déclenche apply
    ├── surveille production
    └── documente résultat

Least privilege GitLab + cloud

Exemple de séparation plan/apply

terraform_plan_prod:
  stage: plan
  environment:
    name: production
  script:
    - terraform plan -out=tfplan
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

terraform_apply_prod:
  stage: apply
  environment:
    name: production
  script:
    - terraform apply tfplan
  when: manual
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Règles production

Runbook apply production

Before apply:
- MR approved
- pipeline green
- plan reviewed
- no unexpected destroy/replace
- rollback documented
- dashboards open
- production window confirmed if needed

During apply:
- trigger manual job
- monitor job logs
- do not run concurrent apply

After apply:
- run health checks
- check logs
- check metrics
- check alerts
- document result

Timeline production

T-30 min
    ├── confirm approval
    ├── review latest plan
    ├── open dashboards
    └── announce change

T0
    ├── trigger manual apply
    └── monitor pipeline

T+5 min
    ├── verify cloud resources
    ├── healthcheck
    └── logs

T+15 min
    ├── metrics
    ├── alerts
    └── business smoke test

T+30 min
    ├── close change
    └── document outcome

Post-checks à exiger

Exemple CODEOWNERS infra

# Global infrastructure owners
/infra/ @platform-team

# Production requires SRE review
/infra/live/prod/ @sre-team @platform-leads

# IAM and security-sensitive files
/infra/modules/iam/ @security-team @platform-team
/infra/**/iam*.tf @security-team

# Network
/infra/modules/network/ @network-team @platform-team
/infra/**/security_group*.tf @platform-team

# Databases
/infra/modules/database/ @dba-team @sre-team
/infra/**/rds*.tf @dba-team

# CI templates
/.gitlab/ci/ @devops-team
/.gitlab-ci.yml @devops-team

Mapping fichiers → reviewers

Pièges CODEOWNERS

Variables GitLab à protéger

Mapping recommandé

DEV credentials:
  protected: false or limited
  environment scope: development

STAGING credentials:
  protected: true if release branches are protected
  environment scope: staging

PROD credentials:
  protected: true
  environment scope: production
  available only from main / protected tags

OIDC et credentials courts

GitLab protected job
    │
    ▼
OIDC token
    │
    ▼
Cloud IAM trust policy
    ├── project allowed
    ├── branch allowed
    ├── environment allowed
    └── audience checked
          │
          ▼
Temporary credentials
    │
    ▼
Terraform plan/apply

Debug sécurisé

# Good: check presence only
if [ -z "$AWS_ACCESS_KEY_ID" ]; then
  echo "AWS_ACCESS_KEY_ID is missing"
  exit 1
else
  echo "AWS_ACCESS_KEY_ID is present"
fi

# Bad: exposes secrets
env
printenv
echo "$AWS_SECRET_ACCESS_KEY"
set -x

Éléments à auditer

Questions d’audit post-change

- Who approved the MR?
- Was the pipeline green before merge?
- Which plan artifact was reviewed?
- Who triggered production apply?
- Which protected environment was used?
- Which cloud role executed the change?
- Were there unexpected destroy/replace actions?
- Were post-checks completed?
- Was rollback documented?

Audit trail idéal

MR approved
    │
    ├── approver identity
    ├── plan artifact
    ├── discussion history
    └── risk acceptance
          │
          ▼
Pipeline apply
    │
    ├── manual trigger user
    ├── protected environment
    ├── protected runner
    └── job logs
          │
          ▼
Cloud audit
    │
    ├── assumed role
    ├── API calls
    ├── resources changed
    └── timestamp
          │
          ▼
Post-change evidence
    ├── health checks
    ├── metrics
    ├── logs
    └── incident/change ticket

À conserver

Checklist GitLab project

Checklist MR production

Checklist sécurité des droits

Mini-cheat-sheet

Must have:
- Protected branch main
- No direct push to main
- Required pipeline success
- MR approvals
- CODEOWNERS for sensitive paths
- Protected production environment
- Manual apply for production
- Protected and scoped variables
- Protected runner for production
- Regular access review

Sensitive paths:
infra/live/prod/**
infra/modules/iam/**
infra/modules/network/**
infra/modules/database/**
.gitlab-ci.yml