# 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) |
| Chat Server | `veza-chat-server` | 10.10.10.3 | 8081 | Serveur Chat Rust (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
- `chat-server.env` - Configuration Chat Server
- `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 chat-server.env et 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-chat-server.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
- **Chat Server** : ws://10.10.10.3:8081/ws
- **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)
- `/ws/*` → Chat Server (10.10.10.3:8081)
- `/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