Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
103 lines
4.7 KiB
Markdown
103 lines
4.7 KiB
Markdown
# Dimensionnement dérivé des ressources VM
|
||
|
||
> **Pour qui :** le **mainteneur** — comment les ressources d'une VM se dérivent des logiciels qu'elle porte.
|
||
|
||
Ce document décrit comment Set-OPS **estime les ressources d'une VM** (cœurs, RAM,
|
||
disque) à partir des **propriétés des logiciels** qu'elle héberge et du **socle SE**,
|
||
plutôt que de laisser chaque clone hériter aveuglément des specs du golden template.
|
||
|
||
> Décision actée le 2026-06-25 : extension assumée de la *modélisation* du plan de
|
||
> contrôle (cf. `positionnement.md`). C'est le prolongement naturel de la dérivation
|
||
> réseau (`nomenclature.yml`) — du dimensionnement, pas une fonction de type NetBox.
|
||
|
||
## Principe
|
||
|
||
```
|
||
ressources(VM) = socle_SE + Σ empreinte(logiciel hébergé) → marge → arrondi
|
||
```
|
||
|
||
Précédence (du plus fort au plus faible) :
|
||
1. **Valeur explicite par hôte** dans `serveurs.yml` (`coeurs` / `memoire` / `disque`) — gagne toujours.
|
||
2. **Valeur dérivée** (socle + empreintes + marge + arrondi) sinon.
|
||
|
||
Comme Ansible/Proxmox sont idempotents, ajuster une empreinte puis régénérer ne fait
|
||
que recalculer la cible ; aucune dérive silencieuse.
|
||
|
||
## Où vit chaque donnée
|
||
|
||
| Donnée | Emplacement | Remarque |
|
||
| --- | --- | --- |
|
||
| Empreinte d'un logiciel | `roles/<groupe>/meta/empreinte.yml` | Propriété du logiciel, voyage avec le rôle. Fichier *pur données* (parsable sans Jinja). |
|
||
| Groupes sans rôle dédié | `EMPREINTES_SANS_ROLE` dans `scripts/inventory_rules.py` | p. ex. `serveur_web_frontal`, `serveur_web_dorsal`. |
|
||
| Repli ultime | `EMPREINTE_DEFAUT` | groupe inconnu : empreinte minimale. |
|
||
| Socle SE | `SOCLE_SE` dans `inventory_rules.py` | coût de base Debian durci. |
|
||
| Override par hôte | `serveurs.yml` (`coeurs`/`memoire`/`disque`) | déjà supporté par le générateur (`PLACEMENT`). |
|
||
| Politique (marges, paliers, plafonds) | constantes en tête de `inventory_rules.py` | |
|
||
|
||
Format d'une empreinte (`roles/<rôle>/meta/empreinte.yml`) :
|
||
```yaml
|
||
setops_empreinte: { coeurs: 2, memoire_mo: 2048, disque_go: 20 }
|
||
```
|
||
|
||
## Règles d'agrégation (valeurs en vigueur)
|
||
|
||
- **Socle SE** : 1 cœur / 512 Mo / 8 Go.
|
||
- **RAM** : `(socle + Σ rôles) × 1.20`, arrondie au palier **512 Mo**, **min 1024 Mo**.
|
||
- **Disque** : `(socle + Σ rôles) × 1.25`, arrondi au palier **5 Go**, **min 12 Go**,
|
||
émis sous la forme `"<n>G"`.
|
||
- **Cœurs** : `max(socle, Σ rôles)`, entier, **min 1**, **plafond 8** (CPU *burstable* :
|
||
ni additif strict, ni marge).
|
||
|
||
Seuls les **groupes de service** de l'hôte (issus de `applications.yml`) entrent dans
|
||
la somme. Le socle (`serveur_debian`/`serveur_durci`) et les groupes d'état sont exclus.
|
||
|
||
## Chaîne technique
|
||
|
||
1. `scripts/inventory_rules.py` — `deriver_ressources(groupes_service, racine_roles)`
|
||
lit les empreintes et calcule.
|
||
2. `scripts/instancier.py` — pour chaque hôte, écrit `proxmox_coeurs`,
|
||
`proxmox_memoire`, `proxmox_disque_taille` dans l'inventaire généré
|
||
(via `setdefault` : un override `serveurs.yml` prime).
|
||
3. `scripts/inventory_host.py` — `parametres-proxmox` émet `SETOPS_COEURS` /
|
||
`SETOPS_MEMOIRE` / `SETOPS_DISQUE` lus par `make creer-vm`.
|
||
4. `Makefile` (`creer-vm` → `cloner-vm`) relaie vers `proxmox_clone_coeurs` /
|
||
`proxmox_clone_memoire`.
|
||
5. `playbooks/proxmox/cloner_vm_debian.yml` — passe `cores`/`memory` à `proxmox_kvm`
|
||
(avec `omit` si absent : aucune régression, on garde alors les specs du template).
|
||
|
||
## Empreintes actuelles
|
||
|
||
| Rôle | cœurs | RAM (Mo) | disque (Go) |
|
||
| --- | --- | --- | --- |
|
||
| serveur_step_ca | 1 | 256 | 2 |
|
||
| serveur_powerdns | 1 | 512 | 2 |
|
||
| serveur_nginx | 1 | 512 | 3 |
|
||
| serveur_openldap | 1 | 512 | 3 |
|
||
| serveur_keycloak | 2 | 1536 | 5 |
|
||
| serveur_postgresql | 2 | 2048 | 20 |
|
||
| serveur_redis | 1 | 512 | 2 |
|
||
| serveur_forgejo | 1 | 1024 | 20 |
|
||
| serveur_prometheus | 1 | 1024 | 20 |
|
||
| serveur_loki | 1 | 1024 | 20 |
|
||
| serveur_grafana | 1 | 512 | 2 |
|
||
| serveur_icinga | 2 | 1024 | 10 |
|
||
| serveur_web_frontal (repli) | 1 | 512 | 5 |
|
||
| serveur_web_dorsal (repli) | 1 | 1024 | 10 |
|
||
|
||
## Ajuster
|
||
|
||
- **Une empreinte de logiciel** : éditer `roles/<rôle>/meta/empreinte.yml`.
|
||
- **Un hôte précis** : poser `coeurs`/`memoire`/`disque` sur le serveur dans
|
||
`serveurs.yml` (l'override prime sur la dérivation).
|
||
- **La politique** (marges, paliers, socle, plafond) : constantes en tête de
|
||
`inventory_rules.py`.
|
||
|
||
Puis : `make instancier` (voir le diff), `make instancier-appliquer` (FORCE=1 si
|
||
changement intentionnel).
|
||
|
||
## Limite connue
|
||
|
||
Les ressources s'appliquent **à la création de la VM** (clonage). Modifier une
|
||
empreinte n'**ajuste pas** automatiquement une VM déjà existante : il faut un
|
||
re-clonage ou un redimensionnement Proxmox manuel. Le **plan**, lui, reste la source
|
||
de vérité et se régénère à volonté.
|