veza/config/incus/README.md
senke 279a10d317 chore(cleanup): remove veza-chat-server directory and all operational references
Chat functionality is now fully handled by the Go backend (since v0.502).
Remove the deprecated Rust chat server and all its references from:
- CI/CD workflows (ci.yml, cd.yml, rust-ci.yml, chat-ci.yml)
- Monitoring & proxy config (prometheus, caddy, haproxy)
- Incus deployment scripts and documentation
- Monorepo config (package.json, dependabot, GH templates)
2026-02-22 21:13:00 +01:00

235 lines
6 KiB
Markdown

# Incus/LXD Deployment Configuration
Ce dossier contient les configurations pour déployer Veza avec Incus (LXD) **sans Docker** - déploiement natif complet.
## Prérequis
```bash
# Installer Incus
sudo snap install incus
# Initialiser Incus (première fois)
sudo incus admin init
# Vérifier les outils de build
make check-tools-incus
```
## Architecture
Chaque service est déployé dans un container Incus séparé avec des binaires natifs :
| Service | Container | IP | Port | Description |
|---------|-----------|-----|------|-------------|
| Infrastructure | `veza-infra` | 10.10.10.10 | 5432, 6379 | PostgreSQL + Redis |
| Backend API | `veza-backend-api` | 10.10.10.2 | 8080 | Backend Go (binaire natif) |
| Stream Server | `veza-stream-server` | 10.10.10.4 | 3002 | Serveur Stream Rust (binaire natif) |
| Web Frontend | `veza-web` | 10.10.10.5 | 80 | Frontend React (Apache - fichiers statiques uniquement) |
| HAProxy | `veza-haproxy` | 10.10.10.6 | 80 | Reverse Proxy |
## Réseau
Le réseau `veza-network` est créé automatiquement avec :
- Subnet: 10.10.10.0/24
- NAT activé pour l'accès externe
- Adresses IP statiques pour chaque service
## Déploiement
### Déploiement complet (recommandé)
```bash
# Build et déploiement complet
make deploy-incus
```
Cette commande :
1. Compile tous les services nativement (Go, Rust, Node.js)
2. Crée le réseau Incus
3. Déploie l'infrastructure (PostgreSQL, Redis)
4. Déploie tous les services applicatifs
5. Démarre tous les services
### Déploiement étape par étape
```bash
# 1. Build natif de tous les services
make build-all-native
# 2. Setup réseau
make incus-setup-network
# 3. Déployer l'infrastructure
make incus-deploy-infra
# 4. Déployer les services
make incus-deploy-all-native
# 5. Démarrer tous les services
make incus-start-all
```
### Déploiement d'un service spécifique
```bash
# Build un service
./config/incus/build-native.sh backend-api
# Déployer un service
make incus-deploy-service-native SERVICE=backend-api
# Démarrer un service
incus exec veza-backend-api -- systemctl start veza-backend-api
```
## Gestion des services
### Vérifier le déploiement
```bash
# Script de vérification
./config/incus/verify-deployment.sh
# Ou manuellement
make status-full
```
### Logs
```bash
# Logs d'un service
make incus-logs SERVICE=backend-api
# Ou directement
incus exec veza-backend-api -- journalctl -u veza-backend-api -f
```
### Arrêter/Démarrer
```bash
# Arrêter tous les containers
make incus-stop-all
# Démarrer un service
incus exec veza-backend-api -- systemctl start veza-backend-api
# Redémarrer un service
incus exec veza-backend-api -- systemctl restart veza-backend-api
# Status d'un service
incus exec veza-backend-api -- systemctl status veza-backend-api
```
## Configuration
### Variables d'environnement
Les fichiers de configuration sont dans `config/incus/env/` :
- `backend-api.env` - Configuration Backend API
- `stream-server.env` - Configuration Stream Server
**Important** : Ces fichiers `.env` ne sont pas versionnés (ils contiennent des secrets).
Créez-les localement à partir de `env/env.example` :
```bash
cd config/incus/env
# Créer les fichiers à partir du template et remplir les valeurs
cp env.example backend-api.env # puis éditer
# Idem pour stream-server.env
```
Modifiez ces fichiers avant le déploiement ou éditez-les dans les containers :
```bash
incus exec veza-backend-api -- nano /etc/veza/backend-api.env
incus exec veza-backend-api -- systemctl restart veza-backend-api
```
### Services systemd
Les fichiers systemd sont dans `config/incus/systemd/` :
- `veza-backend-api.service`
- `veza-stream-server.service`
## Accès aux services
Une fois déployé, les services sont accessibles via :
- **HAProxy (point d'entrée)** : http://10.10.10.6:80
- **Backend API** : http://10.10.10.2:8080
- **Stream Server** : ws://10.10.10.4:3002/stream
- **Web Frontend** : http://10.10.10.5:80
## Dépannage
### Container ne démarre pas
```bash
# Vérifier les logs du container
incus exec veza-backend-api -- journalctl -xe
# Vérifier la configuration réseau
incus network show veza-network
incus list -c n4
```
### Service ne démarre pas
```bash
# Vérifier les logs systemd
incus exec veza-backend-api -- systemctl status veza-backend-api
incus exec veza-backend-api -- journalctl -u veza-backend-api -n 50
# Vérifier les variables d'environnement
incus exec veza-backend-api -- cat /etc/veza/backend-api.env
```
### Problème de connectivité
```bash
# Tester la connectivité entre containers
incus exec veza-backend-api -- ping -c 3 10.10.10.10
incus exec veza-backend-api -- curl http://10.10.10.10:5432
```
### Rebuild complet
```bash
# Supprimer tous les containers
make incus-stop-all
for container in $(incus list -c n --format csv | grep veza-); do
incus delete $container --force
done
# Rebuild et redéployer
make deploy-incus
```
## Architecture de Routing
**HAProxy** est le point d'entrée principal et gère tout le routing :
- `/api/v1/*` → Backend API (10.10.10.2:8080)
- `/stream/*` → Stream Server (10.10.10.4:3002)
- `/*` → Web Frontend (10.10.10.5:80)
**Apache** dans `veza-web` sert uniquement les fichiers statiques du frontend React. HAProxy route toutes les requêtes vers les services appropriés.
## Différences avec Docker
Le déploiement Incus natif diffère du déploiement Docker :
1. **Pas de Docker** : Les services s'exécutent directement dans les containers Incus
2. **Binaires natifs** : Compilation locale puis copie dans les containers
3. **Systemd** : Gestion des services via systemd dans chaque container
4. **IP statiques** : Adresses IP fixes pour chaque service
5. **Performance** : Overhead minimal, performances proches du bare metal
6. **HAProxy unique** : Un seul reverse proxy gère tout le routing (pas de Nginx)
## Avantages
- ✅ Pas de dépendance Docker
- ✅ Performance optimale
- ✅ Isolation complète entre services
- ✅ Gestion native via systemd
- ✅ Configuration réseau flexible
- ✅ Déploiement rapide et reproductible