Pour différents cas d’usage vous pouvez être amené à devoir créer des images disques à partir de VMs existantes pour les réutiliser dans plusieurs scénarios (Image disque dans des blueprints ou comme template pour la création de nouvelle VM).
Cette opération uniquement possible en CLI sur CVM (et depuis peu en GUI sur Prism Central : Source ) peut s’avérer fastidieuse et nécessiter des droits que vous n’avez pas délégué à vos utilisateurs (surtout pour la CLI).
Pour automatiser cette partie là, j’ai créé un petit Runbook sur Nutanix CALM qui moyennant quelques appels API va venir automatiser ce process.
C’est aussi l’occasion de présenter au travers de cet article les possibilités offertes par un Runbook dans Nutanix CALM.
Le runbook est disponible sur mon github ici : Github runbook
Les Runbooks
Sur Nutanix CALM, les runbooks donnent la possibilité d’exécuter des tâches redondantes sur des points de terminaisons (appelés Endpoints) en se basant sur des conditions/dépendances. Par ce biais, on est en mesure par exemple d’exécuter la mise à jour d’un serveur applicatif ou BDD en arrêtant au préalable un proxy qui permet d’y accéder.
Les endpoints peuvent être de type :
- HTTP (pour attaquer une API par exemple)
- VM (Windows ou Linux)
- IP Address (pour par exemple attaquer des machines physiques Windows/Linux)
Sur ces endpoints, nous allons pouvoir exécuter des actions de types :
- Exécutions de scripts (Escript, Shell, Powershell)
- Faire des appels API
- Exécuter des actions baser sur une décision
- Exécuter des Loop While
Ces dernières nous permettent donc de conditionner nos actions.
Présentation du Runbook d’automatisation des création d’image
Note : les procédures d’utilisation détaillées sont disponibles dans le CALM Administration Guide
Pré-requis :
- Avoir activé CALM
- Avoir créé un projet dans CALM
- Avoir un compte local à Prism (dédié à cet usage) en mesure d’utiliser l’API
Création du Endpoint
Dans mon cas, je vais essentiellement faire des appels à l’API de Prism Element. J’ai donc créé mon Prism Element comme un endpoint HTTP :
Création des différentes étapes
Pour créer une image de disque, il faut que la machine soit au préalable éteinte. Voici donc les
différentes étapes du runbook qui vont utiliser différents types de tasks.
- Récupération de l’UUID de la VM en fonction d’un nom de VM en paramètre
- Récupération des informations sur le vdisk (dans mon exemple, mon disque système est très souvent labelisé scsi.0, c’est toujours le disque que je créé en premier et dont je me sers pour les images, libre à vous de modifier cette partie là)
- Vérification du status de la VM (ON ou OFF)
- Décision sur la nécessité d’éteindre la VM
- Création de l’image
- Loop sur la fin de la tâche de création de l’image
- Allumage du modèle source
Ce qui va donner dans le Runbook :
Création des variables
Lors de la création du runbook, j’ai ajouté les variables suivantes, qui vont pour certaines être instanciées par des actions et pour d’autres être spécifiées par l’utilisateur au lancement du runbook (Nom de la VM, Nom de l’image).
Quelques étapes
Vous pouvez retrouver l’intégralité des étapes dans le blueprint en question. Mais voici quelques exemples de plusieurs types de tâches :
Tâche HTTP request pour récupérer les informations sur la VM
Dans cet exemple, je vais récupérer les informations sur la VM (UUID, Status) qui vont m’être nécessaires dans la suite du runbook via un call API. Ici j’appel la ressources vms, sur mon endpoint PrismElement de type HTTP. Ensuite je viens setter mes variables VM_State et VM_UUID avec du JSONpath en filtrant sur le nom de ma VM.
Tâche de décision sur l’état de ma machine
Comme la machine à besoin d’être éteinte pour construire l’image, le runbook vient s’assurer vérifier que le status récupérer dans les informations de la VM est bien sur OFF. Donc avec une tâche de type Décision, je viens vérifier (avec un EScript) cette valeur et éteindre ma VM (via un call API en POST) si la valeur n’est pas sur OFF.
Tâche de type WhileLoop
Via un call API visible dans le runbook, après l’extinction de la machine, une tâche de création de VM a été créé (et a renvoyé un task_uuid) mais sans me donner le status de la tâche.
J’ai donc créé une tâche de type WhileLoop qui vient vérifier que la tâche est bien terminée (status de la tâche en succeed) par un appel à l’api tasks à chaque itération dans la limite de 20 itérations. Le script python arrête de s’exécuter si le status est sur succeed avec un exit(0).
Ces différentes tâches nous donnent donc le runbook suivant qui est conditionné par des decisions et qui automatise le processus de création d’image de bout en bout, de l’extinction de la VM à son rallumage.
Il ne reste plus qu’a le lancer et monitorer l’exécution de chaque steps… et vérifier son image :
