194 lines
5.6 KiB
Markdown
194 lines
5.6 KiB
Markdown
# Nouvelle Structure des Variables d'Environnement
|
|
|
|
## Vue d'ensemble
|
|
|
|
La structure des variables d'environnement a été réorganisée pour séparer les variables par projet. Cette nouvelle architecture améliore la maintenabilité et la sécurité en isolant les configurations de chaque service.
|
|
|
|
## Structure Actuelle
|
|
|
|
```
|
|
4NK_env/
|
|
├── env/
|
|
│ ├── lecoffre_node/
|
|
│ │ └── .env
|
|
│ ├── sdk_relay/
|
|
│ │ └── .env
|
|
│ ├── sdk_storage/
|
|
│ │ └── .env
|
|
│ ├── ihm_client/
|
|
│ │ └── .env
|
|
│ ├── lecoffre-front/
|
|
│ │ └── .env
|
|
│ ├── blindbit-oracle/
|
|
│ │ └── .env
|
|
│ ├── monitoring/
|
|
│ │ └── .env
|
|
│ └── sdk_signer/
|
|
│ └── .env
|
|
└── .env.master (conservé pour compatibilité)
|
|
```
|
|
|
|
## Projets et Variables
|
|
|
|
### 1. lecoffre_node
|
|
**Fichier**: `env/lecoffre_node/.env`
|
|
**Variables principales**:
|
|
- Configuration des domaines (DOMAIN, BOOTSTRAP_DOMAIN, etc.)
|
|
- Configuration Git (GITEA_BASE_URL, GIT_TOKEN, etc.)
|
|
- Configuration IDNOT (IDNOT_API_KEY, IDNOT_CLIENT_ID, etc.)
|
|
- Configuration serveur (APP_HOST, API_BASE_URL, etc.)
|
|
|
|
### 2. sdk_relay
|
|
**Fichier**: `env/sdk_relay/.env`
|
|
**Variables principales**:
|
|
- SDK_RELAY_* (SDK_RELAY_CORE_URL, SDK_RELAY_WS_URL, etc.)
|
|
- Variables legacy (core_url, ws_url, etc.)
|
|
- Configuration des ports (RELAY_PORT, RELAY_HTTP_PORT)
|
|
|
|
### 3. sdk_storage
|
|
**Fichier**: `env/sdk_storage/.env`
|
|
**Variables principales**:
|
|
- STORAGE_URL, STORAGE_PORT, STORAGE_DATA_DIR
|
|
|
|
### 4. ihm_client
|
|
**Fichier**: `env/ihm_client/.env`
|
|
**Variables principales**:
|
|
- VITE_* (VITE_API_BASE_URL, VITE_WS_URL, etc.)
|
|
- VITE_JWT_SECRET_KEY (variable sensible)
|
|
|
|
### 5. lecoffre-front
|
|
**Fichier**: `env/lecoffre-front/.env`
|
|
**Variables principales**:
|
|
- NEXT_PUBLIC_* (NEXT_PUBLIC_4NK_URL, NEXT_PUBLIC_IDNOT_BASE_URL, etc.)
|
|
- NEXT_PUBLIC_IDNOT_CLIENT_ID (variable sensible)
|
|
|
|
### 6. blindbit-oracle
|
|
**Fichier**: `env/blindbit-oracle/.env`
|
|
**Variables principales**:
|
|
- BLINDBIT_API_PORT, BITCOIN_RPC_URL
|
|
|
|
### 7. monitoring
|
|
**Fichier**: `env/monitoring/.env`
|
|
**Variables principales**:
|
|
- Configuration Grafana (GRAFANA_ADMIN_USER, GRAFANA_ADMIN_PASSWORD, etc.)
|
|
- Configuration Loki (LOKI_URL, LOKI_CONFIG_FILE, etc.)
|
|
- Configuration Status API (STATUS_API_PORT, STATUS_API_HOST)
|
|
- Variables Bitcoin pour monitoring
|
|
|
|
### 8. sdk_signer
|
|
**Fichier**: `env/sdk_signer/.env`
|
|
**Variables principales**:
|
|
- SIGNER_* (SIGNER_PORT, SIGNER_DATABASE_PATH, etc.)
|
|
- SIGNER_API_KEY (variable sensible)
|
|
|
|
## Migration depuis .env.master
|
|
|
|
### Avant (Structure Monolithique)
|
|
```yaml
|
|
# docker-compose.yml
|
|
services:
|
|
sdk_relay:
|
|
env_file:
|
|
- /home/debian/4NK_env/.env.master
|
|
```
|
|
|
|
### Après (Structure Séparée)
|
|
```yaml
|
|
# docker-compose.yml
|
|
services:
|
|
sdk_relay:
|
|
env_file:
|
|
- /home/debian/4NK_env/env/sdk_relay/.env
|
|
```
|
|
|
|
## Avantages de la Nouvelle Structure
|
|
|
|
1. **Séparation des responsabilités**: Chaque projet a ses propres variables
|
|
2. **Sécurité améliorée**: Isolation des variables sensibles par service
|
|
3. **Maintenance facilitée**: Modification des variables sans impact sur les autres services
|
|
4. **Déploiement modulaire**: Possibilité de déployer des services indépendamment
|
|
5. **Debugging simplifié**: Variables spécifiques à un service dans un seul fichier
|
|
|
|
## Scripts de Gestion
|
|
|
|
### Ajout de Variables Manquantes
|
|
```bash
|
|
./scripts/add-missing-env-vars-new.sh
|
|
```
|
|
|
|
### Test de Configuration
|
|
```bash
|
|
./scripts/test-env-config.sh
|
|
```
|
|
|
|
### Démarrage des Services
|
|
```bash
|
|
./scripts/lecoffre_node/start.sh
|
|
```
|
|
|
|
## Variables Sensibles
|
|
|
|
Les variables marquées comme sensibles sont identifiées par la section :
|
|
```bash
|
|
# ================== /!\ sensible =========================
|
|
```
|
|
|
|
Ces variables contiennent :
|
|
- Clés API (IDNOT_API_KEY, SIGNER_API_KEY)
|
|
- Secrets JWT (VITE_JWT_SECRET_KEY)
|
|
- Identifiants clients (IDNOT_CLIENT_ID, NEXT_PUBLIC_IDNOT_CLIENT_ID)
|
|
- Mots de passe (IDNOT_CLIENT_SECRET, GRAFANA_ADMIN_PASSWORD)
|
|
|
|
## Compatibilité
|
|
|
|
Le fichier `.env.master` est conservé pour la compatibilité avec les anciens scripts, mais il est recommandé d'utiliser la nouvelle structure pour tous les nouveaux développements.
|
|
|
|
## Migration des Scripts Existants
|
|
|
|
Les scripts ont été mis à jour pour utiliser la nouvelle structure :
|
|
- `docker-compose.yml`: Pointe vers les nouveaux fichiers .env
|
|
- `scripts/lecoffre_node/start.sh`: Vérifie les fichiers par projet
|
|
- `scripts/test-env-config.sh`: Teste la nouvelle structure
|
|
|
|
## Recommandations
|
|
|
|
1. **Ne jamais modifier les valeurs des variables** sans validation préalable
|
|
2. **Utiliser les scripts de gestion** pour ajouter/modifier des variables
|
|
3. **Tester la configuration** après chaque modification
|
|
4. **Maintenir la cohérence** entre les fichiers .env et la documentation
|
|
5. **Sauvegarder** avant toute modification importante
|
|
|
|
## Troubleshooting
|
|
|
|
### Problème : Service ne trouve pas ses variables
|
|
**Solution**: Vérifier que le fichier .env correspondant existe dans `env/<service>/.env`
|
|
|
|
### Problème : Variables manquantes
|
|
**Solution**: Utiliser le script `add-missing-env-vars-new.sh`
|
|
|
|
### Problème : Conflit de variables
|
|
**Solution**: Vérifier que les variables sont dans le bon fichier projet
|
|
|
|
## Maintenance
|
|
|
|
### Ajout d'un Nouveau Service
|
|
1. Créer le dossier `env/<nouveau_service>/`
|
|
2. Créer le fichier `.env` avec les variables nécessaires
|
|
3. Mettre à jour `docker-compose.yml`
|
|
4. Mettre à jour les scripts de test
|
|
5. Documenter les variables dans ce fichier
|
|
|
|
### Suppression d'un Service
|
|
1. Sauvegarder le fichier .env
|
|
2. Supprimer le dossier `env/<service>/`
|
|
3. Mettre à jour `docker-compose.yml`
|
|
4. Mettre à jour les scripts de test
|
|
5. Mettre à jour la documentation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|