LinuxFr.org : les journaux  -  Proxmox_GK : un utilitaire shell pour déployer vos invités LXC/QEMU, avec Cloud-init

 -  3 août - 

Sommaire

• • Que peut-il faire ?
    • Modes de déploiement flexible
    • Customisation et templating
  • Structure fonctionnelle
  • Conclusion
    • Aller plus loin :

Proxmox GK alias "Proxmox Guests Kickstart¨

Pour ceux qui ont déjà eu l'occasion d'utiliser Proxmox VE, peut-être, avez-vous, comme moi ressentis la même frustration, de constater l'absence d'outils natifs pour automatiser le provisionnement et déploiement des invités, que ce soit pour les machines virtuelles ou les conteneurs. Ce qui laissait la part belle aux solutions comme : Packer, Terraform|OpenTofu, Ansible, etc. De très bon outil s'il en est, mais peut être aussi un peu surdimensionné au regard du nombre de leurs fonctionnalités. Ce que je trouvais particulièrement regrettable considérant que quasiment toutes les briques nécessaires à l'automatisation des taches de provisionnement et déploiement était présentes dans Proxmox, il fallait juste un liant pour les faire travailler de concert.

Initialement, j'utilisais un set de scripts shell hétérogènes, exclusivement pour automatiser la création de vm compatible Cloud-init, (je m'étais alors grandement inspiré de l'article "Linux VM Templates in Proxmox on EASY MODE using Prebuilt Cloud Init Images"). Au bout d'un moment, mes scripts prenant de plus en plus d'importance au fur et à mesure des ajouts de nouvelles fonctionnalités, je me rendis compte qu'il y avait là suffisamment de matière pour développer un utilitaire complet.

En tout cas bien assez pour finaliser une première version d'un utilitaire simple et rapide à mettre en œuvre, dédiée spécifiquement à ces taches de provisionnement et déploiement. En ce sens, c'est plus une extension à Proxmox qu'un outil à part entière, et, bien entendu bien moins complet que les solutions précitées.

J'avais quelques principes directeurs lors du développement :

• Avoir une interaction transparente avec les commandes système, une gestion des erreurs et un débogage simplifié. Afin d'aider à la maintenance et modularité du code.

• Il me fallait aussi un processus d'installation simple, donc réduire le plus possible le nombre de dépendances, notamment en privilégiant l'appel aux outils UNIX de base.

• Enfin, je voulais une courbe d'apprentissage faible, nul besoin de définir une nouvelle nomenclature de notions à assimiler pour pouvoir manipuler l'utilitaire, simplement réutiliser et unifiée les concepts des commandes natives et bien-sur la syntaxe cloud-init.

Que peut-il faire ?

Concernant les principales fonctionnalités :

• Configuration unifiée via Cloud-init de vos invités LXC et QEMU/KVM.
• Le déploiement flexible de vos invités :
  • en mode unitaire ou en série
  • entièrement automatisé ou avec vos propres fichiers de configurations
• Le provisionnement rapide et personnalisé de vos Templates Proxmox

Voyons voir cela en détail, maintenant…

Modes de déploiement flexible

Comme je vous le disais plus haut, je voulais avant tout un outil simple permettant par exemple de lancer un invité, que ce soit un conteneur ou une machine virtuelle en une seule ligne de commande. Ici, nous déployons une vm sous Alpine Linux, la syntaxe regex étant supportée avec grep, il n'est pas nécessaire de renseigner le nom complet de l'image.

pgk -a kvm alpine

Il est aussi possible à partir d'une même image de déployer plusieurs invités. Par exemple trois machines virtuelles Alpine Linux, avec un ID (100,101,102) pour chacune d'entre elles, ainsi qu'une adresse ip dédiée au format 192.168.2.**.

pgk -b kvm alpine 141,142,143 192.168.2.14,15,16

Dans l'ensemble de ces cas de figure, une configuration par défaut sera appliquée depuis un fichier "shape" en fonction de l'image choisie, et effectuera un paramétrage de base de(s) invité(s), comprenant : l'ajout d'un utilisateur par défaut, la configuration d'OpenSSH, l'installation de l'agent QEMU (uniquement pour les vm), l'ajustement du fuseau horaire et de la localisation.

L'ensemble des valeurs par défaut sont accessibles depuis le fichier de configuration principal /etc/pgk/config.cfg, éditable avec pgk -e confile.

Customisation et templating

Il est aussi possible de passer son propre fichier shape, afin d'adapter au cas par cas la configuration de vos invités. Vous avez quelques shapes d'exemple (sur une base Alpine Linux), que vous pouvez tester :

• ss_kvm_alpine-docker.yaml: Une pré-configuration docker pour les invités QEMU/KVM

• ss_plxc_alpine-docker.yaml: Une pré-configuration docker pour les conteneurs privilégiés

• ss_ulxc_alpine-docker.yaml: Une pré-configuration docker pour les conteneurs non privilégiés

Il vous suffira de les renseigner en argument, comme suit :

pgk -a lxc alpine ss_ulxc_alpine-docker.yaml

Dans cet exemple, nous créons notre propre shape pour une vm. Il nous sera ensuite demandé de choisir un modèle de base prérempli en fonction de la distribution choisie. Enfin, il ne restera plus qu'à apporter nos modifications, en fonction de nos besoins :

pgk -e kvm my_shape.yaml

Là encore, les champs préremplis se font, fonction de vos paramètres dans le fichier de configuration principal /etc/pgk/config.cfg. Aussi, tous les fichiers shape sont structurés de la même manière et respectent la syntaxe YAML. Trois blocs doivent être présents :

• gs_values: Contient les valeurs nécessaires à la création de l'invité LXC/QEMU, elles seront extraites et interprétées comme des variables d'environnement, et ne concerne que la création de la vm ou du conteneur (interagissant essentiellement avec /usr/bin/pct et /usr/bin/qm).

• extra_guest_config: Bloc optionnel, contenant les directives (une par ligne) que nous aimerions passer directement dans le fichier de configuration PVE de l'invité, /etc/pve/lxc/CTID.conf ou /etc/pve/qemu-server/VMID.conf. À utiliser avec précaution, une mauvaise instruction pourrait empêcher l'invité de démarrer correctement.

• cloud_init: Contient les directives qui seront interprétées par cloud-init pour la configuration de l'invité.

Enfin, vous pouvez provisionner vos templates Proxmox, ici en réutilisant notre shape précédemment crée.

pgk -t kvm my_shape.yaml

Le template en sortie pourra être ensuite réutilisé, comme un template classique, par simple clonage, comme base pour des déploiements ultérieurs.

Structure fonctionnelle

Je ne voulais pas que l'utilitaire modifie en profondeur le fonctionnement de Proxmox. Son installation, ajoute seulement quelques fichiers prérequis en suivant la nomenclature officielle d'un paquet Debian classique.

• /etc/pgk/config.cfg
  le fichier de configuration principal

• /var/lib/pgk:
  Contient les shapes de base pour les différents types d'invités, et les index, c'est aussi dans ce dossier que seront stockés vos shape personnalisé. Contient également, certains fichiers nécessaires à l'initialisation de cloud-init pour les conteneurs.

  • init/ds_kvm_*.conf: shape par défaut pour les invités QEMU/KVM
  • init/ds_lxc_*.conf: shape par défaut pour les invités LXC
  • init/cinit.sh: Charge utile nécessaire à la configuration cloud-init des conteneurs.
  • lxc_index.json: index auto généré, contient les adresses des différentes images des conteneurs et leurs shape par défaut.
  • kvm_index.json: index contenant les adresses des différentes images des guest QEMU/KVM

• /usr/lib/pgk
  Contient les scripts assurant l'exécution des fonctions principales.

  • /usr/lib/pgk/pgk.sh /usr/bin/pgk: Exécutable principal, lien symbolique vers /usr/bin/pgk.

• /var/log/pgk.log
  Le fichier de log, trace les process lors de la création des invités, ainsi que le process de paramétrage de cloud-init pour des conteneurs.

Conclusion

En l'état, le projet est encore en phase alpha, et je suis seul à travailler dessus (pour le moment). Il me faudra encore améliorer le code, et ajouter les quelques dernières fonctionnalités (mais non des moindres). Voilà, je pense avoir tout dit, n'hésitez pas à me faire vos retours.

Aller plus loin :

• GitHub

Commentaires : voir le flux Atom ouvrir dans le navigateur

par asded