README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index). Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis. QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires. Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous- dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5.7 KiB
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) :
- Valeur explicite par hôte dans
serveurs.yml(coeurs/memoire/disque) — gagne toujours. - 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 |
repli aujourd'hui vide d'effet : tous les groupes de service ont leur rôle. Voir l'encadré plus bas. |
| 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) :
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
scripts/inventory_rules.py—deriver_ressources(groupes_service, racine_roles)lit les empreintes et calcule.scripts/instancier.py— pour chaque hôte, écritproxmox_coeurs,proxmox_memoire,proxmox_disque_tailledans l'inventaire généré (viasetdefault: un overrideserveurs.ymlprime).scripts/inventory_host.py—parametres-proxmoxémetSETOPS_COEURS/SETOPS_MEMOIRE/SETOPS_DISQUElus parmake creer-vm.Makefile(creer-vm→cloner-vm) relaie versproxmox_clone_coeurs/proxmox_clone_memoire.playbooks/proxmox/cloner_vm_debian.yml— passecores/memoryàproxmox_kvm(avecomitsi absent : aucune régression, on garde alors les specs du template).
Les empreintes : ne pas les recopier, les mesurer
Ce document a porté jusqu'au 2026-09-06 un tableau de quatorze empreintes recopiées à la main. Il y en a 32 aujourd'hui, et l'une des quatorze avait cessé d'être vraie. Recopier une valeur qui vit ailleurs, c'est s'engager à la suivre — cette page ne s'y engage plus :
# l'empreinte de chaque logiciel, telle qu'elle est déclarée
python3 - <<'EOF'
import yaml, pathlib
for f in sorted(pathlib.Path('roles').glob('*/meta/empreinte.yml')):
e = (yaml.safe_load(f.read_text()) or {}).get('setops_empreinte') or {}
print(f"{f.parts[1]:26} {e.get('coeurs')} coeur(s) {e.get('memoire_mo')} Mo {e.get('disque_go')} Go")
EOF
# ce que ça donne pour un hôte donné, une fois sommé et arrondi
make hote-afficher HOTE=obs-01
Ce qui mérite d'être écrit ici, c'est ce qui façonne le calcul et ne se lit pas dans un
rôle — le socle, les marges, les paliers, les bornes. Ils sont au §« Règles d'agrégation »
ci-dessus, et vivent en tête de scripts/inventory_rules.py.
Un repli devenu inutile.
EMPREINTES_SANS_ROLEcouvraitserveur_web_frontaletserveur_web_dorsaldu temps où ces groupes n'avaient pas de rôle. Ils en ont un depuis, avec leur propremeta/empreinte.yml— et comme la précédence est rôle > repli > défaut, ces deux entrées ne sont plus jamais lues. Elles disent d'ailleurs autre chose que les rôles (5 Go contre 10 pour le frontal) : c'est sans effet, mais c'est le genre d'écart qu'on croit lire comme une vérité.
Ajuster
- Une empreinte de logiciel : éditer
roles/<rôle>/meta/empreinte.yml. - Un hôte précis : poser
coeurs/memoire/disquesur le serveur dansserveurs.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é.