mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
archi docker
This commit is contained in:
@@ -406,3 +406,93 @@ Principes :
|
||||
- Les endpoints critiques documentent leur stratégie d’idempotence
|
||||
- Les retries sont maîtrisés et prévisibles
|
||||
- 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
|
||||
n’est définie.
|
||||
|
||||
Avec le temps cela rend :
|
||||
|
||||
- les sauvegardes ambiguës
|
||||
- le nettoyage risqué
|
||||
- la compréhension de l’infrastructure difficile
|
||||
- la reconstruction d’un 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 d’infrastructure
|
||||
(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 d’un projet possible sans risque pour les autres
|
||||
- lisibilité immédiate de l’infrastructure
|
||||
- reproductibilité de l’environnement
|
||||
|
||||
### 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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user