Architecture VPS Docker

1. Quoi ? — Définition et contexte

Une architecture multi-stack Docker désigne une organisation où plusieurs groupes de services (stacks) coexistent sur un même serveur, chacun défini par son propre fichier docker-compose.yaml. Chaque stack est autonome mais peut communiquer avec les autres via un réseau Docker partagé.

Cette infrastructure tourne sur un VPS Hostinger KVM 4 :

• 16 GB RAM / 4 vCPU / Debian 13
• 7 stacks Docker interconnectées
• 1 reverse proxy (Caddy) comme point d’entrée HTTP
• 1 tunnel SSH dédié comme point d’entrée hors HTTP (pour TimeTrackr)

Stack Docker

Une stack est un ensemble cohérent de containers qui remplissent une fonction (sécurité, automatisation, ERP, …). Docker Compose démarre, arrête et gère tous les containers d’une stack comme une unité.

Vue d’ensemble des 7 stacks

Stack	Services	Fonction	RAM ordre de grandeur
security-stack	Caddy, CrowdSec, Trivy	Reverse proxy + WAF + scanner CVE	~500 MB
n8n-stack	N8N main + 5 workers, PostgreSQL, Redis	Automatisation queue mode	~2 GB
ai-stack	Qdrant, CLI Ollama, Claude Redis, MCP Gateway, N8N MCP	IA, vecteurs, MCP	~4 GB
odoo-stack	Odoo 18, PostgreSQL	ERP (DB guig_db)	~1.5 GB
monitoring-stack	Prometheus, Grafana, Alertmanager, OTEL Collector, exporters	Observabilité + telemetry	~1.5 GB
notify-stack	DIUN, ntfy	Notifications + détection updates	~200 MB
timetrackr-stack	PostgreSQL 17 (tunnel SSH dédié)	Buffer time tracking	~150 MB

Topologie réseau

Trois familles de réseaux Docker se côtoient :

• webproxy — bridge partagé, point de routage de Caddy.
• Réseaux internes par stack (n8n-internal, odoo-internal, monitoring, ai-internal) — communication intra-stack.
• Réseaux isolés (mcp-backend, timetrackr-internal, crowdsec-internal) — surfaces réduites pour les composants sensibles (MCP gateway, base TimeTrackr, API CrowdSec).

---

2. Pourquoi ? — Enjeux et motivations

Pourquoi Docker Compose plutôt que Kubernetes ?

1. Simplicité opérationnelle — Kubernetes introduit etcd, control plane, ingress controllers, inadaptés à un serveur unique. Docker Compose démarre une stack en une commande.

2. Contraintes de ressources — L’overhead Kubernetes (2-4 GB RAM pour le control plane) consommerait 15-25 % du VPS. Docker Compose n’a pas cet overhead.

3. Pas de besoin de scaling horizontal — Pas d’auto-scaling, pas de répartition multi-nœuds. Le scaling vertical (plus de RAM/CPU) suffit.

4. Courbe d’apprentissage — Compose est maîtrisé, Kubernetes serait un investissement disproportionné pour ce cas d’usage.

Quand Kubernetes devient pertinent

Quand on a besoin de : haute disponibilité multi-nœuds, auto-scaling sur la charge, déploiements blue-green automatisés, ou gestion de plusieurs serveurs comme un cluster.

Problèmes résolus par l’approche multi-stack

Problème	Solution
Isolation des pannes	Une stack défaillante n’impacte pas les autres
Déploiement indépendant	Mise à jour d’un service sans redémarrer tout le système
Versions divergentes	Chaque stack gère ses dépendances (PG 15 pour N8N/Odoo, PG 17 pour TimeTrackr)
Sécurité par segmentation	Surfaces minimales : MCP backend isolé, base TimeTrackr hors webproxy
Observabilité	Stack dédiée qui scrape toutes les autres

---

3. Comment ? — Mise en œuvre technique

Structure du dépôt

stacks_vps/
├── security-stack/          # Caddy + CrowdSec + Trivy
├── n8n-stack/               # N8N en mode queue, 5 workers
├── ai-stack/                # Qdrant + CLI Ollama + MCP Gateway + N8N MCP
├── odoo-stack/              # Odoo 18 ERP (DB guig_db)
├── monitoring-stack/        # Prometheus + Grafana + OTEL
├── notify-stack/            # DIUN + ntfy
├── timetrackr-stack/        # PostgreSQL 17 + tunnel SSH (hors webproxy)
├── workflows/               # Documentation des workflows N8N
├── docs-external/           # 📦 Submodule : docs CLI externes
├── n8n-exports/             # 📦 Submodule : exports workflows N8N
├── blog/                    # 📦 Submodule : ce blog (Astro)
└── scripts/                 # deploy-all.sh, backup-databases.sh, …

Submodules Git

docs-external/, n8n-exports/ et blog/ sont des submodules. Après un clone : git submodule update --init --recursive (ou ./scripts/setup-dev.sh).

Réseau Docker partagé

Toutes les stacks HTTP se branchent sur le réseau externe webproxy :

networks:
  webproxy:
    external: true

Ce réseau bridge permet à Caddy d’atteindre n’importe quel container par son nom (n8n:5678, odoo:8069, grafana:3000, ntfy:80, …).

Exception : timetrackr-stack ne touche pas webproxy. Sa base PostgreSQL est exposée uniquement sur 127.0.0.1:5433, et l’accès passe par un user SSH dédié (timetrackr-tunnel) avec ForceCommand /bin/false et PermitOpen localhost:5433. Voir TimeTrackr Stack pour le détail.

Commandes de déploiement

# Créer le réseau partagé (une seule fois)
docker network create webproxy

# Démarrer toutes les stacks
./scripts/deploy-all.sh start

# Status
./scripts/deploy-all.sh status

# Logs d'une stack
./scripts/deploy-all.sh logs n8n-stack

# Redémarrer
./scripts/deploy-all.sh restart odoo-stack

# Pull + redémarrage
./scripts/deploy-all.sh pull

Ordre de démarrage recommandé

1. security-stack — Le reverse proxy doit être prêt avant les autres pour terminer les handshakes TLS.
2. monitoring-stack — Pour capter l’historique de scrape dès le boot des autres.
3. ai-stack, n8n-stack, odoo-stack, notify-stack — Dans n’importe quel ordre.
4. timetrackr-stack — Indépendante (n’a pas besoin de webproxy).

Sauvegardes

Le script scripts/backup-databases.sh (cron quotidien 03:00) produit :

• pg_dump de la base N8N (n8n).
• pg_dump de la base Odoo (guig_db) + archive du filestore.
• pg_dump de la base TimeTrackr (timetrackr_db).
• Sauvegarde de la N8N_ENCRYPTION_KEY (sans elle, les credentials sont irrécupérables).

Rotation locale (7 jours) et push GDrive (30 jours) via rclone. Échec → alerte au Notification Hub.

---

4. Et si ? — Perspectives et limites

Limites actuelles

Limite	Impact	Mitigation
Serveur unique	SPOF physique	Backups quotidiens GDrive + monitoring + alertes
Pas de HA native	Downtime au pull/restart	Fenêtres planifiées, self-restart pattern pour n8n-stack
Scaling vertical uniquement	Plafond matériel KVM 4	Migration vers KVM 8 ou multi-nœuds possible
AI stack la plus gourmande	~4 GB sur 16 disponibles	Sub-processus CLI court-vivants, pas de modèle local

Scénarios d’évolution

Si je dois répliquer ce setup pour un autre client :

• Les stacks deviennent des modèles, packagés en namespaces Kubernetes (ou Compose templates).
• Helm charts pour les variations par client (DB names, secrets, domaines).

Si les besoins IA explosent :

• L’ai-stack devient externalisable vers un cloud GPU (l’interface API Ollama-compatible facilite le swap).
• Garder Qdrant local pour la latence RAG, pousser CLI Ollama vers un host dédié.

Si 16 GB devient insuffisant :

• Upgrade KVM 8 (32 GB) — solution la plus simple.
• Ou déporter monitoring + notify sur un second serveur, le webproxy peut s’étendre en overlay multi-host.

Si la souveraineté SSH doit être renforcée :

• Migration du tunnel TimeTrackr vers WireGuard (wg.guigpap.com).
• Permet d’ouvrir d’autres services privés (admin Postgres, Redis interne) sans multiplier les bouncers SSH.

Architecture pérenne

Ce setup couvre les besoins actuels et prévisibles à 12-18 mois. Sa modularité permet une évolution progressive (par stack) sans refonte complète.

---

Pages liées

Infrastructure

• Security Stack — Caddy + CrowdSec + Trivy + llms.txt
• N8N en mode Queue — Automatisation scalable
• AI Stack — Qdrant + CLI Ollama + MCP Gateway
• Odoo 18 sur Docker — Configuration ERP, modules custom
• Monitoring Stack — Prometheus + Grafana + Telemetry → Odoo
• Notify Stack — DIUN + ntfy
• TimeTrackr Stack — PostgreSQL 17 + tunnel SSH
• Pourquoi Odoo — Choix de l’ERP

Workflows orchestrant ces stacks

• Telegram Orchestrator — Hub de contrôle
• Docker Updates — Auto-update via DIUN + approbation
• Notification Hub — Routage centralisé
• Claude Code Telemetry — Sessions → Odoo via Prometheus
• GitHub-Odoo Sync — Issues / PRs / commits → tâches Odoo
• TimeTrackr → Odoo — Timesheets via webhooks

Référence

• Glossaire — Définitions des termes techniques