archi docker

This commit is contained in:
MaksTinyWorkshop
2026-03-06 22:55:43 +01:00
parent 17263213ef
commit 7a55cefc31

View File

@@ -406,3 +406,93 @@ Principes :
- Les endpoints critiques documentent leur stratégie didempotence - Les endpoints critiques documentent leur stratégie didempotence
- Les retries sont maîtrisés et prévisibles - Les retries sont maîtrisés et prévisibles
- Les automatisations et intégrations peuvent être rejouées sans risque - Les automatisations et intégrations peuvent être rejouées sans risque
---
## Convention de structure pour les projets Docker et les données persistantes
- Date : 2026-03-06
- Statut : Accepted
- Périmètre : infra
### Contexte
Sur un serveur de développement (NUC / VM docker-dev), Docker mélange facilement
code applicatif, données persistantes, volumes et backups si aucune convention
nest définie.
Avec le temps cela rend :
- les sauvegardes ambiguës
- le nettoyage risqué
- la compréhension de linfrastructure difficile
- la reconstruction dun environnement compliquée
Une structure simple et explicite permet déviter ces problèmes.
### Options envisagées
- Laisser Docker gérer implicitement les volumes (`/var/lib/docker/volumes`)
- Laisser chaque projet organiser librement ses dossiers
- Définir une convention globale claire séparant code, données et sauvegardes
### Décision
La structure standard suivante est adoptée sur les machines dinfrastructure
(NUC / serveurs de développement) :
```
/srv
├ projects
├ docker-data
└ backups
```
Principes :
- `/srv/projects`
contient les projets applicatifs (code, `docker-compose.yml`, `.env`, scripts).
- `/srv/docker-data`
contient les données persistantes des conteneurs (bases de données, uploads,
état applicatif).
- `/srv/backups`
contient les dumps, archives et exports destinés à la sauvegarde.
### Justification
- séparation claire **code / données / sauvegardes**
- sauvegardes plus simples et plus fiables
- nettoyage dun projet possible sans risque pour les autres
- lisibilité immédiate de linfrastructure
- reproductibilité de lenvironnement
### Conséquences
Les conteneurs utilisent en priorité des **bind mounts explicites**, par exemple :
```txt
/srv/docker-data/monapp-postgres:/var/lib/postgresql/data
```
Les volumes Docker implicites (`/var/lib/docker/volumes`) sont évités quand la
lisibilité et la maintenabilité priment.
Les données critiques à sauvegarder se trouvent principalement dans :
```
/srv/projects
/srv/docker-data
```
Convention de nommage recommandée pour les dossiers de données :
```
ex :
rl799-postgres
monapp-redis
n8n-postgres
```
---