Daniel Allaire
caee04385b
Some checks are pending
verifier / verifier (push) Waiting to run
Demande de l'exploitant : « l'underlay et son tenant doivent avoir chacun sa voute ». CE QUI ETAIT FAUX. Le jeton d'API du cluster et la cle d'API de la frontiere vivaient dans la voute de CHAQUE tenant. Patient 0 a du les recopier pour exister. Consequence : on ne pouvait plus revoquer l'acces d'un locataire sans le revoquer pour tous — la faute des neuf copies, appliquee aux secrets. CE QUI EST POSE : - `underlay.vault.yml`, chez l'hebergeur, a cote d'underlay.yml. Quatre secrets deplaces (jeton Proxmox, cle et secret d'API OPNsense), retires des deux voutes de tenants. - `proxmox_api.voute()` lit l'underlay APRES le tenant, donc l'hebergeur fait foi ; un site non encore migre continue de fonctionner sur son ancienne voute. - `appliquer_opnsense._voute()` n'a plus sa propre lecture : elle appelle celle du cluster. La reecrire aurait fait une dixieme copie le jour ou l'on refermait les neuf autres. - Le playbook de clonage charge la voute de l'underlay APRES celle du tenant, par la meme derivation que proxmox-hebergeur.yml : le symlink designe deja l'hebergeur. - `voute.py` sait que ces secrets ne sont plus attendus chez un tenant (P18). EPROUVE SUR LE REEL, apres retrait des cles chez les deux tenants : l'API du cluster repond, le devis de placement est conforme pour les deux ecosystemes, le devis de frontiere se genere (86 objets), le SDN est convergent. UNE PRECAUTION APPRISE EN CHEMIN : le premier essai a ecrit la voute EN CLAIR avant de la chiffrer, et le chiffrement a echoue — il a fallu detruire le fichier. La sequence est desormais l'inverse : chiffrer dans un dossier de travail, ne deposer que le resultat. 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