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 endpoints critiques documentent leur stratégie d’idempotence
|
||||||
- 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
|
||||||
|
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