Terraform и Infrastructure as Code

(Section : Technologie et infrastructure)

Résumé succinct

Terraform est l'outil de base de l'IaC pour la création reproductible et vérifiable de l'infrastructure cloud iGaming : VPC/sous-réseaux, équilibreurs, bases de données/clusters, files d'attente/bus, KMS/Secrets, Kubernetes-clusters, CDN et surveillance. Le succès repose sur une architecture modulaire, une politique stricte de steak et de verrouillage, une approche GitOps des versions, un Policy-as-Code, des tests automatisés et des FinOps transparents.

1) Principes IaC pour iGaming

Déclaration : l'infrastructure est décrite par un code ; Il n'y a pas d'étapes manuelles.
Idempotence : la répétition 'apply' donne le même résultat.
Séparation des environnements : 'dev/stage/prod'à partir d'un code unique avec des paramètres.
Composition des modules : catalogue unique de modules pour VPC, OBD, files d'attente, K8s, surveillance.
Sécurité par défaut : sous-réseaux privés, mTLS, droits IAM minimaux.
Observabilité et coût : métriques/alertes/budgets - aussi sous Terraform.

2) Structure du référentiel

iac/
modules/
vpc/
mysql/
kafka/
eks_aks_gke/
redis/
monitoring/
envs/
prod/
eu-west/
main. tf variables. tf backend. tf stage/
eu-west/
...
dev/
...
policies/
opa/
sentinel/
pipelines/
ci_cd/

L'alternative est un repo modulaire (un référentiel séparé pour chaque module) + les consommateurs.

3) Modularité de base (exemple HCL)

hcl variable "name" {}
variable "cidr" {}
variable "az_count" { default = 3 }

cloud provider resources (summarized)
resource "cloud_vpc" "this" { name = var. name cidr = var. cidr }
resource "cloud_subnet" "private" {
count = var. az_count vpc_id = cloud_vpc. this. id type  = "private"
}
output "vpc_id" { value = cloud_vpc. this. id }
output "private_subnets" { value = cloud_subnet. private[].id }

hcl module "vpc" {
source = "../../modules/vpc"
name  = "prod-eu-west"
cidr  = "10. 20. 0. 0/16"
}

module "mysql" {
source = "../../modules/mysql"
name  = "payments"
vpc_id = module. vpc. vpc_id subnets = module. vpc. private_subnets pitr  = true size  = "r6g. large"
kms_key = module. kms. key_id
}

4) Contrôle du steat (state) et des verrous

Backend distant (par exemple, stockage objet) + verrous (DynamoDB/Blob-lock) - empêche les courses 'apply'.
Versioner le backend et chiffrer le steat (KMS).
Règles d'accès : seuls CI/CD et « infra owners » ont les droits « apply » ; les développeurs sont « plan ».

• Workspaces est pratique pour les environnements similaires (réplication),
• Répertoires distincts - pour des configurations clairement isolées et des topologies différentes.

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

5) Variables, secrets et données sensibles

variables. tf + .tfvars pour les environnements ; sensible = vrai pour les valeurs privées.
Les secrets ne sont pas stockés dans Git. Utilisez la consommation de Secret Manager/KMS via data-source ou votre fournisseur.
Chiffrement par défaut : pour les volumes/backups/snapshots/bases de données.
Rotation : les clés et mots de passe tournent automatiquement.

hcl variable "db_password" {
type   = string sensitive = true
}

data "external_secret" "db_password" {
conceptual secret source name = "prod/payments/db_password"
}

6) GitOps et CI/CD pour Terraform

Flow PR : 'terraform fmt' →' init '→' validate '→' tflint '→' plan 'avec sortie en PR → approve manuelle →' apply 'de CI.
Promotion des environnements : changements d'abord dans 'stage', puis balise/merge dans 'prod'.
Logs et artefacts : conservation du plan et diffa, rapport artefact.

yaml steps:
- run: terraform fmt -check
- run: terraform init -upgrade
- run: terraform validate
- run: tflint --enable-rule=terraform_standard_module_structure
- run: terraform plan -var-file=envs/stage/eu-west/vars. tfvars -out tfplan
- run: terraform show -no-color tfplan > plan. txt after April
- run: terraform apply tfplan

7) Policy-as-Code (OPA/Sentinel)

Objectif : rejeter automatiquement les changements dangereux/coûteux.

• Le chiffrement des ressources est obligatoire.
• PI publiques - uniquement par le biais d'une liste d'exceptions.
• Limite la taille des instances/clusters par environnement.
• Les balises obligatoires sont « bou », « owner », « cost _ center ».

rego deny[msg] {
input. resource. type == "db_instance"
not input. resource. encrypted msg:= "DB must be encrypted at rest"
}

8) Test IaC

terraform validate est une vérification de syntaxe de base.
tflint est un style/anti-modèle/fournisseur-spécifique.
Infracost est une estimation préliminaire de la valeur en PR.
Terratest - Tests d'intégration (Go) : soulever/vérifier/démolir le stand.
Kitchen-Terraform - tests modulaires avec invariants de ressources.
Drift-detect : périodique 'plan' en lecture seule et alerte en cas de dissynchrone.

9) Modules types pour iGaming-platform

Réseau

VPC/VNets/VPC-Peering, sabnets privés/publics, routage, NAT/Firewall, groupes de sécurité/NSG.
DNS/Failover: Route-политики, health-checks, latency-based routing.

Données

MySQL/PostgreSQL: Multi-AZ, PITR, `auto_minor_version_upgrade`.
Redis/Memcached : Multi-AZ, politiques snapshot/TTL.
Data Lake/Lakehouse : baquets, politiques, tables (catalogue/métastore).
Clusters ClickHouse/OLAP : Charding/réplication, stratégies de disque.

Bus/files d'attente

Kafka/Pulsar/managed-options, ACL, rétention, schémas de registre.

K8s

EKS/AKS/GKE с NodeGroups, taints/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
Intégration des secrets externes, Prometheus/Grafana, Loki/ELK, cert-manager.

Edge/CDN

Distribution CDN, règles de cache, WAF, mitigation des bots.

10) Variables/Outputs/locals - pratique

locals pour les valeurs calculées (masques, noms).
outputs comme API du module : minimum nécessaire.
Nommage des ressources : '<bou> - <region> - <domain> - <component>'.
Тэги: `env`, `owner`, `cost_center`, `criticality`, `pii`.

hcl locals {
name_prefix = "${var. env}-${var. region}-${var. service}"
}
resource "cloud_lb" "api" { name = "${locals. name_prefix}-lb" }

11) Multicloud et régions

Abstraction à travers les mêmes modules, différents fournisseurs : 'aws', 'azurerm', 'google'.
Provider alias pour les ressources multirégionales (DR/réplication).
Les différences de services sont fermées par des conditions et des ficheflags dans les modules.
Les données sont localisées : réservoirs individuels/OBD par région (EU/TR/LATAM).

hcl provider "aws" { region = "eu-west-1" alias = "eu" }
provider "aws" { region = "sa-east-1" alias = "latam" }

12) Observabilité et alertes comme code

Dashboards, règles d'alerte (p95/p99, taux d'erreur, CPU/IO), moniteurs SLO.
Logs d'accès/audit (WORM), métriques de valeur (par tag/namespace).
Incidents : notifications de chat, URL runbooks dans les annotations de ressources.

13) FinOps : le coût sous contrôle

Infracost en PR + alertes budgétaires.
Quotas par environnement : limitation des classes d'instances/entrepôts.
Auto-hygiène : TTL pour les ressources dev, politique de rétractation des réservoirs/logs.
Spot/Preemptible pour les tâches non critiques, redondance pour la prod.

14) Processus de migration/changement

'Terraform import 'pour les ressources legasi (immédiatement après -' plan '/' apply ').
« moved »/« removed » blocs lors du refactoring pour éviter les destructions.
Changements zero-downtime : double déroulage (bleu-vert) pour les contours critiques (OBD/équilibreurs).
PR étape par étape : d'abord un nouveau groupe de ressources, puis le trafic, puis le démantèlement.

15) Sécurité et conformité

Least privilège : les modules ne créent que les droits nécessaires, ne les utilisent pas ".
KMS everywhere : cryptage des volumes/backups/secrets/steat.
Scan Terraform/IaC en CI (SAST pour IaC).
Secrets en dehors de Git : seulement les gestionnaires de secrets ; rotation et vérification de l'accès.
Zones PII : tags/politiques d'accès, interdiction des exportations interrégionales.

16) Exemples de modèles

hcl module "db" {
source   = "../../modules/mysql"
name    = "wallet"
multi_az  = true storage_gb = 500 pitr    = true backup_retention_days = 14 deletion_protection  = true
}

hcl module "slo_latency" {
source = "../../modules/monitoring/slo"
name  = "api-latency-p95"
target_ms = 250 window  = "30m"
alert_channels = ["chatops#incidents"]
}

hcl module "cdn" {
source = "../../modules/cdn"
domain = "example. com"
waf_enabled = true cache_ttl  = 600
}

17) Chèque de mise en œuvre Terraform/IaC

1. Sélectionnez la structure du référentiel (monorépo des modules + répertoires d'environnement).
2. Configurez l'état à distance avec verrouillage et cryptage (KMS).
3. Entrez GitOps-pipeline : fmt/validate/tflint/plan → review → apply.
4. Formez une bibliothèque de modules (VPC, K8s, OBD, files d'attente, surveillance, CDN, secrets).
5. Inclure les Policy-as-Code (OPA/Sentinel) et les scans IaC dans l'IC.
6. Organisez les secrets à travers le gestionnaire, les clés - KMS, les rotations.
7. Ajouter des tests : Terratest pour les modules critiques, Infracost dans PR.
8. Définissez SLO/alertes et « surveillance en tant que code ».
9. Configurez les quotas/budgets et TTL pour les ressources non critiques.
10. Planifiez les migrations par étapes (bleu-vert/double rail).

18) Anti-modèles

Les flocons de neige manuels en dehors de Terraform → la dérive et les accidents de 'apply'.
Stockez votre steat localement/sans verrouillage → course et perte de cohérence.
Secrets dans Git/dans '.tfvars' sans cryptage.
Le « module Dieu » sur des centaines de ressources → impossible de tester/réutiliser.
« Apply » direct de l'ordinateur portable dans la prod sans PR et plan-revu.
Ignorer Policy-as-Code/scans → fuites, IP/baquets publics.
L'absence d'Infracost/budgets → un coût imprévisible.

Résultats

Terraform/IaC donne à la plate-forme iGaming la reproductibilité, la vitesse et la sécurité/coût contrôlé. La conception modulaire, le steat rigoureux et les GitOps, les politiques de sécurité, les autotests et les FinOps transforment l'infrastructure en un « pipeline » fiable - des versions rapides sans downtime, une p99 prévisible et une préparation aux tournois de pointe et aux exigences réglementaires.