Daniel Allaire
3b16b8845d
Les deux reconstructions de la semaine rebatissaient Chezlepro sur son propre materiel : une preuve de reproductibilite, pas de portabilite. La vraie epreuve est un second tenant — Technolibre, index 11, plan distinct, voute separee, meme cluster. 1. LE CLONAGE RESOLVAIT PAR NOM. proxmox_kvm cherche une VM portant le `name` demande ; s'il en trouve une il rend `ok` et ne clone RIEN — aucune tache cote cluster. Or les noms courts sont VOLONTAIREMENT identiques d'un tenant a l'autre. `backup-01` de Technolibre tombait sur celui de Chezlepro. Mesure : id-ldap-01 et sup-01 (noms absents chez Chezlepro) passaient du premier coup, backup-01 echouait toujours. Le clonage cible desormais par VMID, via l'API. Deux defauts de ce correctif, trouves en le mesurant : le corps assemble en Jinja avec `>-` rendait une CHAINE et perdait le `pool` (VM nee hors de son pool, sans un mot) ; et l'application du gabarit de calcul expirait a 5 s, laissant la VM aux valeurs du gabarit — 2 coeurs/2 Go au lieu du plan, en silence. Corps en mapping YAML avec omit ; six tentatives espacees. Et `no_log` a masque la cause au moment ou elle servait. Les deux attentes disent maintenant ce qu'elles ont constate. 2. LE GUI DETRUISAIT DES INTRANTS. Dans ecrire_intrants, `identite` etait la seule branche sur quatre a ecrire par-dessus le disque au lieu de fusionner. Un enregistrement a supprime dns_amorcage et amorcage_acces_courriel. Le meme geste sur Chezlepro aurait mange les memes cles. 3. LE VERROU DE `raser` N'ETAIT PROUVE QUE POUR UN TENANT. Le faux cluster codait en dur les VMID de Chezlepro ; monte ailleurs, le test rendait 0 au lieu de 2. Il fabrique desormais la collision sur le plan courant. Verifie : prouver.py 34 OK sur Technolibre, test_raser vert sur les deux tenants, ansible-lint production sur le playbook de clonage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| cloner_vm_debian.yml | ||
| README.md | ||
| supprimer_vm_debian.yml | ||
Playbooks Proxmox
Ces playbooks pilotent Proxmox par API depuis le poste Ansible.
Les valeurs Cloud-Init communes déjà définies sur le modèle Proxmox sont héritées par les clones. Set-OPS ne les redemande pas.
Prérequis du poste Ansible
Le clonage Proxmox utilise les modules community.general.proxmox_*.
Le poste Ansible doit donc avoir :
- la collection Ansible
community.general; - la bibliothèque Python
proxmoxerdisponible dans le Python utilisé par Ansible.
Sur Debian, installer généralement :
sudo apt install python3-proxmoxer
Vérification locale :
python3 -c 'import proxmoxer'
Les paramètres non sensibles sont dans :
instance/inventories/production/group_vars/proxmox.yml
Assistant terminal (écrit proxmox.yml et place le token dans la voûte unifiée) :
make config
Les secrets d'API vivent dans la voûte unifiée de l'instance — le token Proxmox aux
côtés des autres vault_*, un seul fichier chiffré, non versionné :
instance/inventories/production/group_vars/all/vault.yml
make config la sème depuis le gabarit et y place le token. Le clonage lit cette voûte
unifiée (une proxmox.vault.yml séparée reste acceptée en compatibilité). Détail des
paramètres : docs/config-proxmox.md.
Créer un clone Debian depuis le modèle :
make creer-vm \
HOTE=web-frontal-01 \
VMID=95301 \
VLAN=15 \
ADRESSE_IP=10.0.15.31 \
PASSERELLE=10.0.15.1 \
GROUPES="serveur_debian serveur_durci"
VLAN doit être saisi à chaque création de VM pour éviter de réutiliser par erreur un réseau d'un autre clone.
Le disque du clone hérite de la taille du modèle. Pour l'agrandir à la création, fournir explicitement une taille supérieure à celle du modèle :
make creer-vm HOTE=web-frontal-01 VMID=95301 VLAN=15 ADRESSE_IP=10.0.15.31 PASSERELLE=10.0.15.1 TAILLE_DISQUE=64G GROUPES="serveur_debian serveur_durci"
Proxmox ne permet pas de réduire un disque existant.
creer-vm clone la VM, applique les paramètres Cloud-Init et ajoute l'hôte à l'inventaire. La conformité Ansible reste séparée :
make deployer HOTE=web-frontal-01