Rebuild et commandes Docker
Mémo des commandes pour reconstruire ou redémarrer un service à la main (dépannage).
À exécuter depuis la racine du projet.
Important — choisir le bon fichier avec -f. Il y a un fichier de recette par
environnement. Précise toujours lequel, et le fichier de réglages correspondant :
| Environnement |
Commande de base |
| Local (PC) |
docker compose -f docker-compose.local.yml --env-file .env.local ... |
| Test |
docker compose -f docker-compose.test.yml --env-file .env.test ... |
| Production |
docker compose -f docker-compose.prod.yml --env-file .env.prod ... |
Dans les exemples ci-dessous, remplace <COMPOSE> par l'une de ces combinaisons.
En temps normal, tu n'as pas besoin de ces commandes : le déploiement se fait tout
seul en poussant le code. C'est pour le dépannage.
Reconstruire et redémarrer toute la stack
| docker compose <COMPOSE> up -d --build
|
Reconstruire / redémarrer un seul service
| docker compose <COMPOSE> up -d --build backend # backend, frontend, db, pgadmin...
|
| docker compose <COMPOSE> restart backend
|
Voir les logs (pour comprendre un problème)
| docker compose <COMPOSE> logs -f backend
|
ERROR. Une API saine affiche Application startup complete.
Rejouer les seeds (données de base : banques, devises)
La reconstruction ne réapplique pas forcément les seeds. Pour les forcer :
| docker compose <COMPOSE> exec backend python -m app.seeds
|
La fonction détecte les enregistrements déjà présents (elle ne crée pas de doublons).
État des conteneurs
| docker ps --filter name=transaction_
|
Up (et healthy pour le backend).
⚠️ Ne lance jamais docker compose down -v en production : le -v efface les
données (base comprise). Le -v ne s'utilise qu'en local/test pour repartir de zéro.