Road to Ansible : il était temps !

Bonjour à tous, les gens ! Ah, les vacances d’hiver, cette période si douce où les alpages nous appellent, les pistes nous font de l’oeil et même la randonnée en raquettes a des cotés sexy … ou pas, cette année … Mais, alors qu’est-ce qu’on peut bien faire à la place ? Me je m’interroge, je dubite, je me questionne ? De l’auto-formation pardi ! Et on s’attaque à du lourd : Ansible.

Depuis plus de 10 ans maintenant, l’objectif de notre équipe a toujours été de franchir les étapes du SDDC/Private cloud pas à pas, une marche à la fois : virtualisation, SDS, SDN, SDDC. Depuis maintenant plus de 2 ans, c’est le SDN avec NSX-T qui a occupé une grande partie de notre énergie, et même si nous en parlons depuis déjà depuis longtemps avec nos intégrateurs, Ansible et l’infrastructure-as-code étaient, jusqu’à très récemment, un sujet assez peu concret.

Aujourd’hui la donne a changé et les collègues de notre cellule réseau/sécurité prennent ce sujet à bras le corps, autant pour la constructions de nouveaux environnements entièrement virtualisés que pour le suivi de configuration de nos équipements réseau physiques. Cisco, NSX-T, vSphere … Ansible est maintenant une réalité opérationnelle et ne cesse de gagner du terrain.

De mon coté, je n’ai jamais pu prendre le temps de me frotter à la prod “as code”, malgré mon appétence sur le sujet. Il fallait que ça cesse ^^. J’ai donc occupé une partie de mes vacances à débroussailler le terrain et commencer à m’exercer sur mon vLab. Après une semaine de découverte, je peux déjà vous dire une chose à propos d’Ansible et des bibliothèques NSX-T/vSphere. Le plus difficile, c’est de s’y mettre ! Nul besoin de très hautes compétences en développement et en codage, même si, on ne va pas se le cacher, ça aide certainement au début, comme lorsqu’on se frotte à PowerShell ou au scripting Unix/Linux. L’apparente complexité d’Ansible est principalement liée, de mon point de vue, à la nécessité de maîtriser déjà les cibles que l’on va vouloir piloter. En gros, vous connaissez bien vSphere et c’est du quotidien pour vous. Vous travaillez déjà avec les templates ? Vous avez déjà tout ce qu’il faut pour démarrer sur Ansible en quelques jours !

D’autre part, on a coutume de dire, lorsqu’on scripte / développe des procédures, et ce, quel que soit l’environnement :
– “est-ce que je vais gagner du temps à automatiser ce que je veux faire ?”
– “est-ce que c’est une action que je fait très régulièrement ?”
Si vous répondez “oui” sans hésiter à l’une de ces deux questions, lancez-vous, vous ne le regretterez pas.

Bon, c’est pas un peu fini cette intro, là ?

Vous avez raison … je m’étale, je m’épanche, je brode … parlons peu, parlons bien.

Nous voici arrivé au coeur de ce premier billet rapide sur le sujet, l’occasion pour moi d’essayer de partager mes premières découvertes. Evidement, ne prenez pas ces futurs billets comme un cours en bon et due forme, je ne suis ni légitime ni même assez compétent pour vous décrire en profondeur le potentiel d’Ansible.

Pour commencer, il faut se donner un objectif. Pour moi c’était simple : créer quelques VMs, les customiser, préparer l’environnement NSX-T qui va bien (tier1, segment) et pourquoi pas poser des règles de filtrage sur ces machines. Ca n’a l’air de rien, mais avec ça, vous allez couvrir 90% des besoins au quotidien ^^. Je vous propose de commencer par le plus simple : la création d’une VM sous vSphere…

Bon, on installe maintenant ?

Hé, mais, pas si vite, il faut s’installer un environnement de travail qui fonctionne correctement. Là j’avoue j’ai pas mal galéré entre les version de Ansible, de Python (2 ou 3) et le choix de la distribution dans laquelle on allait opérer. J’ai essayé un peu toutes les combinaisons entre package manager type yum (CentOS/RedHat/Fedora) ou apt (Debian/Ubuntu) et l’utilisation de PIP (Package Installer for Python). A chaque fois ou presque, j’avais des soucis de chemins ou de version de python (sans doute que je m’y suis mal pris aussi ^^), mais au final, j’ai utilisé une méthode simple et qui a marché a peu près partout : utiliser pip et python en version 3.

En gros, vous installer python3 sur ce que vous voulez, ensuite vous faites en sorte, si ce n’est pas déja le cas, que pip3 soit aussi installé (en général il l’est de base) et ensuite vous utilisez ce pip3 pour installer le reste. Pour vSphere, il vous faut : pyvMomi, pyVim et ansible évidemment.

Sur macOS (que j’utilise beaucoup), ça se résume à (via Homebrew) :

… et le tour est joué. Vous pouvez déjà commencer à vous amuser avec le jeux d’API vSphere. Pour le coup, inutile de réinventer la roue, la meilleure approche, c’est de consulter les nombreux tuto sur le net (je vous en ai sélectionné quelques un en fin de billet) et construire petit à petit vos “playbook”. Les miens sont très roots, mais ils suffisent pour commencer à appréhender le fonctionnement d’Ansible. Vous pouvez aussi vous appuyer sur l’excellente documentation du produit, notamment sur le plugin vmware_guest qui fournit de nombreux exemples sur lesquels vous appuyer. Ne paniquez pas, comme toujours, au début, ça ne marche jamais ^^

Bon, on fait nos premiers pas avec vmware_guest ou pas ?

Commençons, comme prévu, par un petit playbook, sans ambition qui créé une une VM de type CentOS, configure le réseau de la machine en se basant sur une VM template (une simple installation standard de CentOS 7).

Vous noterez les doubles accolades encadrant des chaines de caractères particulières. Cela permet d’utiliser des variables que vous instanciez “hors contexte”, soit dans un fichier externe importé, soit directement en en précisant la valeur dans la ligne de commande d’Ansible. Pour le coup, les 4 variables vars_vmDC, vars_vcenterName, vars_vcenterName et vars_vcenterPassword, sont définies hors de ce playbook dans le fichier “vars.yml” qui est importé dans la première tache, grâce à la directive “include_vars”.

Pour ce qui concene vars_vmName, il suffit de l’indiquer dans la ligne de commande (ou pourquoi pas aussi dans le fichier vars.yml) :
ansible-playbook createVM.yml --extra-vars "vars_vmName=vmToto"

Rien que cela m’a occupé quelques heures pour bien maitriser les concepts et la syntaxe. En effet, si vous ne connaissez pas déjà le fameux langage YAML, sur lequel les playbooks sont basés, il faut un petit temps d’adaptation, notamment avec les indentations et la notion de liste (les “-“). Après, il faut creuser les mot-clés, pas de secret : une bonne doc de référence et un peu de patience au début seront vos meilleures armes. Notez que certains mot-clés ont des sens particuliers. La directive “state” notamment, est assez générique (on la retrouve dans de nombreux playbooks) et définit plutôt l’action souhaitée, même si elle s’entend plutôt comme un état qu’une action réelle (comme son nom l’indique). En effet, si vous mettez “state” à Absent au lieu de PoweredOff, vous donnez l’instruction à Ansible de supprimer purement et simplement la machine virtuelle dont le nom “name:” est XXXX si d’aventure il la trouve dans l’inventaire. Ansible n’est pas à proprement parlé un langage procédural comme on en connait de nombreux aujourd’hui. Vous n’écrivez pas un algorithme, mais bien “un état cible” à obtenir dans votre environnement. Le logiciel va par contre être obligé d’effectuer tout un tas d’actions techniques et d’appels d’API pour OBTENIR le résultat souhaité, à savoir une VM ayant l’état “PoweredOn”.

Du coup, un playbook, plus simple ordonnant la suppression de la machine créée précédemment, se traduira par deux états successifs : on vérifie que la machine est éteinte (et si ce n’est pas le cas, on l’éteint) et ensuite, on vérifie qu’elle n’existe pas (et si elle existe encore, on la supprime) :

Ce qu’il faut noter aussi avec le module vmware_guest plus généralement c’est qu’il s’appuie sur les capacités de customisation intégrées de vSphere. Ensuite, une fois la machine virtuelle montée, il est tout à fait possible, via un playbook basé sur l’usage extensif de ssh (Ansible s’appuie quasi systématiquement sur le protocole SSH pour avoir accès aux environnements cibles et les configurer comme il se doit) de la configurer plus spécifiquement, installer un serveur web ou configurer son SMTP. Pour l’instant, vous le voyez, je ne suis pas allé très loin encore, mais c’est un début qui est hautement satisfaisant ^^

Bon, et ensuite, c’est tout ??

Je vous ai dit que ce n’était que le premier billet d’une série (peut-être longue, à voir). Je ne vais pas tout vous raconter tout de suite. Plus sérieusement, un deuxième billet arrive très vite avec mes premiers pas sur NSX-T. Le fait est que je découvre presque en même temps que vous le potentiel de tout cela. Il faut que je trouve aussi du temps pour progresser et me sentir assez “solide” pour vous en parler sans que tout cela ne soit qu’un copier/coller d’un autre billet anglophone.

En attendant la suite et si l’aventure vous tente, je vous ai compilé des liens qui ont été ma principe source d’inspiration et de référence. Nul doute que cette liste va s’enrichir dans le futur. N’hésitez-pas, comme toujours, à partager et commenter ce billet, surtout que j’ai sans doute énormément de choses à apprendre dans le domaine. Toutes vos lumières, conseils et remarques seront les bienvenues ;)

Références :

Doc Ansible, vmware_guest : https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_guest_module.html
Doc Ansible, la syntaxe YAML : https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html
Un point de départ incontournable d’Ansible (selon moi) : https://riptutorial.com/ansible
Doc Ansible, les variables : https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html
Les distributions “customisables” par vSphere : http://partnerweb.vmware.com/programs/guestOS/guest-os-customization-matrix.pdf
What is Ansible : https://training.galaxyproject.org/training-material/topics/admin/tutorials/ansible/tutorial.html
Formation online Ansible, en Français : https://linux.goffinet.org/ansible/presentation-produit-ansible/