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 est déployée sur un VPS Hostinger KVM 4 :

• 16 GB RAM / 4 vCPU / Debian
• 6 stacks Docker interconnectées
• 1 reverse proxy (Caddy) comme unique point d’entrée

Stack Docker

Une stack est un ensemble cohérent de conteneurs qui remplissent une fonction métier (automatisation, monitoring, ERP…). Docker Compose permet de démarrer, arrêter et gérer tous les conteneurs d’une stack comme une unité.

Vue d’ensemble des stacks

Stack	Services	Fonction	RAM estimée
security-stack	Caddy, CrowdSec	Reverse proxy + WAF	~500 MB
n8n-stack	N8N, 5 workers, PostgreSQL, Redis	Automatisation	~2 GB
ai-stack	Qdrant, Claude Ollama API, Redis	IA et vecteurs	~4 GB
odoo-stack	Odoo 18, PostgreSQL	ERP	~1.5 GB
monitoring-stack	Prometheus, Grafana, Alertmanager, OTEL	Observabilité	~1.5 GB
notify-stack	DIUN, ntfy	Notifications	~200 MB

Flux réseau

Internet
    │
    ▼ (ports 80, 443, 443/udp)
┌─────────────────────────────────────────────────────┐
│              Caddy (security-stack)                  │
│  ├─ TLS automatique (Let's Encrypt)                 │
│  ├─ HTTP/3 QUIC                                     │
│  └─ CrowdSec bouncer (WAF)                          │
└───────────────────────┬─────────────────────────────┘
                        │
                        ▼ (réseau webproxy)
    ┌───────────────────┼───────────────────┐
    │                   │                   │
    ▼                   ▼                   ▼
┌─────────┐      ┌─────────────┐      ┌──────────┐
│   N8N   │      │   Grafana   │      │   Odoo   │
│  :5678  │      │    :3000    │      │  :8069   │
└─────────┘      └─────────────┘      └──────────┘

---

2. Pourquoi ? — Enjeux et motivations

Pourquoi Docker Compose plutôt que Kubernetes ?

Quatre critères ont orienté ce choix architectural :

1. Simplicité opérationnelle — Kubernetes introduit une complexité significative (etcd, control plane, ingress controllers) inadaptée à un serveur unique. Docker Compose permet de démarrer une stack en une commande.

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

3. Absence de besoin de scaling horizontal — Cette infrastructure ne nécessite pas d’auto-scaling ou de répartition sur plusieurs nœuds. Le scaling vertical (plus de RAM/CPU) suffit.

4. Courbe d’apprentissage — La maîtrise de Compose est acquise, celle de Kubernetes demanderait un investissement disproportionné pour ce cas d’usage.

Quand choisir Kubernetes ?

Kubernetes devient pertinent lorsque vous avez besoin de : haute disponibilité multi-nœuds, auto-scaling basé sur la charge, déploiements blue-green, ou gestion de clusters de plusieurs serveurs.

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

Problème	Solution apportée
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
Gestion des dépendances	Chaque stack gère ses propres versions (PostgreSQL N8N ≠ PostgreSQL Odoo)
Sécurité	Point d’entrée unique avec TLS + WAF
Observabilité	Stack dédiée au monitoring de toutes les autres

---

3. Comment ? — Mise en œuvre technique

Structure du dépôt

stacks_vps/
├── security-stack/          # Caddy + CrowdSec
├── n8n-stack/               # N8N en mode queue
├── ai-stack/                # Qdrant + Claude Ollama
├── odoo-stack/              # Odoo 18 ERP
├── monitoring-stack/        # Prometheus + Grafana
├── notify-stack/            # DIUN + ntfy
├── workflows/               # Documentation N8N
├── docs-external/           # 📦 Submodule: docs CLI externes
├── n8n-exports/             # 📦 Submodule: exports workflows N8N
├── blog/                    # 📦 Submodule: ce blog (Astro)
└── scripts/                 # Scripts de déploiement

Submodules Git

Les dossiers docs-external/, n8n-exports/ et blog/ sont des submodules Git. Après un clone : git submodule update --init --recursive

Réseau Docker partagé

Toutes les stacks communiquent via le réseau externe webproxy :

networks:
  webproxy:
    external: true

Ce réseau bridge permet à Caddy de router le trafic vers n’importe quel conteneur, quelle que soit sa stack d’origine. Les services s’adressent par leur nom de conteneur (ex: n8n:5678).

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

# Vérifier le status
./scripts/deploy-all.sh status

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

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

Ordre de démarrage recommandé

1. security-stack — Le reverse proxy doit être prêt avant les autres
2. monitoring-stack — Pour observer le démarrage des services
3. Autres stacks — Dans n’importe quel ordre

---

4. Et si ? — Perspectives et limites

Limites actuelles de l’architecture

Limite	Impact	Mitigation
Serveur unique	Single point of failure	Backups réguliers + monitoring
Pas de HA native	Downtime lors des mises à jour	Fenêtres de maintenance planifiées
Scaling vertical uniquement	Plafond hardware	Migration possible vers multi-nœuds

Scénarios d’évolution

Si le concept N8N + Odoo est répliqué pour d’autres entreprises :

• Migration vers Kubernetes devient pertinente
• Chaque client pourrait avoir son namespace isolé
• Les stacks actuelles serviraient de templates Helm

Si les besoins IA augmentent :

• L’ai-stack (4 GB) est la plus gourmande
• Externalisation possible vers un service cloud GPU
• L’architecture découplée facilite cette migration

Si 16 GB RAM devient insuffisant :

• Option 1 : Upgrade VPS vers 32 GB
• Option 2 : Déporter certaines stacks (monitoring, IA) vers un second serveur
• Le réseau webproxy peut être étendu en overlay multi-host

Architecture pérenne

Cette architecture répond aux besoins actuels et prévisibles. Sa modularité permet une évolution progressive sans refonte complète.

---

Pages liées

Infrastructure

• Security Stack : Caddy + CrowdSec — Reverse proxy et WAF
• N8N en mode Queue — Automatisation scalable
• Monitoring Stack — Prometheus + Grafana
• AI Stack — Qdrant + Claude Ollama
• Odoo 18 sur Docker — Configuration ERP
• Pourquoi Odoo — Choix de l’ERP

Workflows

• Telegram Orchestrator — Bot de contrôle
• Docker Auto-Updates — Mises à jour automatiques

Référence

• Glossaire — Définitions des termes techniques