Skip to content

fastapi-eks-project — Documentation

Déploiement production-grade d'une API FastAPI et de son frontend React sur AWS EKS, avec trois environnements sur un seul cluster, GitOps, observabilité complète et une démarche DevSecOps documentée de bout en bout.

Cette documentation contient l'architecture, les décisions techniques (35 ADR), les 84 incidents rencontrés et résolus, et une section Comprendre de 26 pages qui explique les mécanismes plutôt que les commandes.

Par où commencer

Trois entrées, selon ce que tu cherches.

  1. Architecture de bout en bout — les composants et les flux
  2. Application Overview — la stack applicative, les endpoints
  3. Vue d'ensemble « Comprendre » — les 26 pages de fond
  1. Runbook de validation — la seule source, commencer par la §0 « Reprise après montage »
  2. AWS Setup — session, secrets (§14), clés d'accès (§15)
  3. Infrastructure Summary — Terraform, EKS, RDS
  1. Quick Reference — les incidents critiques, 2 minutes
  2. Best Practices — consolidation par domaine
  3. Un ADR au hasard dans la liste ci-dessous — chacun porte une décision et son arbitrage

Le plus rapide reste la recherche

Le bouton Rechercher en haut à droite indexe toute la documentation. Essaie NetworkPolicy, AccessDenied, write-back, NXDOMAIN, 503.

La stack

Application   FastAPI + PostgreSQL (RDS, hors cluster) + Alembic
              SPA React + Vite, une image pour les trois environnements

Cloud         AWS eu-west-3 — EKS 1.35, RDS, ECR, Secrets Manager, CloudTrail
IaC           Terraform, deux stacks : persistent/ (survit) et ephemeral/ (recréée)
CI/CD         GitLab CI — deux ci_config_path, application et infrastructure

Réseau        Cilium (CNI + NetworkPolicy, sans aws-node)
Exposition    Envoy Gateway (Gateway API), cert-manager en wildcard DNS-01,
              ExternalDNS vers Cloudflare — devopsyouss.com
Secrets       External Secrets Operator + IRSA, un rôle par environnement
GitOps        ArgoCD, selfHeal actif sur toutes les Applications

Observabilité Prometheus, Grafana, Alertmanager vers Slack
              Loki (logs), Tempo + OpenTelemetry (traces), Alloy
Sécurité      Trivy, Semgrep, secret detection, tfsec, kube-linter

Le cluster est recréé, jamais mis à jour sur place

Il naît et meurt à chaque session. Ce n'est pas une limite de moyens mais un choix qui change tout : pas de migration de plan de contrôle, aucune dérive accumulée, et un montage complet qui sert de test d'intégration. Voir Version du cluster.

Décisions techniques (ADR)

35 décisions enregistrées, de l'arbitrage RDS dev/prod jusqu'à l'acceptation documentée d'un risque réseau.

Quelques-unes qui structurent le projet :

ADR Décision
019 Migration du VPC CNI vers Cilium
025 Gouvernance des ressources, et pourquoi kube-system en est exclu
029 Trois environnements sur un seul cluster
030 Contexte de build par dossier, jamais la racine
031 Un garde-fou qui prévient et ne détruit pas
033 Terraform déclare les secrets sans connaître leurs valeurs
034 Les clés d'accès de la CI sortent du state
035 Un risque accepté, écrit, avec ses conditions de réévaluation
036 Une correction que le plan de l'outil rend impossible, nommée plutôt que laissée bloquée

La liste complète est dans le menu ADR.

Incidents

84 incidents documentés sur 8 sprints, chacun avec son symptôme, sa cause, son correctif et la vérification qui prouve le correctif.

Sprint Thème Incidents
0 Fondations et CI/CD 3
1 DevSecOps 4
2 Terraform AWS 5
3 Kubernetes et EKS 45
4 Observabilité et exposition 7
5 Cilium et Gateway API 2
6 Multi-environnement 9
7 Remédiation et fiabilité 9

Le tableau de bord des incidents permet de filtrer par sévérité et par domaine.

Le fil rouge de ce projet

Une idée revient dans presque tous les incidents, et c'est celle qui a le plus d'usage ailleurs :

La preuve est la vérification d'absence, jamais le succès de l'appel

Un apply réussi ne prouve pas que la ressource est correcte. Un pipeline vert ne prouve pas que les tests ont tourné. Un AccessDenied ne prouve rien sans un témoin positif joué avec la même identité.

Sept formes de « vert qui ne prouve rien » ont été rencontrées et documentées. La dernière en date : une politique IAM réduite depuis une trace CloudTrail, complète sur son périmètre et aveugle en dehors, qui a laissé naître un cluster sans un seul nœud (INC-076).

Pages de fond les plus utiles

Rapports de sprint

Sprint 0 · 1 · 2 · 3 · 4 · 5 · 6

L'état du projet donne la vue courante.

Dernière mise à jour

2026-09-06 — Sprint 7 en cours. 35 ADR, 84 incidents, 26 pages « Comprendre ».