111 lines
4.9 KiB
Markdown
111 lines
4.9 KiB
Markdown
<!-- file: config/README.md -->
|
|
<!-- version: 21 -->
|
|
|
|
# Configuration locale
|
|
|
|
Ce dossier contient les compositions propres aux binaires, les documents de configuration partagés, leurs exemples et les schémas JSON actifs.
|
|
|
|
## Principe de composition
|
|
|
|
Un binaire ne possède pas une copie complète de toutes les configurations partagées. Il charge un fichier de composition `<binary>.default.config.json` qui référence les documents spécialisés et sélectionne explicitement un profil dans chacun.
|
|
|
|
Le desktop utilise par défaut :
|
|
|
|
```text
|
|
config/kb-app-demo-desktop.default.config.json
|
|
```
|
|
|
|
Le CLI des scénarios possède également une composition explicite :
|
|
|
|
```text
|
|
config/ks-pipeline-demo-scenarios.default.config.json
|
|
```
|
|
|
|
La composition desktop peut être remplacée par `KB_APP_DEMO_DESKTOP_CONFIG_PATH`. Les tests/scénarios Devnet opt-in peuvent remplacer leur composition avec `KS_DEVNET_CONFIG_PATH`.
|
|
|
|
## Documents partagés actuels
|
|
|
|
```text
|
|
config/
|
|
├── kb-app-demo-desktop.default.config.json
|
|
├── ks-pipeline-demo-scenarios.default.config.json
|
|
├── logging.config.json
|
|
├── transport.config.json
|
|
├── listeners.config.json
|
|
├── example.kb-app-demo-desktop.default.config.json
|
|
├── example.logging.config.json
|
|
├── example.transport.config.json
|
|
├── example.listeners.config.json
|
|
└── schemas/
|
|
├── composition.config.schema.json
|
|
├── logging.config.schema.json
|
|
├── transport.config.schema.json
|
|
├── listeners.config.schema.json
|
|
└── resolved.app.config.schema.json
|
|
```
|
|
|
|
`resolved.app.config.schema.json` décrit uniquement le contrat runtime `AppConfig/ProfileConfig` reconstruit par `ks-config`. Il ne correspond pas à un fichier runtime chargé directement.
|
|
|
|
## Sélection des profils
|
|
|
|
Les documents partagés conservent un `active_profile` pour les consommateurs autonomes. Une composition binaire peut cependant sélectionner un autre profil explicitement :
|
|
|
|
```text
|
|
composition profile mainnet_research
|
|
logging_profile = mainnet_research
|
|
transport_profile = mainnet_research
|
|
listeners_profile = mainnet_research
|
|
```
|
|
|
|
Lorsqu'une composition est utilisée, sa sélection explicite prime pour le binaire. Le même `transport.config.json` ou `listeners.config.json` peut donc être réutilisé par plusieurs binaires avec des combinaisons différentes.
|
|
|
|
## Transport
|
|
|
|
`transport.config.json` possède les endpoints HTTP et WebSocket, leurs providers, clusters, timeouts, capacités, rôles, limites et politique de reconnexion propre aux endpoints.
|
|
|
|
`ks-onchain-transport` peut consommer directement un `TransportProfileConfig`. Un futur worker n'a donc pas besoin de dépendre d'un `ProfileConfig` applicatif complet pour construire ses pools réseau.
|
|
|
|
## Listeners
|
|
|
|
`listeners.config.json` possède les ensembles de listeners Solana :
|
|
|
|
- `logsSubscribe` par mention de programme ;
|
|
- `programSubscribe` ;
|
|
- `accountSubscribe` ;
|
|
- commitment et rôles d'endpoint associés.
|
|
|
|
La séparation prépare les futurs workers de capture, qui pourront associer un profil transport et un profil listeners sans recopier les définitions dans leur propre configuration.
|
|
|
|
## Logging
|
|
|
|
`logging.config.json` reste possédé par `ks-logging`. Une composition sélectionne le profil logging souhaité. `KS_LOGGING_CONFIG_PATH` reste un override direct du chemin logging pour l'exploitation ; sans override, le chemin déclaré par la composition est utilisé.
|
|
|
|
## Configuration encore transitoire dans la composition
|
|
|
|
Après `pre.006`, les sections suivantes restent temporairement dans les profils de composition :
|
|
|
|
- `database` et `data` ;
|
|
- `wallet` ;
|
|
- `execution` ;
|
|
- `demo`.
|
|
|
|
Elles seront séparées dans la prerelease suivante. En particulier, `demo` est propre au desktop et ne doit pas rester durablement dans un contrat généraliste `ks-config`.
|
|
|
|
## Variables d'environnement
|
|
|
|
Les composants `ks-*` utilisent `KS_SECRET_*`, `KS_PUBLIC_*` ou `KS_*`. Les besoins réellement spécifiques à une application `kb-*` utilisent `KB_SECRET_*`, `KB_PUBLIC_*` ou `KB_*`.
|
|
|
|
Les secrets ne sont jamais écrits en clair dans le dépôt. La propagation de sensibilité et les DTO publics sûrs sont traités après la fin du découpage des fichiers de configuration.
|
|
|
|
## Exemples et schémas
|
|
|
|
Les exemples sous `config/` sont des références conformes et ne sont pas chargés automatiquement. Tous les schémas actifs résident exclusivement sous `config/schemas/`.
|
|
|
|
Les fichiers historiques `app.config.json`, `example.app.config.json`, `schemas/app.config.schema.json`, `example.config.json` et `schema.config.json` sont obsolètes et ne doivent pas coexister avec cette architecture.
|
|
|
|
## Logging de développement
|
|
|
|
Le fichier `logging.config.json` conserve les routes globales ainsi que trois fichiers dédiés par crate opérationnelle utilisant `tracing` : `debug.log`, `info.log` et `error.jsonl`.
|
|
|
|
Les logs ne doivent contenir ni secret, ni DSN non masqué, ni keypair, ni payload de configuration résolue complet.
|