Stack complète en conteneurs

Le profil app de docker-compose.yml construit et lance toute la plateforme dans des conteneurs : migrations, API, worker, frontend web et site de l'Office de Tourisme, en plus des quatre services d'infrastructure. Il sert à vérifier les images de production sur un poste, et de base au déploiement sur un serveur. Pour développer, préférer le lancement des applications hors conteneur (Lancer les applications), qui offre le rechargement à chaud et le code de connexion dans la réponse de l'API.

#Les services du profil

L'ordre de démarrage est imposé par les conditions depends_on :

flowchart LR
    P["postgres sain"] --> MG["migrate terminé avec succès"]
    MG --> BE["backend"]
    MG --> WK["worker"]
    R["redis sain"] --> BE
    R --> WK
    BC["blockchain saine"] --> BE
    BC --> WK
    BE -->|"sain"| WEB["web"]
    TO["tourisme, indépendant"]

#Les secrets obligatoires

Les services backend et worker tournent avec NODE_ENV=production. Dans ce mode, backend/src/config/env.config.ts refuse de démarrer si un secret manque ou garde sa valeur de développement.

Le fichier Compose transmet ces variables depuis l'environnement du shell avec une valeur vide par défaut (${JWT_SECRET:-}). Une variable oubliée fait donc échouer la validation, et le conteneur s'arrête avec « Configuration invalide, démarrage interrompu ».

#Générer les secrets

Une valeur de 32 octets aléatoires en hexadécimal convient pour chacun. Pour RELAYER_PRIVATE_KEY, ajouter le préfixe 0x.

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

#Lancer la stack

Avec Bash, depuis la racine du dépôt :

export JWT_SECRET=$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")
export ENCRYPTION_KEY=$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")
export RELAYER_PRIVATE_KEY=0x$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")
export WEBHOOK_SECRET=$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")
export METRICS_TOKEN=$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")
docker compose --profile app up -d --build --wait

Avec PowerShell :

$env:JWT_SECRET = node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
$env:ENCRYPTION_KEY = node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
$env:RELAYER_PRIVATE_KEY = "0x" + (node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")
$env:WEBHOOK_SECRET = node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
$env:METRICS_TOKEN = node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
docker compose --profile app up -d --build --wait

Docker Compose lit aussi un fichier .env placé à la racine du dépôt pour substituer les variables. Ce fichier est ignoré par Git (.gitignore) et évite de redéfinir les secrets à chaque terminal.

#Le compte opérateur

RELAYER_PRIVATE_KEY est transmise au service blockchain sous le nom OPERATOR_PRIVATE_KEY. Au déploiement, smart-contract/scripts/deploy-local.ts accorde à ce compte les rôles opérateur, pause et frappe, ainsi que DEFAULT_ADMIN_ROLE en administrateur additionnel, lui verse 1 000 ETH fictifs, ce qui finance les dotations de bienvenue, puis retire tous ses rôles au compte Hardhat n° 0 qui a déployé. L'administrateur de la Mairie est le compte n° 2, la trésorerie le compte n° 1.

DEFAULT_ADMIN_ROLE est laissé à l'opérateur en local pour que le reversement de commission puisse appeler setTreasury. Avec LOCAL_STRICT_ROLES=true dans l'environnement du service blockchain, il ne l'a plus : les opérations qui l'exigent, comme le changement d'adresse de trésorerie, sont alors refusées avec « Le compte opérateur du backend n'a pas le rôle requis sur le Smart Contract. » C'est la configuration de Sepolia, où l'administrateur est un multisig de la Mairie (voir Déploiement sur Sepolia).

#Différences avec le développement

Pour avoir les comptes de démonstration dans la stack conteneurisée, lancer le seed depuis le poste : PostgreSQL est exposé sur localhost:5434, qui est la valeur par défaut de DATABASE_URL.

cd backend
npm ci
npx prisma generate
npm run prisma:seed

#Durcissement des conteneurs

Les cinq services du profil héritent du bloc x-hardening :

Les images Node tournent avec l'utilisateur node, l'image nginx avec l'utilisateur 101. Les images du backend et du web embarquent une sonde de santé (/health/live pour l'API, page d'accueil pour le web), et l'arrêt du backend et du worker laisse 30 secondes pour terminer les requêtes en cours. Le détail est dans Images Docker.

#Le frontend web conteneurisé

NEXT_PUBLIC_API_URL et NEXT_PUBLIC_WS_URL sont passées comme arguments de construction (http://localhost:2053/api et http://localhost:2053) : elles sont figées dans l'image au moment du docker compose build. Pour servir le web sous un autre nom de domaine, il faut reconstruire l'image avec d'autres valeurs. Le backend accepte les origines http://localhost:3000 et http://localhost:8081 (CORS_ORIGINS).

#Vérifier la stack

docker compose --profile app ps
curl -s http://localhost:2053/health/ready
curl -s -H "Authorization: Bearer $METRICS_TOKEN" http://localhost:2053/metrics | head

#Arrêter

Le passage à un vrai serveur (nom de domaine, TLS, réseau Sepolia, sauvegardes) est traité dans Environnements et Déploiement sur etherbay.tech.