Aller au contenu

Semaine 4 — Templates et cloud-init : arrêter d'installer des systèmes d'exploitation

0. Plan de la séance

Théorie - Ce document : fabriquer une VM modèle et la personnaliser au démarrage. - Sauvegarder une VM et la remettre en place : mettre le travail de la séance à l'abri, et le remonter.

Pratique - Exercice 1 — Configurer le switch Cisco de l'équipe - Exercice 2 — Fabriquer un template Debian cloud-init - Exercice 3 — Déployer le réseau de l'entreprise - Exercice 4 — Sauvegarder l'infrastructure de Cyclo-Nord

Objectifs d'apprentissage

  • Expliquer pourquoi on ne réinstalle pas un système d'exploitation à chaque nouvelle VM.
  • Distinguer une image d'installation (ISO) d'une image cloud.
  • Choisir entre un clone lié et un clone complet.
  • Décrire ce que cloud-init fait au premier démarrage, et d'où il tire ses informations.
  • Identifier les réglages que Proxmox transmet à cloud-init et ceux qu'il ne transmet pas.

1. Le problème : la vingtième installation

À la semaine 2, vous avez installé Windows Server à partir d'un ISO. Compter le temps : télécharger l'image, créer la VM, suivre l'assistant, choisir la langue, partitionner, attendre, redémarrer, configurer le réseau, installer les mises à jour. Quarante-cinq minutes, pour une machine.

Un hébergeur qui crée trois cents VM par jour ne peut pas faire ça. Et vous non plus, quand votre équipe a besoin de quatre VM identiques dans l'heure qui vient.

La solution tient en deux morceaux. D'abord un template : une VM installée une seule fois, figée, et recopiée à volonté. Ensuite cloud-init : un mécanisme qui personnalise chaque copie à son premier démarrage, pour qu'elle ne soit pas le clone exact de sa voisine.

2. Le template Proxmox

Un template, c'est une VM ordinaire à laquelle on a retiré le droit de démarrer. Elle sert uniquement de modèle.

La transformation est définitive : qm template 9000 marque la VM comme modèle, et il n'existe pas de bouton pour revenir en arrière. Son disque devient en lecture seule, ce qui est justement la garantie que toutes les copies partent du même état.

Important

Une VM transformée en template ne redémarre plus jamais. Si le modèle doit évoluer, on clone le template, on modifie le clone, et on en refait un template.

Par convention, on range les templates dans une plage d'ID à part, souvent à partir de 9000. Rien ne l'impose, mais la convention évite de chercher.

3. Clone lié et clone complet

Au moment de cloner, Proxmox demande de choisir entre deux modes. La différence porte sur le disque.

Un clone complet (full clone) recopie tout le disque du template. La nouvelle VM est indépendante : elle occupe sa propre place sur le stockage, et le template peut disparaître sans conséquence.

Un clone lié (linked clone) ne recopie rien. Il crée un disque vide qui ne contient que les différences par rapport à celui du template. Tant que la VM ne modifie rien, son disque pèse quelques kilo-octets.

Clone lié Clone complet
Temps de création immédiat le temps de copier le disque
Espace occupé au départ presque rien la taille complète
Dépendance au template le template ne peut plus être supprimé aucune
Migration vers un autre nœud impossible tant que le lien existe libre
Cas d'usage typique postes de laboratoire, VM jetables serveurs de production

Le clone lié n'est pas disponible sur tous les types de stockage : il demande un stockage capable de gérer des instantanés (snapshots), comme local-lvm ou ZFS. Sur un stockage en fichiers .raw, Proxmox grise l'option.

4. L'image cloud, ce n'est pas un ISO

Un ISO d'installation contient un programme d'installation. Vous le démarrez, il vous pose des questions, et il écrit un système sur le disque.

Une image cloud contient le système déjà installé. C'est un fichier .qcow2 qu'on branche directement comme disque de VM : il n'y a rien à installer, la machine démarre dessus en quelques secondes.

Ces images sont construites pour les hébergeurs, ce qui explique leurs particularités :

  • Aucun mot de passe root, aucun compte utilisateur. Sans cloud-init, l'image démarre et personne ne peut s'y connecter.
  • Aucune interface graphique, très peu de paquets.
  • Un disque volontairement minuscule, souvent 2 ou 3 Go, prévu pour être agrandi.
  • cloud-init installé et activé.

Debian publie les siennes sur cloud.debian.org. La variante genericcloud est celle qui convient à Proxmox : elle contient les pilotes VirtIO et rien de plus.

Note

Le disque de l'image fait 3 Go, mais le système de fichiers s'agrandit de lui-même au premier démarrage pour occuper toute la place disponible. Si vous portez le disque à 20 Go dans Proxmox avant de démarrer, la VM aura bien 20 Go utilisables.

5. Ce que fait cloud-init

cloud-init est un service qui démarre très tôt, avant le réseau et avant les services ordinaires. Son travail : aller chercher une configuration à l'extérieur de la machine, et l'appliquer.

Il traite trois jeux de données :

Jeu de données Contenu
meta-data l'identité de l'instance : son nom d'hôte, son identifiant unique
network-config les adresses IP, les passerelles, les serveurs DNS
user-data tout le reste : comptes, clés SSH, paquets à installer, commandes à lancer

Une fois le travail terminé, cloud-init écrit un témoin dans /var/lib/cloud/. Au redémarrage suivant, il voit ce témoin et ne recommence pas. La personnalisation ne se produit qu'une fois, au tout premier démarrage de la copie.

C'est ce qui rend le mécanisme utilisable : vous pouvez changer le mot de passe à la main après coup, il ne sera pas réécrit au prochain boot.

6. D'où viennent ces données : le lecteur de CD

Reste une question : comment une VM qui vient de naître trouve-t-elle sa configuration ?

Chez un hébergeur comme AWS, cloud-init interroge un serveur web sur une adresse spéciale, 169.254.169.254. C'est ce qu'on appelle une source de données (datasource).

Proxmox utilise une autre source de données, beaucoup plus simple : NoCloud. Il fabrique une minuscule image de CD-ROM contenant les trois fichiers, et l'insère dans le lecteur virtuel de la VM. Au démarrage, cloud-init trouve le disque, lit les fichiers, applique la configuration.

C'est pour cette raison que l'ajout d'un CloudInit Drive est obligatoire dans Proxmox. Sans ce lecteur, la VM démarre sans configuration : pas de compte, pas d'adresse IP, pas de connexion possible.

flowchart LR
    P["Champs remplis<br/>dans Proxmox"] --> ISO["CD-ROM généré<br/>(NoCloud)"]
    ISO --> CI["cloud-init<br/>dans la VM"]
    CI --> R["Compte, réseau,<br/>nom d'hôte"]

Proxmox regénère ce CD-ROM à chaque fois que vous modifiez un champ de l'onglet Cloud-Init. Mais comme cloud-init ne s'exécute qu'au premier démarrage, modifier un champ sur une VM déjà démarrée ne change rien tant qu'elle n'est pas remise à zéro.

7. Les champs de l'onglet Cloud-Init

Proxmox expose une petite partie des possibilités de cloud-init, celle qui couvre 90 % des besoins.

Champ Proxmox Ce qu'il produit
User le compte créé dans la VM, avec les droits sudo
Password son mot de passe
SSH public key la clé publique déposée dans ~/.ssh/authorized_keys
DNS domain / DNS servers le contenu de /etc/resolv.conf
IP Config (net0, net1...) l'adressage de chaque carte, statique ou DHCP
Upgrade packages un apt upgrade au premier démarrage

Un point à retenir : il y a un champ IP Config par carte réseau. Une VM à quatre cartes a ipconfig0 à ipconfig3, et l'ordre suit celui des cartes net0 à net3. Vous utiliserez cette correspondance à l'exercice 3 pour construire un routeur à quatre pattes sans jamais ouvrir sa console.

8. Aller plus loin que les champs : les snippets

Les champs de l'interface ne savent pas installer un paquet ni écrire un fichier. Pour ça, il faut fournir soi-même du user-data, sous forme d'un fichier YAML déposé sur le nœud : c'est ce que Proxmox appelle un snippet.

YAML
#cloud-config
packages:
  - qemu-guest-agent
runcmd:
  - systemctl enable --now qemu-guest-agent

Le fichier se range dans le stockage local, sous-dossier snippets, et se rattache à la VM avec l'option --cicustom. Deux formes existent :

  • user= remplace le user-data généré par Proxmox. Les champs User et Password de l'interface ne sont plus pris en compte.
  • vendor= s'ajoute au user-data généré. Les champs de l'interface continuent de fonctionner.

Dans ce cours, nous utilisons la forme vendor=, qui permet de garder l'interface web pour les comptes et les adresses, et le fichier pour le reste.

Astuce

La première ligne #cloud-config n'est pas un commentaire. C'est elle qui indique à cloud-init le format du fichier. Sans elle, le fichier est ignoré en silence.

9. Ce que cloud-init ne fait pas

cloud-init s'exécute une fois, au premier démarrage, et s'arrête là. Ce n'est pas un outil de gestion de configuration.

Si vous devez modifier la configuration de trente machines déjà en service, cloud-init ne vous sert à rien : il a déjà fini son travail sur chacune d'elles. C'est le rôle d'outils comme Ansible, Puppet ou Salt, qui repassent sur les machines aussi souvent qu'on le veut.

La règle pratique : cloud-init amène la machine à l'état où on peut s'y connecter. Tout le reste appartient à un autre outil.

Pièges fréquents

  • Oublier le CloudInit Drive. La VM démarre, le disque fonctionne, mais aucun compte n'existe. La console affiche une invite de connexion à laquelle rien ne répond.
  • Modifier les champs Cloud-Init après le premier démarrage. Le CD-ROM est bien regénéré, mais cloud-init ne le relit pas. Il faut détruire la VM et recloner, ou remettre cloud-init à zéro à la main.
  • Utiliser user= au lieu de vendor=. Le snippet écrase les comptes de l'interface web, et plus personne ne peut se connecter.
  • Vouloir se connecter en root par SSH. Les images cloud créent un compte ordinaire avec sudo. Le compte root n'a pas de mot de passe et refuse la connexion.
  • Démarrer le template « juste pour vérifier ». C'est impossible, et c'est voulu.

Vérification des acquis

Question 1

Vous clonez un template en mode lié, puis vous essayez de supprimer le template. Que se passe-t-il ?

  • a) La suppression réussit, les clones continuent de fonctionner sur leur propre disque.
  • b) Proxmox refuse la suppression tant qu'un clone lié existe.
  • c) La suppression réussit et les clones cessent de démarrer.
Voir la réponse **b) Proxmox refuse la suppression tant qu'un clone lié existe.** Le disque du clone lié ne contient que les différences avec celui du template. Il a donc besoin du disque d'origine pour toutes les données qu'il n'a pas modifiées, et Proxmox protège ce lien. Le choix c) décrit ce qui arriverait si la protection n'existait pas, et c'est exactement pour éviter ce scénario qu'elle existe. C'est aussi la raison pour laquelle un clone lié ne peut pas migrer seul vers un autre nœud.

Question 2

Une VM clonée démarre, mais la console reste bloquée sur une invite de connexion où aucun mot de passe ne fonctionne. Quelle est la cause la plus probable ?

  • a) Le mot de passe cloud-init contient un caractère spécial mal interprété.
  • b) Le CloudInit Drive est absent de la configuration de la VM.
  • c) L'image cloud téléchargée est corrompue.
Voir la réponse **b) Le CloudInit Drive est absent de la configuration de la VM.** Sans ce lecteur, cloud-init cherche sa source de données, ne la trouve pas, et abandonne. L'image cloud n'a aucun compte d'origine : personne ne peut donc s'y connecter, et rien n'indique clairement pourquoi. Le choix c) est peu probable : une image corrompue ne démarrerait pas du tout, et vous n'auriez jamais d'invite de connexion. Le fait que le système se lance normalement prouve que le disque est intact.

Question 3

Vous changez le champ Password d'une VM clonée qui tourne depuis une semaine, puis vous la redémarrez. Le nouveau mot de passe fonctionne-t-il ?

  • a) Oui, Proxmox regénère le CD-ROM et cloud-init le relit au démarrage.
  • b) Non, cloud-init a déjà fait son travail au premier démarrage et ne recommence pas.
  • c) Oui, mais seulement après avoir détaché et rattaché le CloudInit Drive.
Voir la réponse **b) Non, cloud-init a déjà fait son travail au premier démarrage et ne recommence pas.** Un témoin écrit dans `/var/lib/cloud/` dit à cloud-init que l'instance est déjà configurée. Il n'y retouche plus, et c'est heureux : sans ça, toutes vos modifications manuelles seraient écrasées à chaque redémarrage. Le choix a) est tentant parce que la première moitié est vraie : le CD-ROM est bien regénéré. Mais personne ne le lit. Pour repartir de zéro, il faut soit recloner, soit lancer `cloud-init clean` dans la VM.

Question 4

Pourquoi utiliser un snippet vendor= plutôt que user= pour installer qemu-guest-agent sur toutes vos VM ?

  • a) Parce que user= ne sait pas installer de paquets.
  • b) Parce que vendor= s'ajoute au user-data de Proxmox, alors que user= le remplace.
  • c) Parce que vendor= s'exécute à chaque démarrage, et user= une seule fois.
Voir la réponse **b) Parce que `vendor=` s'ajoute au user-data de Proxmox, alors que `user=` le remplace.** Avec `vendor=`, les champs User, Password et IP Config de l'interface web continuent de fonctionner, et le fichier n'ajoute que ce qu'ils ne savent pas faire. Avec `user=`, il faut tout écrire soi-même dans le YAML, comptes compris. Le choix a) est faux : les deux formes acceptent exactement la même syntaxe `#cloud-config`. La différence n'est pas dans ce qu'on peut écrire, mais dans ce que le fichier remplace.