REX : Ansible & Windows

Introduction

Durant ma précédente mission moi et mon équipe avons commencé à utiliser Ansible pour administrer nos VMs (Virtual Machines) Windows. C’était presque un pari car nous n’avions aucun retour d’expérience, ni aucun écho sur cette pratique encore peu connu et on trouve peu de ressources sur ce sujet à part quelques tutoriels simplistes. Après un déploiement dans plusieurs environnements et l’administrations de plusieurs centaines de VMs, je vous rédige aujourd’hui ces quelques lignes pour synthétiser ce que j’ai appris et peut-être vous motiver à passer le cap.

Pourquoi utiliser Ansible avec Windows ?

Bien que Microsoft ait créé son propre language pour administrer ses serveurs, Powershell reste très clivant, certains adorent d’autres détestent, le principal point de discorde : sa verbosité. En ayant beaucoup fait je reste du côté de ceux qui ne l’apprécie guère, pourquoi ne pas tenter autre chose ?

L’idée derrière le fait d’utiliser Ansible avec Windows est de :

• avoir un seul outil d’administration pour Linux & Windows
• bénéficer des collections de modules créés par la communauté
• rendre plus simple la réutilisation de code via les rôles

Mise en place de la solution

L’installation et la configuration sont assez simple, bien que quelques choix soient à étudier.

1. Quel protocole de communication je souhaite utiliser ? SSH ou WinRM ?

La plupart de la communauté fait le choix de partir sur WinRM car c’est le protocole de communication natif à Windows, de plus la configuration par défaut à partir de Windows Server 2016 est suffisante pour tester ses premiers playbooks.

2. Comment je m’authentifie sur ma machine distante ? J’utilise un compte local ? Un compte de domaine ?

A noter que ces choix n’auront aucun impact sur l’élaboration de vos playbooks, seule la configuration d’ansible devra être adaptée.

3. Est-ce que je connais et matrise bien mon applicatif ?

Nous reviondrons sur ce point plus tard.

Les modules existants

Les modules existant pour Linux ne sont pas compatibles avec Windows, mais en faisant quelques recherches vous pourrez rapidement vous rendre compte que beaucoup de modules Ansible existent pour Windows ; ce qui vous permettra de faire la majorité des actions du quotidien sans créer les votres. Quelques modules restent manquants aujourd’hui notamment pour la création et la modification de GPO.

Création de modules

Attention, j’ai mentionné précédemment que je n’étais pas un grand fervant de Powershell mais lors de la création d’un module il devra bien être développé en Powershell (si les VMs cibles seront des Windows). Nous en faisons moins souvent mais ce n’est pas pour autant que nous nous en passons.

Quelques soucis avec WINRM

L’avantage principal d’utiliser ce protocole est que les connexions WINRM en https fonctionnent par défaut sur les Windows Server 2016 et plus donc il n’y a aucune configuration à faire au péalable. Mais j’ai pu constater quelques limites :

1. WINRM n’est pas toujours très fiable lors de tâches lourdes ou longues comme la copie de fichiers, l’installation de KBs… Les connexions ont tendance à se couper de manière aléatoire, j’ai essayé de jouer avec divers paramètre ansible comme ansible_winrm_operation_timeout_sec mais cela n’a apporté aucune amélioration.

2. Certains Antiviris comme McAfee (installé sur les VMs cibles) peuvent créer des alertes lors d’une connexion entrante. Après quelques recherches dans le code de la librarie utilisée par Ansible pour WINRM je me suis aperçu qu’il s’agissait une fonction principale de la librairie, il n’y avait donc peu de marche de manoeuvre de ce côté.

Ansible, Windows & SSH

Le manque de fiabilité de WINRM & les alertes de sécurité m’ont obligé à me tourner vers une alternative : SSH. L’idée peut sembler farfelu car ce protocole est plutôt associé au monde Unix/Linux mais j’ai été surpris de découvrir qu’OpenSSH est installé par défaut sur les Windows Server 2019, un aveux d’échec de la part de Microsoft ? 🤔

Je ne vais pas m’attarder sur l’installation et la configuration de Windows avec SSH car elle diffère assez peu de ce que l’on peut voir sur un OS open source.

Le constat est sans appel :

• plus de timeout
• plus de problème avec McAfee

C’est donc un des premiers point de configuration que je peux vous conseiller d’étudier à minima.

Cohabitation avec l’applicatif

Je vous ai spécifié plus haut qu’il était important de bien connaître l’applicatif que l’on exploite sur vos machines Windows car bien souvent sur ce type d’OS héberge une solution/application propriétaire et il peut arriver que l’on ne la connaisse pas de fond en comble. Pour ma part, nous utilisions une solution Cisco qui m’a obligé à adapter ma configuration ansible et Openssh et ne plus se reposer sur des paramètres par défaut.

a. shell type

Certaines solutions peuvent déjà se servir d’OpenSSH avec une configuration établie par l’éditeur. Dans mon cas j’ai dû uniformiser le paramètre **set ansible_shell_type** pour être égal à powershell au lieu de cmd par exemple.

b. les binaires

L’applicatif que nous utilisions déployait des executables reboot.exe et shutdown.exe, hors Windows disposent déjà d’executables du même noms mais avec des paramètres (inputs) différents ce qui rendait les certains modules communautaires inutilisables.

Comme il n’est jamais très judicieux de modifier la configuration utilisée (ici l’ordres des variables d’environnement) par une solution propriétaire j’ai dû modifier les modules ansible faisant appel à ces binaires.

Conclusion

Avec cette fin un peu critique vous pourriez penser que c’est une mauvaise expérience, mais vous vous tromperiez ! Si je devais retravailler un jour avec l’OS de Microsoft je pousserai cette solution tout de même. La principale différence avec Linux est qu’il peut y avoir un phase de customisation plus fine qu’avec son comparse open source. Après cette phase de configuration vous gagnerez beaucoup de temps lors de vos développements.