Ansible sous Windows ou presque...

Logo Ansible

Cliquez sur l'image pour l'agrandir.

Introduction

Ansible est devenu en quelques années la référence pour la gestion de la configuration de son parc serveur, voire même de son infrastructure en général (notamment le réseau).

Arrivé comme une alternative au classique Puppet ou à Salt, il a su s’attirer les faveurs d’un grand nombre d’administrateurs système dont je fais partie.

Sa force principale (celons-moi) est d’être « agentless » pour ne dépendre que d’une simple connexion SSH pour piloter ses cibles. Ajoutez à cela des modules toujours plus nombreux permettant de simplifier l’écriture des fameux playbook et vous obtenez un superbe outil de déploiement et de conformité pour vos configurations serveur ou autres.

L’idée de cet article n’est pas de rentrer dans le détail du fonctionnement d’Ansible mais de démontrer qu’Ansible est parfaitement exploitable depuis son poste de travail Windows

Principe de Ansible (source : https://blog.stephane-robert.info/docs/infra-as-code/gestion-de-configuration/ansible/introduction/)

Cliquez sur l'image pour l'agrandir.

Installation d’Ansible sous Windows

Pour cet exercice, il est nécessaire d’avoir déployé la couche WSL pour Windows. Je vous invite à suivre le tutoriel suivant

Sous condition d’avoir choisi Ubuntu comme « sous OS Linux », l’installation d’Ansible est très rapide.

Lancez votre terminal windows, ouvrez un onglet dédié à WSL, et lancez la commande d’installation d’Ansible.

sudo apt install ansible
Installation de ansible via APT sous WSL

Cliquez sur l'image pour l'agrandir.

Configuration d’Ansible

Il vous est possible de configurer ansible de deux manières.

  • au niveau du systeme via /etc/ansible/ansible.cfg
  • au niveau de votre session via ~/.ansible.cfg

  • Nous allons modifier le fichier de l'environnement utilisateur

    Dans la partie [defaults], vous pouvez préciser l’emplacement de vos fichiers d’inventaire. Ces inventaires peuvent être de différents types allant de simples fichiers à plat à des scripts python.

    C’est la base de travail d’Ansible qui utilise ces inventaires pour construire la liste des cibles à atteindre (vos serveurs, switchs…) fonction de ce que vous lui demanderez.

    Étant donné qu’on utilise le sous systeme Linux pour Windows, rien n’empêche de faire pointer vos inventaires dans un dossier Windows. Pour rappel toute votre arborescence Windows est accessible depuis WSL via le point de montage /mnt.

    Il en va de même pour les rôles. Ces derniers sous forme de playbook rassembleront les consignes à appliquer sur vos cibles.

    Fichier de configuration ansible

    Cliquez sur l'image pour l'agrandir.

    Mise en place d’un utilisateur dédié

    Pour plus de cohérence, vous pouvez référencer un utilisateur spécifique pour vous connecter à vos cibles. Ici j’ai choisi « ansible-windows », bien entendu ce user devra avoir une existence sur les ressources auxquels Ansible va essayer de se connecter. Nous verrons ce point un peu plus tard.

    Personnellement j’encourage à utiliser un utilisateur spécifique à Ansible de manière à bien différencier les actions réalisées via Ansible des actions réalisées par un utilisateur en direct.

    Il faut donc au préalable créer ce user sur WSL.

    sudo useradd ansible-windows
    sudo mkdir /home/ansible-windows
    sudo chown -R ansible-windows /home/ansible-windows/

    Puis on se connecte sous l’identité de ce user

    sudo su - ansible-windows

    Ansible utilise SSH pour se connecter à ses cibles, il faut donc lui générer une clef SSH.

    ssh-keygen
    Generation clefs SSH

    Cliquez sur l'image pour l'agrandir.

    Afin que cette clef soit utilisable sans forcément prendre l’identité de l’utilisateur nous allons procéder aux modifications des droits suivants

    Ce n'est pas une bonne pratique de sécurité de changer les droits par défault des éléments SSH, mais cela va me permettre d'utiliser mon utilisateur courant pour lancer mes commandes et que ces dernieres s'exécutent sur les cibles avec le compte ansibe-windows.

    chmod g+r /home/ansible-windows/.ssh/id_rsa
    chmod g+x /home/ansible-windows/.ssh/

    Pour terminer, je vais ajouter mon compte au groupe associé à ansible-windows.

    vim /etc/group
    Groupe Ansible

    Cliquez sur l'image pour l'agrandir.

    Résumé de la configuration

    Si je résume la configuration de mon installation d’Ansible sous Windows, je peux reprendre l’ensemble dans mon fichier de configuration locale

    vim ~/.ansible.cfg
    Cluster Kubernetes

    Cliquez sur l'image pour l'agrandir.

    Notez l’ajout du paramètre « private_key_file » qui pointe vers la clef privée de mon utilisateur « ansible-windows » que j’ai créé précédemment.

    De cette manière, je peux simplement lancer depuis mon terminal Windows une instance WSL sous mon identité propre, mais exploiter le compte « ansible-windows » (via l’usage de sa clef privée) pour la connexion à mes serveurs distants lorsque je fais appelle à Ansible.

    On pourrait dire en quelque sorte que j’utilise un compte de service. Bien entendu ce compte devra être connu de mes cibles et sa clef autorisée. Ce point sera abordé par la suite.

    Une nouvelle section [inventory] a été ajoutée. Elle permet de préciser les formes d'inventaire supportés. Dans mon cas, j'active le support des fichiers yaml ainsi que du module communautaire vmware pour créer un inventaire directement à partir d'un vCenter. Ce point sera évoqué par la suite.

    A ce stade, Ansible est parfaitement fonctionnel pour etre appelé depuis votre poste de travail Windows via la couche WSL

    Lancement d'une commande ansible

    Cliquez sur l'image pour l'agrandir.