Aller au contenu principal

Docker

Environnements​

Patrimo utilise deux fichiers Docker Compose distincts :

FichierUsage
docker-compose.ymlDéveloppement local (hot-reload, bind-mount source)
docker-compose.prod.yamlProduction standalone — utilisé par Coolify
Extension .yaml pour la prod

Le fichier de production utilise l'extension .yaml (et non .yml). Coolify détecte automatiquement ce fichier lors de la configuration du service.

Développement​

cp .env.example .env
# Éditer POSTGRES_PASSWORD et AUTH_SECRET
docker compose up

Ce qui se passe au démarrage :

  1. PostgreSQL 16 démarre et attend le healthcheck (pg_isready)
  2. L'image app est construite (cible dev du Dockerfile)
  3. npx prisma migrate deploy applique les migrations versionnées
  4. npm run dev lance Next.js sur le port 4000

Le code source est monté en volume (- .:/app) → le hot-reload fonctionne sans rebuild.

Services :

ServicePortDescription
app4000Next.js dev server
db5432PostgreSQL 16
docs3001Docusaurus dev server

Production​

En production, Coolify clone le dépôt depuis GitHub et build les images directement depuis le code source. On ne lance pas docker compose up manuellement en prod.

Le fichier docker-compose.prod.yaml est un fichier standalone — il ne nécessite pas de fichier d'override. Il définit :

  • Service app : build depuis le Dockerfile racine (cible runner), port exposé 3000 (sans binding hôte — routé par Coolify)
  • Service db : postgres:16-alpine, volume nommé postgres_data, healthcheck pg_isready
  • Service docs : build depuis docs-site/Dockerfile (cible runner), port exposé 80
  • Variables injectées par Coolify (aucune valeur hardcodée dans le fichier)
Pas de healthcheck applicatif dans le compose prod

Le healthcheck de l'application (/api/health) est géré directement par Coolify, pas dans docker-compose.prod.yaml.

Voir Coolify pour la configuration du déploiement.

Dockerfile multi-stage​

Le Dockerfile à la racine utilise plusieurs stages :

StageRôle
baseNode 22 Alpine + dépendances système
depsnpm ci — dépendances de prod
devCible dev (inclut devDeps, CMD = npm run dev)
builderBuild Next.js (npm run build)
runnerImage finale minimale — copie .next/standalone

Stage runner — détail : les modules Prisma natifs sont installés via npm install --ignore-scripts --no-audit --no-fund prisma (plutôt que par COPY manuel des binaires). Le fichier prisma.config.ts est également copié dans ce stage (requis par Prisma 7).

Entrypoint de production​

Le script entrypoint.sh exécuté au démarrage du container de production :

npx --no prisma migrate deploy
exec node server.js

Les migrations sont donc appliquées automatiquement à chaque déploiement, avant le démarrage de l'application.

Volumes​

VolumeContenu
postgres_dataDonnées PostgreSQL persistantes (prod)

En dev, deux volumes anonymes excluent node_modules et .next du bind-mount (performance sur macOS/Windows).

Variables d'environnement​

En dev, DATABASE_URL est construite automatiquement depuis POSTGRES_USER, POSTGRES_PASSWORD et POSTGRES_DB. En production, toutes les variables sont injectées par Coolify.

Voir Variables d'environnement pour la référence complète.

Commandes utiles​

# Voir les logs en temps réel
docker compose logs -f app

# Accéder au shell du container
docker compose exec app sh

# Appliquer les migrations manuellement (dev)
docker compose exec app npx prisma migrate deploy

# Redémarrer l'app sans rebuild
docker compose restart app

# Rebuild forcé après changement de dépendances (dev)
docker compose up --build

Voir aussi​