Josias Kabore

Back to Blog

Infrastructure as Code : Déployer un Data Lake AWS avec Terraform et GitHub Actions

Michée Kabore••12 min read
Infrastructure as CodeTerraformGitHub ActionsAWSData LakeCI/CDDevOps

Découvrez comment mettre en place une infrastructure complète de data lake sur AWS en utilisant Terraform pour l'Infrastructure as Code et GitHub Actions pour l'automatisation CI/CD.

Infrastructure as Code : Déployer un Data Lake AWS avec Terraform et GitHub Actions

Publié le 22 mars 2025

🔗 Code source complet disponible sur GitHub : https://github.com/KMike226/Realtime_financial_app

Introduction

Dans cet article, je vais vous expliquer comment j'ai mis en place l'infrastructure complète de mon pipeline de données financières en utilisant Terraform et GitHub Actions. Cette approche Infrastructure as Code (IaC) garantit la reproductibilité, la versioning et l'automatisation des déploiements.

Pourquoi Infrastructure as Code ?

J'ai choisi l'Infrastructure as Code pour plusieurs raisons cruciales. D'abord, la reproductibilité : je peux déployer exactement la même infrastructure sur différents environnements (dev, staging, prod) sans erreurs humaines. Ensuite, la versioning : chaque changement d'infrastructure est tracé dans Git, permettant un rollback facile en cas de problème. Enfin, l'automatisation : GitHub Actions déploie automatiquement les changements après validation.

Architecture Infrastructure

J'ai conçu une architecture modulaire avec Terraform qui permet de déployer facilement l'infrastructure sur différents environnements. Chaque module a une responsabilité spécifique et peut être réutilisé dans différents contextes.

infrastructure/terraform/
├── environments/
│   └── dev/
│       ├── main.tf
│       ├── backend.tf
│       └── terraform.tfvars
├── modules/
│   ├── vpc/
│   ├── s3/
│   ├── kinesis/
│   ├── emr/
│   └── grafana/

Mes Choix de Modules Terraform

Module VPC : La Fondation Réseau

J'ai créé un module VPC complet qui gère le réseau privé avec des sous-réseaux publics et privés. Le choix d'un VPC privé avec NAT Gateway était crucial pour la sécurité, permettant aux ressources de communiquer avec Internet sans exposer leurs adresses IP publiques.

# Configuration VPC de base
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name = "${var.project_name}-vpc"
    Environment = var.environment
  }
}

# Sous-réseaux privés pour les ressources sensibles
resource "aws_subnet" "private" {
  count = length(var.availability_zones)
  
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]
  
  tags = {
    Name = "${var.project_name}-private-subnet-${count.index + 1}"
    Type = "Private"
  }
}

Module S3 : Data Lake Intelligent

Pour le data lake S3, j'ai implémenté un partitioning intelligent par date, heure et symbole. Cette approche optimise les performances des requêtes et réduit les coûts de stockage. J'ai également configuré la versioning et le chiffrement pour la sécurité des données.

# Bucket S3 avec partitioning intelligent
resource "aws_s3_bucket" "data_lake" {
  bucket = "${var.project_name}-data-lake-${random_id.bucket_suffix.hex}"
  
  tags = {
    Name        = "Financial Data Lake"
    Environment = var.environment
    Purpose     = "Data Storage"
  }
}

# Configuration du lifecycle pour optimiser les coûts
resource "aws_s3_bucket_lifecycle_configuration" "data_lake" {
  bucket = aws_s3_bucket.data_lake.id
  
  rule {
    id     = "transition_to_ia"
    status = "Enabled"
    
    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    
    transition {
      days          = 90
      storage_class = "GLACIER"
    }
  }
}

Module Kinesis : Streams Haute Performance

J'ai configuré plusieurs streams Kinesis pour différents types de données : un pour les données financières, un pour les crypto-monnaies, et un pour les événements système. Chaque stream est configuré avec le nombre optimal de shards selon le volume attendu.

# Stream Kinesis pour données financières
resource "aws_kinesis_stream" "financial_data" {
  name             = "${var.project_name}-financial-data"
  shard_count      = var.financial_data_shards
  retention_period = 24
  
  shard_level_metrics = [
    "IncomingRecords",
    "OutgoingRecords",
    "WriteProvisionedThroughputExceeded",
    "ReadProvisionedThroughputExceeded"
  ]
  
  tags = {
    Name        = "Financial Data Stream"
    Environment = var.environment
  }
}

# Stream pour crypto-monnaies avec plus de shards
resource "aws_kinesis_stream" "crypto_data" {
  name             = "${var.project_name}-crypto-data"
  shard_count      = var.crypto_data_shards
  retention_period = 48
  
  tags = {
    Name        = "Crypto Data Stream"
    Environment = var.environment
  }
}

Pipeline CI/CD avec GitHub Actions

J'ai automatisé tout le processus de déploiement avec GitHub Actions. À chaque push sur la branche main, le pipeline exécute automatiquement terraform plan pour valider les changements, puis terraform apply pour les déployer. Cette approche garantit que l'infrastructure est toujours synchronisée avec le code.

# Workflow GitHub Actions pour déploiement Terraform
name: Deploy Infrastructure

on:
  push:
    branches: [ main ]
    paths: [ 'infrastructure/**' ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v2
      with:
        terraform_version: 1.5.0
    
    - name: Terraform Init
      run: terraform init
      working-directory: infrastructure/terraform/environments/dev
    
    - name: Terraform Plan
      run: terraform plan -out=tfplan
      working-directory: infrastructure/terraform/environments/dev
    
    - name: Terraform Apply
      run: terraform apply tfplan
      working-directory: infrastructure/terraform/environments/dev
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Module S3 : Data Lake Intelligent

Pour le data lake S3, j'ai implémenté un partitioning intelligent par date, heure et symbole. Cette approche optimise les performances des requêtes et réduit les coûts de stockage. J'ai également configuré la versioning et le chiffrement pour la sécurité des données.

Module Kinesis : Streams Haute Performance

J'ai configuré plusieurs streams Kinesis pour différents types de données : un pour les données financières, un pour les crypto-monnaies, et un pour les événements système. Chaque stream est configuré avec le nombre optimal de shards selon le volume attendu.

Pipeline CI/CD avec GitHub Actions

Automatisation Complète

J'ai automatisé tout le processus de déploiement avec GitHub Actions. À chaque push sur la branche main, le pipeline exécute automatiquement terraform plan pour valider les changements, puis terraform apply pour les déployer. Cette approche garantit que l'infrastructure est toujours synchronisée avec le code.

Validation et Tests

Le pipeline inclut plusieurs étapes de validation : vérification de la syntaxe Terraform, validation des configurations AWS, et tests de connectivité. Ces validations préviennent les erreurs de déploiement et garantissent la stabilité de l'infrastructure.

Configuration EMR pour Spark

Cluster Optimisé

J'ai configuré un cluster EMR optimisé pour Spark avec auto-scaling. Le cluster démarre avec un nombre minimal de nœuds et s'adapte automatiquement à la charge de travail. Cette approche optimise les coûts tout en garantissant les performances.

Configuration Spark Avancée

J'ai optimisé la configuration Spark pour le streaming avec des paramètres spécifiques : activation de l'adaptive query execution, configuration du sérialiseur Kryo, et optimisation de la mémoire. Ces réglages permettent de traiter efficacement les données temps réel.

Sécurité et IAM

Principe du Moindre Privilège

J'ai implémenté une politique de sécurité stricte avec le principe du moindre privilège. Chaque service AWS a exactement les permissions nécessaires à son fonctionnement, rien de plus. Cette approche minimise les risques de sécurité et facilite l'audit.

Rôles et Politiques

J'ai créé des rôles IAM spécifiques pour chaque composant : un rôle pour EMR, un pour Lambda, un pour les fonctions de traitement. Chaque rôle a des politiques IAM granulaires qui limitent l'accès aux ressources strictement nécessaires.

Monitoring et Observabilité

CloudWatch Intégré

J'ai configuré CloudWatch pour le monitoring complet de l'infrastructure. Des métriques personnalisées permettent de suivre les performances de chaque composant. Les logs sont centralisés et indexés pour faciliter le debugging.

Alertes Automatiques

J'ai configuré des alertes automatiques pour détecter les problèmes avant qu'ils n'affectent les utilisateurs. Des seuils intelligents déclenchent des notifications en cas de dégradation des performances ou de panne de service.

Gestion des Environnements

Séparation Dev/Prod

J'ai séparé clairement les environnements de développement et de production. Chaque environnement a sa propre configuration Terraform et ses propres ressources AWS. Cette séparation garantit que les tests en dev n'affectent pas la production.

Variables d'Environnement

J'ai utilisé des variables d'environnement pour personnaliser chaque déploiement. Les fichiers terraform.tfvars contiennent les valeurs spécifiques à chaque environnement, permettant une configuration flexible et sécurisée.

Résultats et Métriques

Avec cette infrastructure, j'ai atteint des résultats remarquables. Le déploiement complet prend moins de 5 minutes, l'infrastructure est identique sur tous les environnements, et la sécurité est renforcée avec des politiques IAM strictes. Le monitoring complet permet une détection proactive des problèmes.

Bonnes Pratiques Appliquées

Versioning et Documentation

Tous les modules Terraform sont versionnés avec des tags Git pour les releases. La documentation est intégrée dans le code avec des commentaires détaillés expliquant chaque ressource et sa configuration.

Tests et Validation

J'ai implémenté des tests automatisés pour valider l'infrastructure avant déploiement. Ces tests vérifient la connectivité, les permissions, et la configuration des services critiques.

Backup et Récupération

L'infrastructure inclut des stratégies de backup automatiques pour les données critiques. Les snapshots EBS et les sauvegardes S3 garantissent la récupération en cas de problème.

Conclusion

Cette approche Infrastructure as Code avec Terraform et GitHub Actions m'a permis de créer un pipeline de déploiement robuste et automatisé. L'infrastructure est maintenant reproductible, sécurisée, et monitorée. Cette base solide permet de se concentrer sur le développement des fonctionnalités métier plutôt que sur la gestion d'infrastructure.

Dans le prochain article, je détaillerai le stream processing avec Apache Spark Structured Streaming pour traiter les données en temps réel.

Le code source complet de l'infrastructure est disponible dans le dossier infrastructure/terraform/ du repository.

Thanks for reading! If you enjoyed this article, feel free to share it.

← Read More Articles