Infrastructure as Code: Terraform, Ansible

Infrastructure as Code: Terraform, Ansible

1) Pourquoi l'IaC et ce que les outils diffèrent

Terraform est un orchestrateur-IaC déclaratif : crée/modifie l'infrastructure cloud (VPC, K8s, LB, OBD, IAM) par l'intermédiaire des fournisseurs. Gère le cycle de vie des ressources et stocke l'état.
Ansible est un bou-IaC procédural et de gestion de la configuration : configure les hôtes/logiciels (paquets, fichiers, services), sait anticiper les applications, timplate, orchestration des étapes. Sans agent (SSH/WinRM), avec idempotence des tâches.

Combinaison : Terraform - « de quoi est faite la plate-forme », Ansible - « comment il est configuré et démarré ».

2) Structure des dépôts et des couches

1. Foundation (Landing Zone) : réseaux, IAM, KMS, journaux de base/surveillance.

2. Platform : clusters Kubernetes, bases, files d'attente, stack observability.

3. Workloads : espaces/neimspace, comptes de service, politiques, configs.

• 'iac/terraform/' - modules et environnements ('modules/',' envs/').
• 'iac/ansible/' - rôles ('roles/'), playbooks (' playbooks/'), inventaires ('inventories/').
• « politiques/ » - Règles OPA/Conftest.
• « pipelines/ » - scripts CI/CD (lint/plan/apply/test).

3) Terraform : modules, steat, environnement

3. 1 modules

Petits, surutilisés : 'vpc', 'eks', 'rds', 'redis', 'alb', 'iam-role'.
Entrées → 'variables. tf ', sorties →' outputs. tf ', versions - via le registre des modules/balises git.

hcl module "vpc" {
source = "git::ssh://git@repo/iac. git//modules/vpc? ref=v1. 6. 0"
name  = "prod-core"
cidr  = "10. 0. 0. 0/16"
azs  = ["eu-central-1a","eu-central-1b"]
}

3. 2 État (état)

Backend distant (S3/GCS + DynamoDB/LockTable) + verrous.
Division par environnement : 'prod. tfstate`, `staging. tfstate`.
State-drift : 'terraform plan' dans CI comme prévu ; alert à la dérive.

hcl terraform {
backend "s3" {
bucket     = "iac-state"
key      = "prod/network/terraform. tfstate"
region     = "eu-central-1"
dynamodb_table = "iac-locks"
encrypt    = true
}
}

3. 3 Workspaces / Envs

• Catalogues individuels 'envs/prod', 'envs/stage' (visible).
• Workspaces pour des variations faciles, mais évitez de mélanger les secrets.
• Paramètres via 'tfvars' : 'prod. tfvars`, `stage. tfvars`.

4) Ansible : rôles, inventaires, idempotence

4. 1 Rôles et playbooks

roles/
nginx/
tasks/main. yml templates/.j2 handlers/main. yml defaults/main. yml playbooks/
site. yml

yaml
- hosts: web become: true roles:
- role: nginx vars:
nginx_listen_port: 8080

4. 2 Inventaires et dynamique

`inventories/prod/hosts. yml '+ variables'group _ vars/host _ vars '.
Inventaire dynamique : 'aws _ ec2', 'gcp _ compute', 'kubernetes. core`.

4. 3 Idempotence

Utilisez les modules (pas 'shell') là où c'est possible.
'Changed _ when '/' check _ mode 'pour les courses sèches.
Les handlers ne réfléchissent qu'en cas de changement.

5) Secrets et confidences

Terraform : sécrétion de valeurs via 'sensible = vrai' ; les secrets eux-mêmes ne sont pas dans l'état (gardez AWS Secrets Manager/HashiCorp Vault/KMS et référencez la source de données).
Ansible : Vault pour le chiffrement des variables ('ansible-vault encrypt'), intégration avec HashiCorp Vault/KMS.
GitOps : secrets dans un repo/stockage séparé, accès par least-privilège.

6) Politiques et conformité (Policy as Code)

OPA/Conftest pour les plans Terraform : interdiction des S3 publics ouverts par SG, ressources non coupées (tags).
Terraform Cloud/Enterprise - Sentinel comme alternative.
Ansible Lint : style et sécurité (sans 'sudo : yes' où tu n'as pas besoin, sans raw-shell).

rego package terraform. security

deny[msg] {
input. resource_type == "aws_security_group_rule"
input. values. cidr_blocks[_] == "0. 0. 0. 0/0"
input. values. from_port == 22 msg:= "SSH from 0. 0. 0. 0/0 is forbidden"
}

7) Test IaC

Terraform : 'tflint', 'tfsec '/' checkov', Terratest (Go) pour les contrôles d'intégration.
Ansible : 'ansible-lint', Molecule (+ Docker/Podman/EC2) pour vérifier les rôles.
Smoak tests après apply : HTTP probes, port/processus, droits.

8) CI/CD и GitOps

1. Lint/Sec: tflint, tfsec/checkov, ansible-lint.

2. Plan : 'terraform plan' avec publication d'un artefact (commentaire dans MR).

3. Policy Gate: Conftest/Sentinel.

4. Apply (manuel/approved) : uniquement sur le main avec la signature des artefacts.

5. Ansible deploy : '--check' sur la scène, puis '--diff' sur prod.

6. Post-checks : Synthétique/Probe, annotation de sortie.

• Gardez les manifestes comme source de vérité ; Argo CD/Flux pour Kubernetes, mais les clusters/primitives de base sont via Terraform.

9) Modèles pour Kubernetes, réseaux, OBD

9. 1 Kubernetes

Terraform : EKS/GKE/AKS clusters, nœuds, IAM, StorageClass, LB.
Ansible : préparation AMI/bastions, assemblage d'images/référentiel, post-installation (loggers/agents/OTel).

9. 2 Réseaux et périmètre

Terraform : VPC/sous-réseaux/NAT/Transit-Gateway/WAF, itinéraires.
Ansible : config NGINX/Envoy/HAProxy, TLS, configi WAF des règles.

9. 3 Bases/caches/files d'attente

Terraform : RDS/CloudSQL paramètre de groupe, Redis/ElastiCache, Kafka/MSK.
Ansible : échauffement du cache, tâches de migration, configuration des backups/agents.

10) Exemples de configues

10. 1 Terraform — RDS PostgreSQL + SG

hcl module "db" {
source        = "terraform-aws-modules/rds/aws"
engine        = "postgres"
engine_version    = "15. 4"
instance_class    = "db. m6g. large"
allocated_storage  = 100 name         = "core"
username       = var. db_user password       = var. db_password # см. secret data source vpc_security_group_ids = [module. db_sg. security_group_id]
multi_az       = true backup_retention   = 7
}

module "db_sg" {
source = "terraform-aws-modules/security-group/aws"
name  = "db-core"
vpc_id = module. vpc. vpc_id ingress_cidr_blocks = ["10. 0. 0. 0/8"]
ingress_rules    = ["postgresql-tcp"]
}

10. 2 Terraform - la source de données du secret

hcl data "aws_secretsmanager_secret_version" "db" {
secret_id = "prod/db/core"
}
variable "db_password" {
type   = string sensitive = true default  = jsondecode(data. aws_secretsmanager_secret_version. db. secret_string). password
}

10. 3 Ansible - rôle postgresql-client (fragment)

yaml
- name: Install packages apt:
name: [ "postgresql-client-15" ]
state: present update_cache: yes

- name: Create. pgpass copy:
dest: /home/deploy/.pgpass mode: '0600'
content: "{{ db_host }}:5432:core:{{ db_user }}:{{ db_password }}"
no_log: true

- name: Smoke query shell: psql -h {{ db_host }} -U {{ db_user }} -d core -c "select 1"
register: psql_out changed_when: false

10. 4 Ansible - NGINX avec timplate

yaml
- name: Deploy nginx. conf template:
src: templates/nginx. conf. j2 dest: /etc/nginx/nginx. conf notify: Restart nginx

- name: Ensure nginx running service:
name: nginx state: started enabled: true

handlers:
- name: Restart nginx service: { name: nginx, state: restarted }

11) Gestion de la dérive et de la conformité

Un 'terraform plan' périodique dans la clé read-only ; crée un tiquet en cas de divergence.
Ansible --check programmé pour les rôles critiques (mode audit).
Rapports : Politiques OPA/Conftest non appliquées, ressources sans tags/backup/monitoring.

12) Observation et audit

Logs 'terraform apply' et artefacts de plans - conservez-le dans le stockage objet.
Ansible : 'callback _ plugins' (json) → journal central/ELK ; incluez job ID, commit SHA, trace_id.
Métriques : temps d'exécution des plans/pleybuks, taux de changement, couverture par les tests.

13) Sécurité

Signature des modules/rôles ou balises/hachages fixes.
Droits IAM minimaux ('plan' ≠ 'apply'), séparez les rôles CI et Homme-Appriver.
Cryptage des états/logs, registres privés des modules/rôles.
La politique « no pleintext secrets in VCS », les scanners secrets (gitleaks/trufflehog).

14) Anti-modèles

Un module monstre Terraform « par tous » ; pas de versions des modules.
Local 'terraform. tfstate 'et pas de blocages.
Les modifications manuelles dans le nuage au-dessus de l'IaC → une dérive éternelle.
Ansible 'shell '/' command' au lieu des modules (brise l'idempotence).
Inventaire « en un seul fichier » sans groupes/variables, mélange prod/stage.
Secrets dans vars/référentiel, absence de Vault/KMS.
Apply sans Plan et sans Peer Review.

15) Chèque de mise en œuvre (0-45 jours)

0-10 jours

Configurer backend/lock distant, décomposer les modules Terraform.
Inclure tflint/tfsec/checkov, ansible-lint ; négocier des étiquettes/labels de ressources.
Avoir un rôle Ansible pour NGINX/agents/logers ; organiser les inventaires.

11-25 jours

Ajouter Conftest/OPA, Terratest et Molecule pour les modules/rôles critiques.
CI : « plan » sur MR, artefact du plan, manuel-apply avec appellation ; Ansible `--check` на stage.
Intégrer le stockage secret (Vault/KMS/Secret Manager).

26-45 jours

Auto-plan programmé pour drift-détail, rapports sur les politiques.
Catalogue de modules/rôles avec versioning ; documentation 'README. md'dans chacun.
GitOps : annotations de sortie, lien avec le monitoring et les jeux d'alert.

16) Métriques de maturité

% des environnements avec état et localités distants = 100 %.
La part des modules/rôles avec les tests (Terratest/Molecule) ≥ 70 %.
Le temps moyen entre MR et apply (prod) est d'heures, pas de jours.
« Dérive manuelle » nulle (tous les changements passent par le MR).
100 % des ressources critiques sont couvertes par Policy as Code (tags, cryptage, backup).

17) Conclusion

Terraform définit une base d'infrastructure prévisible et répétable ; Ansible amène les hôtes et les services à l'état requis. Ajoutez Policy as Code, Remote State avec Localisation, Tests, Secret Management et CI/CD avec plan→review→apply - et votre circuit IaC deviendra gérable, sûr et rapide, et les versions atomiques et réversibles.