Choix techniques
Pour chaque décision : ce qui a été choisi, ce qui a été envisagé, et pourquoi.
| Décision | Alternatives envisagées | Pourquoi |
|---|---|---|
| Docker Compose | Kubernetes (k3s) avec Argo CD | Répond à toutes les exigences avec beaucoup moins de complexité, pour une seule application sur deux machines. Kubernetes reste une évolution possible. |
| Deux VM | Tout sur une seule VM | Les builds exécutent du code tiers avec accès au socket Docker : les isoler protège la production. Les builds ne ralentissent plus l'application. |
| Jenkins | GitHub Actions, Travis CI, Woodpecker, Tekton | Auto-hébergé et entièrement configuré par fichiers, sans dépendre des réglages de l'organisation de l'école. Travis CI n'est plus gratuit et n'est cité par le sujet qu'en exemple. |
| Interrogation de GitHub (polling) | Webhooks | Pas de droits d'administration sur le dépôt de l'école. Le polling n'a besoin que d'un accès en lecture, et GitHub n'a jamais besoin de joindre Jenkins. |
| GHCR | Docker Hub, registre auto-hébergé | Images privées illimitées, accès lié à GitHub, rien à héberger. |
| Ansible sans Terraform | Terraform pour les ressources GCP | L'empreinte Google Cloud est petite et créée une seule fois. Ansible couvre tout ce qui change. |
| Traefik avec des routes en fichiers | Labels Docker, nginx | Les routes sont des fichiers explicites, lisibles et versionnés, et Traefik gère Let's Encrypt tout seul. |
| Configuration générée par Ansible | Fichiers .env écrits à la main | Une seule source de vérité, des secrets chiffrés, pas d'erreur manuelle. |
:latest en production | Déployer un SHA précis | Déploiement plus simple. Chaque image garde aussi son SHA, pour la traçabilité et le retour arrière. |
L'étape builder du Dockerfile pour les tests | Une image de test dédiée | Réutilise les outils déjà définis pour la production, pas de fichier de plus à maintenir. |