La cuisine de Gandi

Accueil > Hébergement > Comment est configurée une machine virtuelle ?

Comment est configurée une machine virtuelle ?

Avant-propos

Le processus de configuration actuel d'une machine virtuelle sur l'hébergement Gandi IaaS a changé mais le nouveau processus est toujours considéré comme instable et les appels API sont susceptibles de changer dans le futur. Si vous utilisez ce processus pour développer de nouveaux outils de déploiement de machine virtuelle, indiquez-le nous ! Gardez aussi à l'esprit que cette version de notre outil de provisioning est encore jeune, les interfaces sont aussi susceptibles de changer.

L'ancienne méthode

Jusqu'en novembre 2013, chaque machine virtuelle (VM) créée sur la plateforme d'hébergement Gandi IaaS démarrait en utilisant une copie d'un disque maitre. Le service gandi-kernel était ensuite lancé au démarrage et récupérait l'arbre des modules pour le noyau choisi. Le service gandi-config lancé au plus tot possible était en charge de configurer et d'optimiser légèrement le système (comme par exemple de préparer le fichier /etc/hosts). D'autres scripts lancés par des événements udev configuraient les vCPU additionnels, les disques virtuels attachés à la machine et les interfaces réseaux en utilisant un client DHCP. Une fois la VM correctement démarrée, notre backend se connectait à l'agent Gandi sur la VM et finissait de configurer les éléments nécessitant des informations de l'utilisateur (en créant l'utilisateur 'administrateur' et en changeant le mot de passe root).

Nous avons voulu changer ce processus

Comme nous l'avions précédemment annoncé, nous avons activé les VLANs sur notre plateforme hébergement IaaS pour tous nos clients. La suite logique est d'autoriser la création de VM sans interface avec adressage publique. Nous voulions encore utiliser le premier démarrage de la VM pour les configurations particulières du système.

Comme certaines VM peuvent ne pas avoir accès à notre réseau ou même seulement à notre serveur miroir (mirrors.gandi.net), nous devons passer les informations au script de configuration pendant le démarrage de la VM. Notre backend ne peut donc plus se connecter sur chaque VM pour finir la configuration du système.

La nouvelle méthode

Notre nouveau processus de configuration utilise maintenant l'espace de swap; notez que celle-ci vous est attribuée automatiquement au démarrage en fonction de la mémoire vive RAM allouée à la machine virtuelle. Cet espace est détruit à chaque arrêt de la VM. Nous avons fait quelques changements dans la création du swap pour injecter une archive tar contenant un script de bootstrap, un fichier en format JSON contenant les informations spécifiques à propos du système de la VM (voir notre exemple ci-dessous) et l'arbre des modules pour le noyau démarré.

Une fois la VM démarrée pour la première fois, un nouveau service gandi-bootstrap est démarré le plus tôt possible et récupère les données dans l'archive tar écrite dans l'espace swap. Il lance ensuite le script de configuration qui créé l'utilisateur système, change le mot de passe pour root, prépare l'interface virtuelle principale en configuration statique. Le meme service installe ensuite l'arbre des modules du noyau dans le repertoire valide (soit /lib/modules ou nouvellement /usr/lib/modules).

Après le premier boot avec le nouveau processus, la configuration réseau va être écrite dans les fichiers de configuration classique du système. Dans le cas de Debian par exemple, le fichier contenant les informations d'adressage se trouve dans /etc/network/interfaces.

Le service gandi-config qui existe déjà est encore présent et configure certains points du système de la VM. Il lit encore /etc/{default,sysconfig}/gandi mais la phase de configuration est moins complexe et moins longue. Les règles udev décrites dans /etc/udev/rules.d/86-gandi.rules sont encore utilisées. L'activation de CPU virtuel, de disque(s) supplémentaire(s) et d'interface(s) virtuelle(s) (sauf eth0) est encore géré de manière automatique. Le service gandi-mount est aussi présent. Il est lancé pendant la première phase du démarrage de la VM et re-déclenche les appels udev pour attacher et monter les disques virtuels disponibles.

Finalement, le service gandi-postboot exécute une commande que le client a spécifiée pendant la création ou le démarrage de la VM (par le formulaire du site web ou l'appel de la méthode API). La commande ou ensemble de commandes peut être par exemple :

  • wget -O /install https://mywebsite.tld/install && chmod +x /install && /install,
  • la VM peut s'enregistrer à un serveur Puppet/Chef/Salt,
  • une autre idée que vous pouvez avoir !

Le fichier de configuration en format JSON dans /gandi/config est présent après l’exécution du service 'gandi-bootstrap' et contient de nombreuses informations concernant la VM. Votre script ou programme de configuration peut facilement lire ce fichier et extraire les informations du format JSON. Voici un exemple de configuration : {

   "nameservers": [
       "217.70.184.225",
       "217.70.184.226",
       "217.70.184.227"
   ],
   "vdi": [
       {
           "vdi_access": "read/write",
           "vdi_format": "ext4",
           "vdi_label": "testdisk11",
           "vdi_size": "10240"
       }
   ],
   "vif": [
       {
           "pna": [
               {
                   "pbn": {
                       "pbn_gateway": "92.243.31.254",
                       "pbn_network": "92.243.28.0/22"
                   },
                   "pna_address": "92.243.28.208"
               },
               {
                   "pbn": {
                       "pbn_gateway": "fe80::45",
                       "pbn_network": "2001:4b98:dc0:45::/64"
                   },
                   "pna_address": "2001:4b98:dc0:45:216:3eff:fe6c:4c40"
               }
           ],
           "vif_mac": "00:16:3e:6c:4c:40",
           "vif_number": 0
       }
   ],
   "vm_conf": {
       "ssh_key": "ssh-rsa AAAAB3uHyeruUQ== joe@bar",
       "password": "$6$hashofthepassword",
       "user": "kevin",
       "run": "wget -O /install https://mywebsite.tld/install && chmod +x install && /install",
   },
   "vm_hostname": "myvm",
   "vm_max_memory": 24576,
   "vm_memory": 1024

}

Nos clients n'ont jamais eu la possibilité de re-configurer leur VM en mode expert en utilisant notre ancien processus backend/agent. Avec notre changement, la reconfiguration du système pourra être demandée lors d'opérations de démarrage de la VM. Il nous reste à donner la possibilité en étendant nos méthodes API (notamment hosting.vm.start). Le service gandi-kernel avait vu le jour comme un hack pour simplifier la migration des noyaux de même version majeure quand la VM redémarrait. Ce service est maintenant supprimé car l'arbre des modules est déjà présent sur le système au moment du démarrage dans l'espace de swap.

Toutes les machines virtuelles créées sur nos trois centres de données (Paris, Baltimore et Bissen) utilisent déjà le nouveau processus. Toutes les machines déjà existantes ne sont pas impactées par le nouveau process.

Avantages

Comme notre backend ne doit plus se connecter sur la machine virtuelle fraichement créée pour configurer le système, le temps de démarrage d'une VM avant d'etre utilisable par les clients est plus bas qu'avec la précédente méthode.

Des nouvelles fonctionnalités vont voir le jour par effet de bord : vous aurez la possibilité de choisir la taille de votre disque principal à la création de votre VM. Le processus impose actuellement un disque d'une taille de 3 Go.

Des nouvelles fonctionnalités vont apparaitre dans un futur proche :

  • création d'une machine virtuelle avec seulement un adressage IPv6 qui permet d'économiser le prix d'une adresse IPv4,
  • création d'une machine virtuelle avec seulement une adresse réseau privée dans un Private VLAN défini.