Docker, CI/CD et Coolify : une usine automatisée de releases

Imaginez une usine où chaque produit sort avec le même moule, la même étiquette et un contrôle qualité avant d’atteindre le client. C’est un bon pipeline Docker + CI/CD + Coolify : pas « envoyer à la main ce qui marchait sur mon laptop », mais un processus répétable qui transforme le code en release fiable.

Cet article explique, en langage clair et avec des étapes concrètes, comment déployer des APIs Laravel, des apps Node et des sites WordPress conteneurisés. Il sert aux responsables produit qui veulent moins d’incidents, et aux équipes techniques qui ont besoin d’un vrai runbook — pas seulement d’un Dockerfile isolé.

Pourquoi c’est important pour le business

Chaque deploy improvisé est un risque : un paiement qui ne facture plus, un formulaire qui tombe un vendredi, ou un rollback impossible parce que personne ne se souvient de la version en cours. Un bon pipeline réduit le time-to-ship, rend le staging crédible et transforme le deploy en opération mesurable — pas en rituel de minuit.

• Moins de « ça marche chez moi » : le même artefact est testé puis promu.
• Rollback prévisible : vous revenez au tag précédent en minutes, sans deviner.
• Audit : vous savez quel commit est en production et qui l’a promu.
• Passage à l’échelle de l’équipe : un junior peut déployer sans casser le rituel du senior.

Concepts clés (simple + technique)

Docker : la boîte scellée

Docker empaquette l’app avec ses dépendances dans une image. Pensez à un conteneur maritime : le quai (serveur) peut changer, le contenu voyage de la même façon. Techniquement : couches, Dockerfile multi-stage et un runtime sans toolchain de build ni secrets.

CI/CD : la chaîne d’assemblage

CI (intégration continue) valide chaque changement : lint, tests, build. CD (livraison/déploiement continu) amène l’artefact en staging puis, avec des portes qualité, en production. Coolify excelle au deploy (SSL, variables, redémarrages) ; le CI reste dans GitHub Actions, GitLab CI ou un autre runner.

Tags immuables vs latest

N’étiqueter qu’en latest, c’est comme écrire « version actuelle » sans numéro de lot. Utilisez registry/app:gitsha : vous savez exactement ce qui tourne et pouvez redéployer ce digest.

Guide pratique : pipeline minimum

1. PR : lint + typecheck + tests unitaires (et e2e critiques s’il y a un checkout).
2. Build multi-stage : deps → build → runtime léger.
3. Tag immuable : registry/app:gitsha (jamais seulement latest).
4. Scan basique de l’image (CVE évidentes, utilisateur root, secrets dans les couches).
5. Deploy en staging sur Coolify avec les mêmes variables (valeurs différentes).
6. Smoke / healthcheck : route peu coûteuse qui vérifie app + DB.
7. Promote en production du même digest/tag — pas un rebuild différent.

Multi-stage pour Laravel / Node

• deps : Composer/npm avec cache de couches ordonnées.
• build : npm ci + npm run build, php artisan optimize, assets.
• runtime : utilisateur non-root, sans toolchain, sans .env cuit dans l’image.
• Permissions correctes sur storage et bootstrap/cache (Laravel).

WordPress dans Docker

• Volume persistant pour wp-content/uploads.
• Secrets via env / wp-config généré au runtime — jamais dans l’image.
• Object cache (Redis) comme service séparé quand le trafic l’exige.
• Multisite : domaines, cookies et chemins documentés.
• Backup DB + uploads avant les mises à jour majeures.

Configuration Coolify

• Variables et secrets hors du Dockerfile.
• Healthcheck réel (HTTP 200 sur une route stable, pas seulement « le processus existe »).
• Domaine apex canonique ; www avec redirect 301.
• SSL Let's Encrypt sur les deux hôtes.
• Staging et production séparés ; restart policies et logs accessibles.

Erreurs fréquentes

• Rebuild différent en prod : on ne sait plus ce qui tourne ni comment reproduire le bug.
• Healthcheck sur / avec redirect 301 → boucle unhealthy.
• Volumes WordPress appartenant à root → uploads cassés.
• Lancer migrate --force deux fois en parallèle.
• Oublier le worker de files : le web répond, les webhooks ne traitent pas.
• Secrets dans Git ou dans les couches Docker « pour la commodité ».

Checklist pré-production

• Tag = git SHA (pas seulement latest).
• Secrets absents du repo et des couches Docker.
• Healthcheck vert en staging avec la même image.
• Migrations répétées + backup récent.
• Apex / www et SSL vérifiés.
• Workers et cron vivants après le deploy.
• Plan de rollback écrit (redeploy du SHA précédent).
• Noms de variables alignés entre staging et prod ; valeurs différentes.

Un checkout mal déployé est une bombe. Le pipeline se connecte à les paiements et l'audit de sécurité .