Cloud, Docker & DevOps — des déploiements rapides et fiables
Nous conteneurisons toutes les applications avec Docker, les orchestrons avec Docker Compose (ou Kubernetes sur les projets d'entreprise), configurons Caddy en proxy inverse avec SSL automatique et automatisons tout le cycle de déploiement via GitHub Actions, du commit à la production.
Conteneurisation avec Docker et Docker Compose
Chaque service dispose de son propre Dockerfile multi-étapes : une étape de build qui installe les dépendances et compile, puis une étape finale minimale (distroless ou alpine) ne contenant que les artefacts nécessaires. Une image Next.js type reste sous les 150 Mo, une image FastAPI sous les 80 Mo. Les images sont reconstruites à chaque fusion sur main et étiquetées sémantiquement (`v1.2.3` et `latest`).
Docker Compose décrit toute la pile : frontend, API, base de données, Redis et worker. Les variables sensibles (mot de passe de la base, clés d'API, secret Stripe) résident dans un `.env` exclu de git — jamais figées dans l'image. Les health checks de Compose garantissent que les dépendances sont prêtes avant le démarrage (base prête → l'API démarre → le frontend démarre).
- Cache de build avec `--mount=type=cache` — `npm ci` en CI
- Ordre des couches optimisé : les dépendances stables d'abord, le code source ensuite
- Gestion des secrets avec Docker secrets ou HashiCorp Vault sur les projets d'entreprise
- `restart: unless-stopped` et `docker compose up --no-deps` pour un déploiement atomique
Caddy — un proxy inverse moderne à SSL automatique
Caddy 2.8 gère SSL/TLS automatiquement via ACME (Let's Encrypt ou ZeroSSL) — sans configuration manuelle des certificats. HTTP/2 et HTTP/3 (QUIC) sont actifs par défaut. Les en-têtes de sécurité (HSTS, X-Frame-Options, CSP) sont posés globalement grâce à des snippets réutilisables. La configuration déclarative du Caddyfile se compare par diff et se versionne dans git.
La limitation de débit, la compression gzip/brotli et la journalisation JSON structurée s'activent via des directives natives de Caddy — sans module Nginx ni configuration Apache complexe. L'accès aux chemins sensibles (`/admin`, `.env`, `.git`) renvoie un 444 (aucune réponse), défini dans un snippet de sécurité global.
- TLS 1.3 uniquement, avec des suites cryptographiques modernes
- TLS à la demande pour les SaaS multi-locataires à sous-domaines dynamiques
- Rechargement sans interruption — `caddy reload` ne coupe aucune connexion active
- Journaux Caddy → Loki → Grafana — analyse du trafic et alertes sur anomalies
CI/CD GitHub Actions et supervision
Le pipeline CI s'exécute à chaque PR : lint, vérification des types, tests unitaires, construction de l'image Docker et analyse de vulnérabilités (Trivy). Si tout passe, l'image est poussée vers le registre et le déploiement sur staging se fait automatiquement. Une fusion sur main déclenche un déploiement automatique en production, suivi d'un health check. Si celui-ci échoue en 60 secondes, le rollback est automatique.
La supervision repose sur Grafana et Prometheus pour les métriques applicatives (latence, taux d'erreur, taille de file) et sur Loki pour l'agrégation des journaux. Les alertes partent sur Slack ou par e-mail : taux d'erreur supérieur à 1 %, latence P95 au-dessus de 500 ms, disque au-delà de 85 %. La surveillance externe de disponibilité passe par Better Uptime — un tableau de bord SLA public est disponible sur demande.
- Analyse de vulnérabilités Trivy sur les images — une CVE critique bloque le déploiement
- Dependabot avec fusion automatique des correctifs (CI au vert exigée)
- Sauvegarde automatique de la base vers un stockage compatible S3 (chaque nuit, rétention de 30 jours)
Avantages et limites
Avantages
- Déploiement par bascule de version, avec rollback automatique si le health check échoue.
- SSL/TLS automatique grâce à Caddy — le renouvellement des certificats ne demande pas d'intervention manuelle.
- Environnement reproductible : la même image Docker en développement, en staging et en production.
- Supervision et alertes (Grafana, Loki) sur les métriques et les journaux.
Limites
- Docker Compose ne monte pas en charge comme Kubernetes sur un parc multi-nœuds d'entreprise.
- La mise en place initiale du CI/CD demande du temps et une expertise DevOps.
- Les images et les journaux consomment de l'espace disque — un nettoyage régulier s'impose.
- Une supervision complète (Prometheus et Grafana) ajoute des services à maintenir.
Verdict en bref
Docker, Caddy et GitHub Actions forment la combinaison idéale pour déployer de façon fiable sur un VPS ou quelques nœuds. Au-delà de plusieurs dizaines de nœuds avec un auto-scaling agressif, passez à Kubernetes.
Tableau des spécifications
| Capacité | Limite / seuil | Usage courant | |
|---|---|---|---|
| Orchestration | Docker Compose, pile complète | Un seul nœud ; le multi-nœuds impose Swarm ou K8s | VPS, projets petits et moyens |
| Proxy inverse | Caddy 2.8, HTTP/3, SSL automatique | Des règles très complexes réclament une configuration étendue | Multi-domaine, multi-locataire |
| CI/CD | GitHub Actions, déploiement automatisé | Les minutes de CI sont facturées au-delà de l'offre gratuite | Du commit à la production automatiquement |
| Coût courant | VPS à partir d'environ 5 €/mois | La supervision et les sauvegardes ajoutent un coût | D'un site unique à un portefeuille de marques |
Docker Compose face à Kubernetes
| Critère | Docker Compose | Kubernetes |
|---|---|---|
| Complexité de mise en place | Faible | Élevée |
| Montée en charge multi-nœuds / auto-scaling | Limitée (un seul nœud) | Excellente |
| Adapté à | VPS, projets petits et moyens | Grandes flottes, entreprise |
Questions fréquentes
Pourquoi Caddy plutôt que Nginx ?
Caddy gère SSL/TLS automatiquement via ACME, active HTTP/2 et HTTP/3 par défaut et se contente d'une configuration déclarative courte. Nginx exige certbot et beaucoup plus de configuration manuelle pour un résultat équivalent.
Ai-je besoin de Kubernetes ?
Pas pour la majorité des sites. Docker Compose sur un VPS fait tourner un site ou quelques services de façon fiable. Kubernetes ne devient utile qu'à partir de plusieurs dizaines de nœuds avec un auto-scaling agressif.
Comment fonctionne un déploiement par bascule ?
GitHub Actions construit une nouvelle image, la démarre à côté de l'ancienne, exécute un health check puis bascule le trafic. Si le health check échoue dans les 60 secondes, le rollback vers la version précédente est automatique.
Quelle supervision recommandez-vous ?
Grafana et Prometheus pour les métriques (latence, taux d'erreur) et Loki pour les journaux agrégés, avec des alertes sur Slack ou par e-mail. Pour la disponibilité externe, nous ajoutons un service indépendant comme Better Uptime.