veza/docs/ENVIRONMENT_REAL_SETUP.md

# Environnement Réel Unifié - Veza

Ce document décrit la procédure pour mettre en place un environnement de développement **réel, stable et unifié** pour l'ensemble des services Veza (Backend Go, Chat Server Rust, Stream Server Rust).

## 1. Synthèse de l'Analyse

L'analyse du code source a révélé les dépendances suivantes pour chaque service :

| Service | PostgreSQL | Redis | MinIO/S3 | RabbitMQ | Ports | Notes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **`veza-backend-api`** | ✅ Requis (`DATABASE_URL`) | ✅ Requis (`REDIS_URL`) | ✅ Requis (`USE_S3=true`) | ✅ Requis (`RABBITMQ_URL`) | `8080` (API) | Service central, gère le stockage S3. |
| **`veza-chat-server`** | ✅ Requis (`DATABASE_URL`) | ⚠️ Optionnel (`REDIS_URL`) | ❌ Non utilisé directement | ✅ Requis (`RABBITMQ_URL`) | `8081` (WebSocket) | Utilise Postgres pour users/messages. RabbitMQ pour événements. |
| **`veza-stream-server`** | ✅ Requis (`DATABASE_URL`) | ⚠️ Optionnel (`REDIS_URL`) | ❌ Utilise `audio_dir` | ✅ Requis (`RABBITMQ_URL`) | `3002` (Stream) | Port par défaut 3002 (et non 8082). Utilise `sqlx`. |

**Conclusion** : Un environnement unifié avec PostgreSQL, Redis, MinIO (pour le backend) et RabbitMQ est nécessaire pour valider l'ensemble du système.

---

## 2. Configuration Unifiée (.env.lab)

Copiez ce contenu dans un fichier `.env.lab` à la racine du projet.

```bash
# ==========================================
# VEZA LAB ENVIRONMENT - UNIFIED CONFIG
# ==========================================
# Usage: source .env.lab
# ou docker run --env-file .env.lab ...

# 1. CORE VARIABLES
APP_ENV=development
ENVIRONMENT=development
# Secrets (Pour environnement LAB uniquement)
JWT_SECRET=veza_lab_secret_key_minimum_32_chars_long_2025
SECRET_KEY=veza_lab_secret_key_minimum_32_chars_long_2025

# 2. DATABASES (POSTGRESQL)
# DSN Unifié pour tous les services
# Note: sslmode=disable est crucial pour le local
VEZA_LAB_DSN=postgres://veza:veza_password@localhost:5432/veza_lab?sslmode=disable

# Mapping Backend Go
DATABASE_URL=${VEZA_LAB_DSN}
VEZA_DATABASE_DSN=${VEZA_LAB_DSN}
DB_HOST=localhost
DB_PORT=5432
DB_USER=veza
DB_PASSWORD=veza_password
DB_NAME=veza_lab

# Mapping Chat Server & Stream Server (Rust)
# Ils utilisent directement DATABASE_URL définie ci-dessus

# 3. REDIS
REDIS_URL=redis://localhost:6379/0

# 4. OBJECT STORAGE (MINIO)
USE_S3=true
S3_ENDPOINT=http://localhost:9000
S3_ACCESS_KEY=veza_minio
S3_SECRET_KEY=veza_minio_password
S3_BUCKET=veza-bucket
S3_REGION=us-east-1
S3_FORCE_PATH_STYLE=true

# 5. MESSAGE BROKER (RABBITMQ)
RABBITMQ_URL=amqp://guest:guest@localhost:5672/
RABBITMQ_ENABLE=true

# 6. PORTS
APP_PORT=8080
CHAT_SERVER_PORT=8081
STREAM_PORT=3002

# 7. LOGGING
LOG_LEVEL=info
RUST_LOG=info,sqlx=warn
```

---

## 3. Commandes de Démarrage (Infrastructure)

Lancez ces commandes pour démarrer l'infrastructure réelle (sans mocks).

### 🟦 PostgreSQL 15
```bash
# Lancer PostgreSQL
docker run -d --name veza-postgres \
  -e POSTGRES_USER=veza \
  -e POSTGRES_PASSWORD=veza_password \
  -e POSTGRES_DB=veza_lab \
  -p 5432:5432 \
  postgres:15-alpine

# Attendre que la base soit prête (optionnel, ou juste attendre 5s)
sleep 5
```

### 🟥 Redis
```bash
# Lancer Redis
docker run -d --name veza-redis \
  -p 6379:6379 \
  redis:7-alpine
```

### 🟧 MinIO (Compatible S3)
```bash
# Lancer MinIO
docker run -d --name veza-minio \
  -p 9000:9000 -p 9001:9001 \
  -e MINIO_ROOT_USER=veza_minio \
  -e MINIO_ROOT_PASSWORD=veza_minio_password \
  minio/minio server /data --console-address ":9001"

# Créer le bucket (nécessite le client mc ou via l'interface web http://localhost:9001)
# Commande via docker one-off :
docker run --rm --entrypoint sh minio/mc -c "\
  mc alias set myminio http://host.docker.internal:9000 veza_minio veza_minio_password && \
  mc mb myminio/veza-bucket && \
  mc anonymous set public myminio/veza-bucket"
```
*Note: Si `host.docker.internal` ne fonctionne pas sous Linux, utilisez l'IP locale ou `--network host` pour le client mc.*

### 🟩 RabbitMQ
```bash
# Lancer RabbitMQ avec Management Plugin
docker run -d --name veza-rabbitmq \
  -p 5672:5672 -p 15672:15672 \
  rabbitmq:3-management-alpine
```

---

## 4. Validation et Initialisation

Une fois les conteneurs lancés, validez l'environnement et jouez les migrations.

### Test de connexion PostgreSQL
```bash
# Chargez les variables
set -a; source .env.lab; set +a

# Test simple
psql "$VEZA_LAB_DSN" -c "SELECT NOW() as connection_success;"
```

### Migrations

**1. Backend Go (Initialisation du schéma principal)**
```bash
cd veza-backend-api
# Utiliser le script de migration ou go run
# Exemple (adapter selon scripts disponibles):
export DATABASE_URL=$VEZA_LAB_DSN
go run cmd/migrate/main.go up
# OU si vous utilisez un outil externe comme migrate:
# migrate -database "$VEZA_LAB_DSN" -path migrations up
```

**2. Chat Server (Rust SQLx)**
```bash
cd veza-chat-server
export DATABASE_URL=$VEZA_LAB_DSN
# Vérifier la validité des requêtes SQLx
cargo sqlx prepare --check --workspace
# Jouer les migrations (si dossier migrations présent)
cargo sqlx migrate run
```

**3. Stream Server (Rust SQLx)**
```bash
cd veza-stream-server
export DATABASE_URL=$VEZA_LAB_DSN
# Jouer les migrations
cargo sqlx migrate run
```

---

## 5. Points de Vigilance pour les Audits

1.  **Conflits de Schéma** : Les trois services partagent la **même base de données** (`veza_lab`). Assurez-vous que les noms de tables ne rentrent pas en conflit entre le backend Go et les services Rust (ex: table `users` gérée par qui ?).
    *   *Risque* : Le backend Go et le Chat Server peuvent tous deux vouloir gérer la table `users`. Il faudra vérifier si le Chat Server doit lire la table `users` du backend ou s'il a sa propre table.
2.  **Ports** :
    *   Backend : 8080
    *   Chat : 8081
    *   Stream : 3002 (Attention : la config par défaut peut indiquer 3000 ou 8082, mais le code compile sur 3002).
3.  **Réseau Docker** : Si vous lancez les services en local (hors Docker) et les DBs dans Docker, utilisez `localhost`. Si tout est dans Docker Compose, utilisez les noms de services (`veza-postgres`, etc.). Le fichier `.env.lab` ci-dessus est configuré pour une exécution des services sur la machine hôte (`localhost`).