43 lines
2.4 KiB
Markdown
43 lines
2.4 KiB
Markdown
# Politique de centralisation des variables et secrets (.env.master)
|
||
|
||
Objectif: toutes les variables d’environnement (publiques et privées) utilisées par les services doivent être centralisées dans `lecoffre_node/.env.master`. Aucun fichier Dockerfile ni docker-compose ne doit redéclarer des valeurs en dur qui divergeraient.
|
||
|
||
## Règles
|
||
|
||
- Fichier source unique: `lecoffre_node/.env.master`
|
||
- Chargement docker-compose: tous les services référencent `env_file: .env.master` et n’overrident pas les clés déjà définies.
|
||
- Aucune valeur sensible dans les Dockerfile/images. Utiliser exclusivement les variables passées par l’environnement (build args pour le front, runtime env pour les autres).
|
||
- Variables publiques Next.js: préfixe `NEXT_PUBLIC_` (intégrées au build). Variables privées: sans préfixe (non exposées au client).
|
||
- Secrets: clés API, tokens, mots de passe restent dans `.env.master` (jamais commités hors de ce dépôt privé). Fournir un `ENV_EXAMPLE.md` synchronisé.
|
||
|
||
## Mapping par service
|
||
|
||
- lecoffre-front (Next.js)
|
||
- Build-time: `NEXT_PUBLIC_*` via docker-compose build args → Dockerfile ARG/ENV → Next publicRuntimeConfig/env
|
||
- Runtime: idem (les valeurs restent exportées pour l’inspection)
|
||
- sdk_signer
|
||
- Runtime uniquement: `SIGNER_*` (ex: `SIGNER_API_KEY`, `SIGNER_WS_URL`, etc.) chargées via `env_file` sans override local.
|
||
- sdk_relay, sdk_storage, ihm_client
|
||
- Runtime: variables `SDK_RELAY_*`, `VITE_*` (pour IHM), etc. via `.env.master`
|
||
- Autres services (bitcoin, blindbit, …)
|
||
- Utiliser l’env pour toute config personnalisable; ne pas coder en dur.
|
||
|
||
## Bonnes pratiques
|
||
|
||
- N’ajouter de nouvelles variables qu’en les documentant dans `ENV_EXAMPLE.md` et ce fichier.
|
||
- Préférer des URLs de services Docker (ex: `http://service:port`) au lieu d’IP/host externes.
|
||
- Interdire toute duplication: si une valeur existe dans `.env.master`, ne pas la re-déclarer ailleurs.
|
||
- Logique de fallback uniquement côté code applicatif (jamais dans l’infra).
|
||
|
||
## Vérification rapide
|
||
|
||
- Front: `GET /lecoffre/api/env` et `/lecoffre/env` (no-store) pour voir les `NEXT_PUBLIC_*` en vigueur.
|
||
- Container: `docker exec <svc> env | grep -E '^(PREFIX_)'` pour contrôler.
|
||
|
||
## Process
|
||
|
||
1) Ajouter/mettre à jour la variable dans `.env.master`
|
||
2) Mettre à jour `ENV_EXAMPLE.md`
|
||
3) Rebuild/restart si nécessaire (front: rebuild; autres: recreate)
|
||
4) Vérifier via endpoints/container
|