Ansible & VMware...et autres

Introduction

Après avoir déployé Ansible sous Windows et préparer un template VMware à être cloné, il est temps de poursuivre la configuration d’Ansible pour lui permettre d’interagir avec vCenter.

Ansible et les inventaires

Ansible reste dans son fonctionnement de base, un exécutable capable de se connecter, principalement en SSH, à une cible distante pour y exécuter des commandes.

Ansible a donc besoin qu’on lui fournisse une ou plusieurs destinations de connexion.

On va pour cela s’appuyer sur des inventaires.

Un inventaire peut être un simple fichier à plat au format ini ou yaml. Il peut être également dynamique via l’usage de scripts python capables d’interroger une source tierce pour récupérer la liste des cibles à piloter. Il est même possible de mixer les inventaires.

Dans le cas d’un inventaire dynamique, vous pouvez écrire votre propre script, mais la communauté fournit également des modules qui viennent ajouter le support de différentes sources.

Dans l’exemple qui va suivre, le but est de constituer l’inventaire à partir d’un vCenter. Ansible va ainsi pouvoir récupérer la liste des VMs, mais également associer ces VMs à des groupes fonctions de différentes caractéristiques.

L’avantage de constituer des groupes est de pouvoir lancer des commandes sur un ensemble de serveurs assurant le même rôle et devant donc avoir des composants configurés à l’identique.

Une VM peut appartenir à plusieurs groupes.

Plusieurs critères peuvent être utilisés pour constituer un groupe, comme le type d’OS, l’appartenance à un réseau ou comme çà va être le cas ici la présence de tags.

Toujours en lien avec le rachat de VMware par Broadcom, il est possible que je sois amené à changer de plateforme d’exécution, et dans ce cas je devrais travailler sur une nouvelle source d’inventaire.

Ansible restant une référence sur le marché, il existe de nombreux exemples de gestion d’inventaire et la communauté fournit de nombreux scripts et modules. Il est fort probable que je puisse évoluer vers une autre plateforme sans trop de difficultés. Dans tous les cas, la logique globale présentée ici reste valable et pourra servir de base dans d’autres situations.

Gestion de VMWARE par Ansible

Ansible est déployé sur un poste Windows via WSL

Composants supplémentaires

Afin de pouvoir interagir avec l’écosystème VMware, Ansible nécessite des modules additionnels, qui eux même font appel à des composants tiers.

On va commencer par installer le gestionnaire de package python pip

sudo apt install python3-pip

On s’assure d’avoir les composants python à jour:

pip3 install --upgrade pip setuptools

On peut désormais installer le SDK vmware python:

pip3 install --upgrade git+https://github.com/vmware/vsphere-automation-sdk-python.git

Même si en l’état, Ansible serait déjà capable de fonctionner, il est préférable d’utiliser le plugin de la communauté pour avoir plus d’options.

Une grosse partie des plugins et autres sources d’exemples sont disponibles sur le site Ansible Galaxy devenu au fil du temp une véritable mine d’or pour tout utilisateur de Ansible.

Une commande existe nativement pour récupérer un module publié sur Galaxy:

ansible-galaxy collection install community.vmware

Update 18/08/2024 - A partir de Ubuntu 24.04

Lorsque j’ai mis à jour mon instance Ubuntu en 24.04, je me suis aperçu d’un problème entre la version de python fournie et les librairies vSphere incluses dans le package pyvmomi.

Si vous êtes dans cette situation, vous pouvez suivre les consignes données ici et revenir ensuite à cet article pour poursuivre la configuration.

Configuration Ansible

Maintenant que tout est prêt, on va pouvoir indiquer à Ansible d’utiliser comme source d’inventaire le plugin VMware.

On édite son fichier de configuration local vim ~/.ansible.conf

Dans la section default, on va indiquer l’emplacement des fichiers d’inventaires (étant sous WSL, mon arborescence Windows est accessible dans /mnt)

Dans la rubrique inventory, on ajoute à la section enable_plugin l’option community.vmware.vmware_vm_inventory

Configuration de la connexion

On va pouvoir créer le fichier de configuration nécessaire à la connexion d’Ansible à vCenter.

Il est fortement conseillé de créer un compte de service dédié. Ce compte peut être local à vCenter ou issu d’un annuaire d’entreprise interrogeable par vCenter.

Dans mon exemple, je dispose d’un Active Directory, je vais donc l’utiliser et créer un compte spécifique.

Le compte doit être ajouté au vCenter. Pour notre besoin, Ansible peut se connecter en lecture seul.

On n’utilise pas Ansible pour déployer des ressources VMware (je préfère utiliser terraform pour cela), l’accès au vCenter est utile uniquement pour récupérer la liste des VMs auquelles Ansible devra se connecter.

La connexion SSH aux VMs ne se fait pas via ce compte de service, mais via un compte locale présent dans le template Linux de base (et donc hérités dans toutes les VMs clonées)

Il est nécessaire de créer le fichier de configuration a l’emplacement ou Ansible s’attend à trouver ses fichiers d’inventaires.

Il faut au sein de ce répertoire créer un fichier yml vcenter.vmware.yml qui va contenir les informations de connexion au vCenter

    
plugin: community.vmware.vmware_vm_inventory
strict: False
hostname: vcenter.coolcorp.priv
username: svc_prd_ansible@coolcorp.priv
password: mon_password_non_ce_nest_pa_ça
validate_certs: False
with_tags: True
hostnames:
- 'config.name'
keyed_groups:
- key: tags
separator: ''
  

La section keyed_groups permet d’ajouter les critères à retenir pour constituer les groupes de VMs

Comme vous pouvez le constater, la notion de « tags » est incluse de manière à ce que Ansible les exploite

Dans hostname, on indique à Ansible de considérer l’information config.name comme nom de VM. C’est important, car de base Ansible va considérer l’UUID de la VM, soit une variable plus complexe à manipuler. Il sera plus simple de lancer un playbook sur une VM en indiquant son nom dans l’inventaire vCenter plutôt que son UUID.

Le plus critique est l’ajout des informations d’identification rattachées au compte de services utilisé pour communiquer avec le vCenter. C’est une donnée confidentielle.

Heureusement Ansible inclut la possibilité via la commande ansible-vault de chiffrer ce fichier afin de le rendre illisible en cas de vols ou perte.

Il y’a différente manière d’utiliser ansible-vault que je ne vais pas détailler ici.

On va se contenter de chiffrer l’inventaire de manière à ce qu’à chaque lecture de ce dernier, Ansible demande un mot de passe de déchiffrement:

ansible-vault encrypt /mnt/mon_emplacement_d_inventaire/vcenter.vmware.yml

Si on relit le fichier d’inventaire, celui-ci est maintenant chiffré et illisible sans le password entré lors de la commande précédente.

On va pouvoir lancer une commande ansible pour vérifier que tout fonctionne.

Demandons la liste des VMs avec leurs informations.

ansible-inventory vcenter.vmware.yml --list --ask-vault-pass

(Si on ne précise pas l’option –ask-vault-pass, Ansible ne demandera pas le mot de passe de déchiffrement et le fichier d’inventaire ne pourra être lu).

La même commande avec l’option graph permet d’afficher une arborescence de son inventaire

ansible-inventory --ask-vault-pass --graph

Comme deux VMs ont un tag commun, on observe bien que Ansible les a associés à un groupe portant le nom du tag « TAG_COOLCORP_APPS_CRYPTO ».

Le cas de tdnf

Pour valider définitivement la configuration on va essayer de déployer un package sur la VM template.

Au préalable on va devoir procéder à une petite installation complémentaire.

En effet, comme je l’ai indiqué dans la partie concernant mon template, l’OS utilisé PhotonOS est un peu particulier.

Celui-ci exploite par défaut une version « allégée » du gestionnaire de packet dnf appelé tdnf. Or ce gestionnaire de package n’est pas manipulable directement par Ansible.

VMware propose néanmoins un module additionnel pour prendre en charge tdnf.

Vérifions ou Ansible s’attend à trouver ses modules par défaut avec la commande:

ansible-config dump |grep DEFAULT_MODULE_PATH

Créez le dossier propre à votre profil si nécessaire (normalement ~/.ansible/plugins/modules)

Puis on copie le module tdnf.py disponible ici

(la commande suivante simplifie l’opération)

wget https://raw.githubusercontent.com/vmware/photon/master/SPECS/ansible/tdnf.py

Demandons à Ansible de déployer sur la VM template le packet iotop dans sa dernière version en sollicitant le module tdnf fraichement ajouté

ansible nom_template -m tdnf -a "name=iotop state=latest" --become --ask-vault-pass

En résumé

L’infrastructure VMware que j’utilise dispose d’un template preconfiguré et basé sur un OS optimisé pour l’exécution des conteneurs.

Ansible est déployé sur un poste Windows via la couche WSL et dispose d’un accès en lecture seul au vCenter afin de pouvoir utiliser ce dernier comme source d’inventaire.

Le template contient les informations d’identification SSH permettant à Ansible de s’y connecter.

Il est donc possible, après le déploiement des VMs via terraform basées sur ce template, de passer le relais à Ansible afin qu’il puisse par la suite y déployer tous les prérequis et fichiers de configuration propre à l’installation d’un cluster Kubernetes.