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.

# ==========================================
# 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

# 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

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

🟧 MinIO (Compatible S3)

# 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

# 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

# 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)

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)

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)

cd veza-stream-server
export DATABASE_URL=$VEZA_LAB_DSN
# Jouer les migrations
cargo sqlx migrate run

5. Points de Vigilance pour les Audits

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.
Ports :
- Backend : 8080
- Chat : 8081
- Stream : 3002 (Attention : la config par défaut peut indiquer 3000 ou 8082, mais le code compile sur 3002).
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).

6.2 KiB Raw Blame History