Blog

Docker, CI/CD et déploiement Coolify pour Laravel, Node et WordPress

Mis à jour: 14 min de lecture
DockerCI/CDCoolifyDevOpsLaravelWordPress

« Ça marche sur ma machine » coûte cher. L'objectif de Docker + CI/CD + Coolify est la reproductibilité : le même artefact qui a passé les tests arrive en staging et, bien fait, en production.

S'applique aux APIs Laravel, apps Node, frontends modernes (dont Astro SSR) et, quand ça a du sens, WordPress containerisé. Sur les projets avec checkout ou passerelles, le pipeline fait partie du produit.

Pipeline minimum recommandé

  1. PR : lint + typecheck + tests unitaires (et e2e critiques si applicable).
  2. Build multi-stage : dépendances → build → runtime léger.
  3. Tag immuable : registry/app:gitsha.
  4. Scan basique d'image.
  5. Deploy en staging sur Coolify avec les mêmes variables (valeurs différentes).
  6. Smoke / healthcheck.
  7. Promotion en production du même digest/tag.

Multi-stage (Laravel / Node)

  • deps : installe Composer/npm avec cache.
  • build : npm run build, php artisan optimize, assets.
  • runtime : image finale avec utilisateur non-root, sans toolchain, sans secrets.

Détails qui évitent les incidents :

  • Couches ordonnées pour ne pas invalider le cache Composer à chaque changement.
  • npm ci en CI, pas de npm install libre.
  • Utilisateur non-root + permissions sur storage et bootstrap/cache.

Checklist de release Laravel

  1. Image multi-stage avec PHP-FPM ou Octane.
  2. Variables dans Coolify/secrets CI, jamais dans l'image.
  3. Migrations comme étape explicite du deploy.
  4. Files d'attente et scheduler avec restart policy.
  5. Healthcheck : route légère qui vérifie app + DB.
  6. Rollback : redeploy du tag SHA précédent.

WordPress dans Docker

  • Volume persistant pour wp-content/uploads.
  • Secrets via env / wp-config généré au runtime.
  • Object cache (Redis) comme service séparé quand le trafic l'exige.
  • Multisite : attention aux domaines, cookies et paths.
  • Backups DB + uploads avant mises à jour majeures.

Configuration Coolify

  • Variables et secrets hors du Dockerfile.
  • Healthcheck réel (HTTP 200, pas seulement « le processus existe »).
  • Domaines : apex canonique ; www avec redirect 301.
  • SSL Let's Encrypt sur les deux hosts.
  • Restart policies et logs accessibles.
  • Staging et production séparés.

Checklist pré-production

  • Tag = git SHA (pas seulement latest)
  • Secrets absents du repo et des couches Docker
  • Healthcheck vert en staging
  • Migrations répétées + backup récent
  • Apex/www et SSL vérifiés
  • Workers/cron vivants après le deploy
  • Plan de rollback écrit

Erreurs courantes

  • Rebuild différent en prod et on ne sait plus ce qui tourne.
  • Healthcheck qui tape / avec redirect 301 et marque unhealthy en boucle.
  • Volumes WordPress avec propriétaire root.
  • Lancer migrate --force deux fois en parallèle.
  • Oublier le worker de file : le web est up mais les webhooks ne sont pas traités.

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

Questions fréquentes

Coolify remplace-t-il un pipeline CI ?

Pas entièrement. Coolify excelle en deploy, SSL, variables et redémarrages. Le CI (lint/tests/build) reste la responsabilité de GitHub Actions, GitLab CI ou un autre runner. L'usage habituel est de les combiner.

Peut-on mettre WordPress dans Docker ?

Oui, avec précaution : volumes pour uploads, permissions correctes, et ne jamais laisser wp-config avec secrets dans l'image. Pour des sites simples ce n'est parfois pas utile ; pour des équipes déjà en containers, oui.

Faut-il utiliser le tag latest en production ?

Il vaut mieux éviter `latest` comme seule référence. Les tags avec git SHA permettent un rollback exact.

Que faire des migrations de base de données ?

Migrations versionnées, exécutées comme étape contrôlée du release, avec plan de reverse quand applicable. Pas comme processus officiel « à la main en production ».

Configure-t-on aussi www et SSL ?

Oui. Sur proxy/Coolify on définit apex canonique, SSL Let's Encrypt et redirect www→non-www. Un DNS mal configuré est un bug produit, pas un détail.