Optimisation de CI/CD avec GitHub Actions et Docker
Introduction
Docker et GitHub Actions forment le duo que j'utilise quotidiennement. Sur WizOps.fr, le pipeline build l'image Docker frontend et backend, les pousse vers GHCR (GitHub Container Registry), puis déclenche le déploiement Kubernetes. Ce workflow, que j'ai affiné sur des dizaines de projets, est reproductible et optimisable. Voici comment.
Optimiser le build Docker dans le pipeline
Le build Docker est souvent le goulot d'étranglement du pipeline. Sur WizOps.fr, le build Nuxt prenait initialement 8 minutes. En activant BuildKit avec le cache inline et en restructurant le Dockerfile (les couches qui changent rarement en premier : OS, dépendances système, puis pnpm install, puis le code source), le build est passé à 2 minutes 30. Chez TEKYN, on a poussé l'optimisation plus loin avec des multi-stage builds : le stage de build Nuxt produit un artefact statique, et le stage final ne contient qu'un Nginx slim avec les fichiers générés. L'image finale pèse 45 Mo au lieu de 1,2 Go.
GitHub Actions + Docker : le workflow type
Mon workflow standard pour un projet Kubernetes : (1) checkout du code, (2) setup Docker Buildx, (3) login au registry (GHCR, ECR ou Docker Hub selon le client), (4) build avec cache, (5) push avec tag basé sur le SHA du commit et le nom de branche, (6) mise à jour du manifest Kubernetes avec le nouveau tag. Pour WizOps.fr, ce workflow est défini dans .github/workflows/docker-image.yml et utilise un runner self-hosted pour des builds plus rapides. L'image est poussée vers ghcr.io/wizops-cloud/wizops.fr:main-frontend.
Docker en environnement de test
Docker n'est pas qu'un outil de packaging : c'est aussi un outil de test. Chez Epiconcept, les tests d'intégration des projets INSERM utilisent Docker Compose pour monter l'environnement complet (MariaDB, Redis, API backend) dans le pipeline GitHub Actions. Chaque PR a son propre environnement Docker éphémère, complètement isolé. Chez Bloomflow, on va plus loin : les tests E2E tournent dans des conteneurs Docker sur le cluster Kubernetes via des Jobs éphémères. L'environnement de test est strictement identique à la production.
Sécurité des images Docker
Chaque image Docker que je construis passe par un scan de vulnérabilités Trivy dans le pipeline. Chez KNDS, c'est une obligation contractuelle. L'action GitHub aquasecurity/trivy-action produit un rapport SARIF qui s'intègre directement dans l'onglet Security de GitHub. Les images de base sont épinglées à un digest SHA (pas à un tag mutable comme node:20-alpine), et on utilise des images distroless quand c'est possible pour réduire la surface d'attaque. Chez Bloomflow, un job nightly rescanne toutes les images en production pour détecter les nouvelles CVE.
Monitoring et maintenance continue
Une fois les images en production, le monitoring prend le relais. Chez Metronome, Prometheus scrape les métriques des conteneurs via le cAdvisor de Kubernetes, et Grafana affiche les dashboards de consommation de ressources par image/version. Loki centralise les logs de tous les conteneurs. Quand un conteneur crash-loop (restart en boucle), une alerte Slack est envoyée en moins de 30 secondes. Cette boucle de feedback complète, du commit au monitoring, est ce qui rend le pipeline véritablement continu.
Conclusion
GitHub Actions et Docker, bien configurés et optimisés, permettent de livrer des applications containerisées en toute confiance. Les clés : un Dockerfile optimisé avec multi-stage build et cache, un pipeline structuré avec scan de sécurité, et un monitoring post-déploiement. C'est cette stack que je déploie sur tous mes projets, de WizOps.fr aux environnements les plus exigeants du secteur défense.