Kiddoo — Chaîne DevOps, GitOps et observabilité

Aperçu

Kiddoo est un projet académique de plateforme DevOps construit autour d’une API REST de mise en relation pour des services de garde d’enfants. Le travail ne se limite pas à l’application Rust : il couvre son cycle de livraison, le socle cloud qui l’accompagne et son exploitation.

L’objectif était de rendre chaque étape reproductible et traçable : tester le code, produire des images de conteneur versionnées, promouvoir une version entre environnements, déployer l’état attendu avec GitOps et observer les services une fois déployés.

Problématique et enjeux

Un déploiement manuel multiplie les écarts entre les environnements, les actions non tracées et le risque de régression. Le projet répond à quatre enjeux concrets :

• Fiabilité : détecter les défauts avant la fusion et avant la mise à disposition.
• Reproductibilité : décrire l’infrastructure, les conteneurs et les déploiements dans des fichiers versionnés.
• Sécurité : limiter les flux, isoler les données, séparer les secrets du code et réduire l’administration SSH.
• Exploitabilité : disposer de sondes, métriques, journaux et alertes pour diagnostiquer une anomalie.

Architecture technique

L’application est structurée comme un workspace Rust réunissant une bibliothèque de persistance et trois services : api-gateway, identity-proxy et orchestrator. PostgreSQL assure la persistance ; le service passerelle constitue le point d’entrée.

Développeur
    │ push / pull request
    ▼
GitHub Actions ──► tests Rust + formatage + Clippy + PostgreSQL de test
    │ version validée
    ▼
GitHub Container Registry ──► images versionnées
    │ mise à jour du dépôt de déploiement
    ▼
Argo CD ──► Kubernetes (base Kustomize + overlays par environnement)
    │                         │
    │                         ├── api-gateway
    │                         ├── identity-proxy
    │                         ├── orchestrator
    │                         └── PostgreSQL / RDS selon l'environnement
    ▼
Prometheus + Grafana ◄── métriques, sondes et alertes

En parallèle, le socle AWS est décrit avec Terraform : VPC et sous-réseaux, instance EC2, groupes de sécurité, volume EBS chiffré et RDS PostgreSQL non public. Ansible automatise la configuration post-provisionnement. AWS Secrets Manager, Ansible Vault, Systems Manager et Cloudflare Tunnel complètent le dispositif de sécurité et d’exploitation.

Réalisations clés

• Pipeline GitHub Actions exécutant cargo test --workspace, cargo fmt, cargo clippy et une compilation de validation avec un service PostgreSQL de test.
• Conteneurisation des services Rust avec Docker et orchestration locale par Docker Compose : réseau interne, variables d’environnement et stockage séparé des conteneurs applicatifs.
• Chaîne GitOps : publication des images dans GHCR, déploiements Kubernetes factorisés avec Kustomize, puis synchronisation par Argo CD.
• Séparation développement, préproduction et production afin de promouvoir une version validée progressivement.
• Infrastructure AWS modulaire avec Terraform, configuration automatisée via Ansible et état Terraform distant dans S3.
• Observabilité orientée exploitation : sondes Kubernetes, collecte Prometheus, tableaux de bord Grafana et alertes de disponibilité, erreurs, latence, ressources et redémarrages.

Sécurité et résilience

La conception applique une logique de moindre exposition : RDS n’est pas public, les Security Groups limitent les flux au strict nécessaire et les volumes EBS/RDS sont chiffrés. Les secrets sont dissociés du dépôt et des images avec AWS Secrets Manager, Ansible Vault et une stratégie d’injection au déploiement. L’accès applicatif peut passer par Cloudflare Tunnel, afin d’éviter l’ouverture directe du port du service.

Les contrôles ne s’arrêtent pas au déploiement : les sondes vérifient la disponibilité des services, tandis que métriques et journaux servent à confirmer le comportement après une mise à jour et à préparer un retour à une version stable en cas d’incident.

Résultats et apprentissages

Réalisé en autonomie dans le cadre d’une simulation professionnelle encadrée, ce projet a permis de pratiquer une chaîne DevOps complète : Infrastructure as Code, CI, conteneurs, GitOps et supervision. La leçon principale est qu’un déploiement fiable est un processus : une version identifiable, des contrôles avant et après livraison, et un état d’infrastructure lisible dans Git.

Lire le retour d’expérience technique complet pour les décisions d’architecture, les flux de livraison et les compromis.

Statut du projet

Projet académique / simulation professionnelle — réalisé dans le cadre d’une formation en 2026, sous supervision pédagogique.