133 lines
5.7 KiB
Markdown
133 lines
5.7 KiB
Markdown
# Enclume
|
|
|
|
Site public de génération de configuration CLAPI pour Centreon. On y construit ses commandes
|
|
de contrôle, ses modèles de service et ses modèles d'hôte — de zéro ou en partant d'un pack
|
|
du catalogue — et on repart avec les fichiers à jouer sur son central.
|
|
|
|
Projet indépendant, sans lien avec Centreon SAS.
|
|
|
|
## Ce que fait le site
|
|
|
|
- **Éditeur libre** : commandes, modèles de service, modèles d'hôte, hôtes. Héritage,
|
|
duplication, rattachement des services aux modèles d'hôte.
|
|
- **Catalogue de départ** : 52 packs, 224 sondes, importables puis modifiables.
|
|
- **Validation** avant génération : noms en double, références manquantes, point-virgule
|
|
interdit, services rattachés à aucun modèle d'hôte, mots de passe en clair.
|
|
- **Quatre fichiers** : `deploy.sh` (avec `--dry-run`), `deploy.clapi` (import CLAPI),
|
|
et les deux `rollback` correspondants.
|
|
- **Version de Centreon** au niveau du projet : les macros sortent en 3 ou 5 champs selon
|
|
la cible.
|
|
|
|
- **Prérequis d'installation** : un pack peut déclarer ses paquets et ses droits, générés
|
|
dans un `prerequis.sh` distinct du CLAPI.
|
|
- **Notifications par périmètre** : calendriers, destinataires, états déclencheurs et
|
|
message personnalisé par domaine applicatif ou système — voir
|
|
[docs/NOTIFICATIONS.md](docs/NOTIFICATIONS.md).
|
|
- **Partage par lien**, projets enregistrés et **soumission de packs** quand l'instance est
|
|
configurée pour — voir [docs/COMPTES-ET-MODERATION.md](docs/COMPTES-ET-MODERATION.md).
|
|
|
|
## Ce que le serveur ne fait pas
|
|
|
|
Il n'exécute rien. Ni CLAPI, ni prérequis, ni contribution : il écrit des fichiers que
|
|
l'utilisateur relit avant de les jouer.
|
|
|
|
Sans configuration, le projet vit dans le navigateur (`localStorage`), s'exporte en JSON et
|
|
se réimporte ; le serveur valide et génère sans rien conserver. Avec une base, le partage et
|
|
l'enregistrement deviennent possibles — et les macros marquées « mot de passe » sont vidées
|
|
avant toute écriture, quelle qu'elle soit.
|
|
|
|
## Architecture
|
|
|
|
```
|
|
Cloudflare Tunnel → Traefik ─┬→ web (image maison, sans état)
|
|
│
|
|
volume catalogue ┴← catalog-sync (git → volume, puis /recharger)
|
|
db (postgres, à partir du chantier 2)
|
|
```
|
|
|
|
Chaque évolution produit une image versionnée. Le déploiement et le retour arrière se font
|
|
en changeant une ligne dans `.env` : voir [docs/EXPLOITATION.md](docs/EXPLOITATION.md).
|
|
|
|
## Développement
|
|
|
|
```bash
|
|
python3 -m venv .venv && . .venv/bin/activate
|
|
pip install -r requirements.txt
|
|
ENCLUME_DEBUG=1 python3 run.py # http://127.0.0.1:8080
|
|
python3 -m pytest -q
|
|
```
|
|
|
|
Ou en conteneur, avec le code monté en direct :
|
|
|
|
```bash
|
|
docker compose -f compose.dev.yaml up --build
|
|
```
|
|
|
|
## Ligne de commande et API
|
|
|
|
Le même moteur sert au site, à la CLI et à la CI :
|
|
|
|
```bash
|
|
python3 -m enclume.cli --list
|
|
python3 -m enclume.cli --pack os-linux-snmp --prefix ACME- --out ./sortie --strict
|
|
python3 -m enclume.cli --projet mon-projet.json --out ./sortie
|
|
```
|
|
|
|
| Route | Usage |
|
|
|---|---|
|
|
| `GET /api/packs` | catalogue |
|
|
| `GET /api/packs/<id>/projet` | un pack converti en objets de projet |
|
|
| `POST /api/packs/<id>/fusionner` | ajoute un pack au projet en cours |
|
|
| `POST /api/valider` | validation seule |
|
|
| `POST /api/generer` | validation et génération des quatre fichiers |
|
|
| `POST /telecharger` | archive zip |
|
|
| `POST /api/partages` `GET /api/partages/<id>` | partage par lien |
|
|
| `GET POST DELETE /api/projets` | projets enregistrés (connexion requise) |
|
|
| `POST /api/soumissions/verifier` `POST /api/soumissions` | contribution d'un pack |
|
|
| `/api/moderation/...` | file de modération (groupe d'administration) |
|
|
| `GET /health` (alias `/sante`) | version, commit, état du catalogue, fonctions actives |
|
|
| `GET /` | page d'accueil publique |
|
|
| `GET /editeur` | l'éditeur |
|
|
| `GET /mentions` | mentions légales et données personnelles |
|
|
| `POST /recharger` | relecture du catalogue (appelé par `catalog-sync`) |
|
|
|
|
## Ajouter un pack au catalogue
|
|
|
|
Un pack est un fichier YAML déposé dans `catalog/<catégorie>/`. Le format et un exemple
|
|
commenté sont dans `catalog/exemple-pack.yml.example`. Aucun code à modifier, aucune image à
|
|
reconstruire : `catalog-sync` le prend en charge au prochain cycle.
|
|
|
|
## Contribuer et livrer
|
|
|
|
Les conventions de nommage et la revue à passer avant chaque version sont dans
|
|
[docs/CONVENTIONS.md](docs/CONVENTIONS.md). En résumé : `ruff check`, la suite de tests, et
|
|
une installation en environnement vierge — dans cet ordre, avant tout tag.
|
|
|
|
## Structure
|
|
|
|
```
|
|
run.py point d'entrée de développement
|
|
enclume/model.py modèle de projet, validation, retrait des secrets
|
|
enclume/generator.py projet → opérations CLAPI → quatre fichiers
|
|
enclume/catalog.py lecture du catalogue YAML
|
|
enclume/packs.py pack du catalogue → objets de projet
|
|
enclume/webapp.py routes Flask
|
|
enclume/cli.py usage en ligne de commande et en CI
|
|
enclume/static/editeur.js éditeur, sans dépendance ni étape de build
|
|
tests/ garde-fous sur la génération
|
|
Dockerfile image de l'application
|
|
Dockerfile.catalog-sync image du synchroniseur
|
|
compose.yaml production, derrière Traefik
|
|
compose.dev.yaml développement local
|
|
.gitea/workflows/build.yaml construction, tests, publication sur Harbor
|
|
```
|
|
|
|
## Chantiers
|
|
|
|
1. Éditeur libre — **fait**
|
|
2. Empaquetage Docker, CI, exploitation — **fait**
|
|
3. Partage par lien et projets enregistrés — **fait**
|
|
4. Connexion optionnelle via Authentik — **fait**
|
|
5. Soumission de packs et modération, demandes de fusion Gitea — **fait**
|
|
6. Habillage public : page d'accueil, mentions, documentation d'usage
|