Daniel Allaire
716be304c5
Complète les 14 unités d'apprentissage au moule à 4 temps : Reverse-proxy, Courriel, Bases de données, Cache, Métriques & journaux, Supervision & impact, Virtualisation, Sécurité & durcissement, Infra as Code & idempotence, Liaisons (bindings, avec l'analogie NetScaler). Navigation complétée. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
69 lines
3 KiB
Markdown
69 lines
3 KiB
Markdown
# Virtualisation & clonage
|
|
|
|
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
|
|
|
|
---
|
|
|
|
## ① Le concept *(générique)*
|
|
|
|
La **virtualisation** fait tourner plusieurs **machines virtuelles (VM)** — chacune avec son OS —
|
|
sur un seul serveur physique (l'**hyperviseur**). Isolation, densité, souplesse.
|
|
|
|
**Image / golden template** : au lieu de réinstaller chaque VM, on prépare **une** image de
|
|
référence, propre et durcie, puis on la **clone**. Rapide et **reproductible**.
|
|
|
|
**cloud-init** : au premier démarrage d'un clone, il lui donne son **identité initiale** (nom d'hôte,
|
|
IP, clé SSH, agrandissement du disque). C'est *l'amorçage*, pas la configuration complète.
|
|
|
|
Idée-force : la VM devient **jetable/reconstructible**. Ce qui est précieux, c'est la **donnée**
|
|
(voir *Sauvegardes*), pas la machine.
|
|
|
|
---
|
|
|
|
## ② Comment Set-OPS le fait
|
|
|
|
- **Proxmox** = l'hyperviseur (cluster).
|
|
- Un **golden template** (`basiqueChezlepro`) : Debian minimal, durci, avec le compte technique
|
|
`ansible`, qemu-guest-agent, cloud-init… — préparé **une fois**.
|
|
- Chaque nœud = un **clone** du template. `cloud-init` pose l'identité (hostname, IP dérivée de la
|
|
nomenclature, clé SSH).
|
|
- **Puis** Set-OPS/Ansible fait la **vraie** configuration (les rôles).
|
|
|
|
Séparation nette, à retenir :
|
|
```
|
|
Proxmox + cloud-init ──> identité initiale de la VM
|
|
Set-OPS + Ansible ──> configuration réelle du serveur
|
|
```
|
|
C'est *pour ça* que l'infra est reconstructible : cloner + reconfigurer = quelques minutes.
|
|
|
|
---
|
|
|
|
## ③ Pourquoi c'est transférable
|
|
|
|
| Set-OPS | Équivalents ailleurs |
|
|
|---|---|
|
|
| Proxmox (KVM) | VMware · Hyper-V · KVM/libvirt · nuage (EC2, GCE…) |
|
|
| golden template | AMI, image cloud, **Packer** |
|
|
| cloud-init | **standard** de toutes les images cloud |
|
|
|
|
Tu as appris **VM/hyperviseur, image de référence, cloud-init, l'infra jetable** — pas « Proxmox ».
|
|
|
|
---
|
|
|
|
## ④ À toi de jouer
|
|
|
|
1. **Regarde un clone.** Dans la GUI (`make inventaire-ui`), un serveur *actif* a été **cloné** du
|
|
template (bouton « 🖥 Créer la VM »). Son VMID/IP sont **dérivés** de la nomenclature.
|
|
2. **Vois l'identité cloud-init.** Sur un nœud : `cloud-init query hostname`, `hostname -f`, et
|
|
l'agrandissement du disque racine (`df -h /`).
|
|
3. **Sépare les deux couches.** cloud-init a posé *l'identité* ; tout le reste (paquets, services,
|
|
durcissement) vient d'**Ansible**. Le template, lui, ne contient **aucune** donnée de clone.
|
|
4. **Casse & répare (mentalement + lab).** Supprime un nœud non critique et **reclone-le** depuis le
|
|
template, puis redéploie : il revient à l'identique. Tu *sens* que la machine est **reconstructible**.
|
|
|
|
---
|
|
|
|
## Pour aller plus loin *(dépôt)*
|
|
- Playbooks Proxmox : `playbooks/proxmox/` ; rôle `cloud_init` ; préparation du modèle : `playbooks/modeles_vm/`.
|
|
- Golden template = actif central (jamais jetable, cloné pour chaque VM).
|
|
- Ce qui est précieux = la **donnée** : unité **Sauvegardes**.
|