Débutez avec Ansible et gérez vos serveurs Windows

I. Présentation d'Ansible

Ansible, qu’est-ce que c’est ?

Écrit en Python, Ansible est un outil Open Source qui permet l’automatisation de tâches. Grâce à lui, vous pourrez gérer vos configurations de serveurs plus facilement, et de façon automatique grâce à l’exécution de tâches sur des groupes d’hôtes.

Il n’utilise pas de client, d’agent, sur les hôtes clients mais nécessite uniquement une partie serveur Ansible, forcément sous Linux.

Par ailleurs, Ansible peut éventuellement être utilisé à des fins de contrôle, par exemple pour s’assurer que certains services soient exécutés sur un groupe de machine.

Sachant qu’il est possible de développer ses propres tâches grâce aux langages YAML, vous pourrez dompter vos serveurs comme bon vous semble avec Ansible !

Il est à noter qu’une interface graphique est disponible pour l’outil, mais c’est un outil commercial nommé Ansible Tower.

Ansible et Windows

Il faut savoir qu’Ansible ne peut pas s’installer sur Windows, même en passant par Cygwin. Autrement dit, le « serveur » Ansible doit forcément être sous Linux, Debian 8 dans cet exemple. Cela n’empêche pas qu’avec Ansible, il est possible d’automatiser certaines tâches sur des serveurs sous Windows, pour ma part sous Windows Server 2012 R2.

D’ailleurs, nous n’utiliserons pas SSH comme cela est le cas lorsqu’on administre des serveurs Linux avec Ansible, simplement car Windows ne connaît pas SSH. Il a son propre module d’administration à distance en ligne de commande : WinRM (Windows Remote Management).

Voici le schéma de l’infrastructure utilisée dans le cadre de cette mise en place :

En résumé : un serveur Ansible (JESSIE-01), un serveur Active Directory (SRV-AD01) et un serveur Windows classique membre du domaine (SRV01). Les serveurs Windows sont dans le domaine it-connect.fr.

Le fichier de configuration d’Ansible est : /etc/ansible/ansible.cfg.

II. Différence entre Ad Hoc et PlayBooks

Pour le moment, ces deux termes vous sont étrangers, et pourtant, ils sont au cœur de l’utilisation d’Ansible. Ils permettent tous les deux d’exécuter des actions sur les hôtes clients, voici on peut les définir :

- Ad Hoc :

Exécuter des commandes rapides à partir du binaire ansible. Par exemple, exécuter une action simple qui consiste à redémarrer 10 machines de votre infrastructure (administré par Ansible).

- PlayBooks :

Exécuter des actions à partir du binaire ansible-playbook. Un Playbook est écrit en YAML et permet de réaliser des actions plus complexes.

Le fait que les playbooks soient écrit en YAML, rend le code facilement lisible et compréhensible, on parle généralement de code « human readable ».

Des exemples de PlayBooks sont accessibles sur le GitHub d’Ansible : Ansible Examples

Nous verrons au sein d’un ou plusieurs autres articles les PlayBooks en détails.

Finalement, avec les « actions Ad-Hoc » vous pourrez faire des choses basiques alors qu’avec les « actions PlayBooks » vous pourrez effectuer de la véritable automatisation avancée. Les deux sont intéressants mais les PlayBooks sont la véritable force d’Ansible.

III. Préparer les hôtes Windows

Sur les hôtes Windows qui vont être domptés par Ansible, il est nécessaire de configuration la gestion à distance par WinRM. Pour cela, il faudra :

- Activer et configurer WinRM
- Autoriser WinRM dans le Pare-feu

A. Configurer WinRM pour Ansible

Pour configurer WinRM sur votre serveur afin de permettre la connexion depuis Ansible, deux solutions :

- Effectuer une configuration manuelle
- Utiliser le script d’auto-configuration fournit sur le site Ansible

Pour le premier cas, appuyez-vous sur notre tutoriel sur la configuration de WinRM, et veillez à activer l’authentification basique. Comme je suis sympa avec vous, voici les commandes pour l’authentification basique (à exécuter dans une console PowerShell) :

winrm set winrm/config/client/auth '@{Basic="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'

Dans le second cas, utilisez un script PS1 (PowerShell) fournit directement par la communauté Ansible afin de configurer WinRM :

Configure Windows 2008R2/2012/2012R2 for SSL-based remoting

Exécutez ce script sur chacun de vos serveurs hôtes.

Si nécessaire, modifiez la politique d’exécution de script :

Set-ExecutionPolicy Unrestricted

Pour WinRM c’est OK, il reste la règle dans le pare-feu de Windows à créer.

B. Autoriser WinRM dans le pare-feu Windows

Pour le pare-feu Windows, nous allons autoriser le port 5986 TCP. Vous devez appliquer la règle sur un profil du Pare-feu, en général dans un environnement d’entreprise, les serveurs seront dans un domaine et donc la règle devra être créée sur le profil « Domain ».

Sinon, utilisez « Any » pour tous les profils ou encore « Public » pour le profil public.

Note : Si vous utilisez un logiciel anti-virus spécifique sur votre serveur, il se peut qu’il joue le rôle de pare-feu, à la place du pare-feu intégré à Windows. De ce fait, il faudra créer une règle directement dans cette application.

Voici la commande qui permet de créer la règle :

netsh advfirewall firewall add rule Profile=Domain name="Autoriser WinRM HTTPS" dir=in localport=5986 protocol=TCP action=allow

La commande retourne un simple « Ok » :

WinRM configuré, WinRM autorisé dans le pare-feu, du côté des hôtes Windows c’est terminé pour le moment. Passons à la configuration d’Ansible.

IV. Installer Ansible sous Debian 8

Ouvrez un terminal sur votre Linux, Debian Jessie pour ma part, et commencez par installez python-pip qui va être utile pour installer Ansible et pywinrm.

pywinrm : Librairie Python pour utiliser WinRM.

Saisissez les trois commandes ci-dessous pour installer python-pip, puis à l’aide de pip installer ansible et pywinrm.

apt-get install python-pip
pip install ansible
pip install http://github.com/diyan/pywinrm/archive/master.zip#egg=pywinrm

Ansible est désormais installé, bravo ! Passons maintenant à la création du fichier hosts.

V. Fichier hosts : Ajout des clients Windows

Le fichier hosts est utilisé pour définir l’ensemble des groupes d’hosts que vous souhaitez administrer. Dans le répertoire « /etc/ansible », créez ce fichier et éditez-le avec un éditeur.

nano /etc/ansible/hosts

Note : Si vous désirez changer le nom du fichier hosts, cela doit se modifier dans le fichier de configuration ansible.cfg, avec la directive hostfile.

On commence par définir un groupe d’hôtes, pour cela on doit indiquer un nom de groupe entre crochets, comme ceci :

[windows]

Ensuite, nous allons renseigner nos deux hôtes Windows au sein de ce groupe, ce qui donnera l’ensemble suivant :

[windows]
# Domain Controller – 192.168.1.204
SRV-AD01.it-connect.fr
# Server – 192.168.1.201
SRV01.it-connect.fr

Les lignes qui commencent par # sont des lignes commentées. Il faut savoir également que les lignes vides sont ignorées.

Enregistrez et fermez le fichier, nos hôtes clients sont désormais référencés dans Ansible.

VI. Créer un fichier chiffré avec ansible-vault

Avec Ansible, chaque groupe du fichier hosts doit avoir un fichier YML correspondant. Ce fichier permet de définir un ensemble de paramètres utiles pour se connecter sur ces hôtes. De ce fait, il contient un mot de passe connexion… Ce n’est pas très sécurisé de créer ce fichier YML en clair sur notre serveur.

Les développeurs d’Ansible l’ont bien compris, il est possible de chiffrer le fichier YML. C’est ce que nous allons faire pour le fichier correspondant à notre groupe « windows ».

Ces fichiers YML liés aux groupes sont stockés dans le répertoire « /etc/ansible/group_vars/ », que vous devez créer s’il n’est pas présent :

root@JESSIE-01:~# cd /etc/ansible/
root@JESSIE-01:/etc/ansible# mkdir group_vars
root@JESSIE-01:/etc/ansible# cd group_vars/

Pour créer un fichier YML chiffré, nous allons utiliser la commande « ansible-vault ». Avant de créer ce fichier, un réglage système doit être effectué.

A. La variable EDITOR

Pour éditer ce fichier il faut un éditeur de texte tel que Vim, pour récupérer le chemin vers le binaire de votre éditeur Ansible s’appuie sur la variable d’environnement « EDITOR ». Il se peut que cette variable soit déjà configurée sur votre machine, dans ce cas vous devriez obtenir un retour en affichant son contenu :

echo $EDITOR

Si vous obtenez un retour vide, votre variable est vide. Nous allons éditer le fichier « /root/.bashrc » pour remplir automatiquement le contenu de cette variable au redémarrage du système :

export EDITOR='/usr/bin/vim'

Il semblerait que Vim soit nécessaire car avec Nano cela ne fonctionne pas. Si besoin de l’installer :

apt-get install vim

Si vous ne réalisez pas cette étape et que cette variable d'environnement est vide, cela générera l'erreur suivante dans Ansible :

ERROR: [Errno 2] No such file or directory

B. Création du fichier YML chiffré

La commande « ansible-vault » associée à l’option « create » permet de créer un nouveau fichier YML chiffré. Le nom du fichier doit correspondre au groupe d’hosts auquel il doit s’appliquer.

Par exemple, notre groupe d’hosts « windows » doit avoir un fichier YML nommé « windows.yml ».

root@JESSIE-01:/etc/ansible/group_vars# ansible-vault create windows.yml
Vault password:
Confirm Vault password:

Au niveau du contenu de ce fichier de configuration, on indiquera quatre directives :

ansible_ssh_user: Administrateur
ansible_ssh_pass:
ansible_ssh_port: 5986
ansible_connection: winrm

Ces directives correspondent respectivement à l’utilisateur de connexion, son mot de passe, le port d’accès et le mode de connexion. Vous remarquerez que ces directives contiennent l’expression « ssh » malgré que ce soit pour WinRM dans ce cas précis.

Note : Le port 5986 est le port utilisé par WinRM pour les connexions HTTPS

Sauvegardez votre fichier.

Note : Par défaut, le fichier sera chiffré en AES 256 bits. Vous pourrez vérifier que son contenu est correctement chiffré en tentant de le lire.

Pour éditer un fichier de configuration existant, on utilisera l'option edit à la place de create :

root@JESSIE-01:/etc/ansible/group_vars# ansible-vault edit windows.yml

La commande ci-dessus permet d’éditer un fichier YML à tout moment afin de revenir sur une configuration.

VII. Correction du bug « send_message() crashes with https »

A l’heure actuelle, une erreur de développement est présente au sein winrm.py, un fichier Python utilisé par Ansible. Pour corriger ce bug, il faut éditer le fichier suivant :

lib/ansible/runner/connection_plugins/winrm.py

Modifiez la ligne :

err_msg = str(exc.args[0])

Par la correction suivante :

err_msg = str(exc)

Retrouvez le ticket du Bugfix sur le GitHub d’Ansible (#8720).

Cette erreur se produit lorsque l’on tente une communication entre Ansible et un hôte Windows par WinRM (chose que nous n’avons pas encore effectuée).

VIII. Tester la communication avec « win_ping »

Le module « win_ping » est intégré au core d’Ansible, il permet de tester la communication entre l’hôte Ansible et les hôtes d’un groupe Windows. Il n’effectue pas un ping ICMP, mais test le canal de communication entre les deux parties.

De ce fait, nous allons utiliser ce module pour tester la communication entre Ansible, et les deux hôtes sous Windows Server 2012 R2. Exécutez la commande suivante :

ansible windows –m win_ping --ask-vault-pass

On indique « windows » car il s’agit du nom que l’on a donné à notre groupe (dans le fichier hosts), Ansible cherchera automatiquement le fichier windows.yml. L’option « --ask-vault-pass » est nécessaire pour que l’on soit invité à saisir le mot de passe de protection du fichier.

Vous l’aurez surement compris, l’option « -m » permet d’indiquer le nom du module à charger.

La sortie doit ressembler à ceci :

SRV01.it-connect.fr | success >> {
"changed": false,
"ping": "pong"
}
SRV-AD01.it-connect.fr | success >> {
"changed": false,
"ping": "pong"
}

Ansible arrive à communiquer avec vos serveurs Windows, via WinRM ! Si l’on veut aller plus loin dans cette initialisation, on peut même utiliser le module « setup », comme ceci :

ansible windows –m setup --ask-vault-pass

Le module setup : présent dans le core d’Ansible, il permet d’obtenir des informations basiques sur les machines cibles. Certains PlayBooks l’utilisent car les informations qu’ils récupèrent sont intéressantes pour bien identifier une machine.

On obtiendra des informations comme la version précise de Windows, le nom FQDN de la machine, le nom de l’hôte, ou encore la famille de l’OS.

Dans ce cas précis, voici la sortie que j’obtiens avec le module setup :

SRV01.it-connect.fr | success >> {
    "ansible_facts": {
        "ansible_distribution": "Microsoft Windows NT 6.3.9600.0",
        "ansible_distribution_version": "6.3.9600.0",
        "ansible_fqdn": "SRV01.it-connect.fr",
        "ansible_hostname": "SRV01",
        "ansible_ip_addresses": [
            "192.168.1.201"
        ],
        "ansible_os_family": "Windows",
        "ansible_system": "Win32NT",
        "ansible_totalmem": "System.Object[]"
    },
    "changed": false
}

SRV-AD01.it-connect.fr | success >> {
    "ansible_facts": {
        "ansible_distribution": "Microsoft Windows NT 6.3.9600.0",
        "ansible_distribution_version": "6.3.9600.0",
        "ansible_fqdn": "SRV-AD01.it-connect.fr",
        "ansible_hostname": "SRV-AD01",
        "ansible_ip_addresses": [
            "192.168.1.204",
            "fe80::7960:1749:bbc3:8703"
        ],
        "ansible_os_family": "Windows",
        "ansible_system": "Win32NT",
        "ansible_totalmem": "System.Object[]"
    },
    "changed": false
}

IX. PlayBook : Exécuter un script PowerShell

Pour terminer, nous allons créer notre premier PlayBook et l’utiliser par la suite. L’objectif sera de créer un PlayBook qui exécute un script PowerShell sur les hôtes Windows.

Dans le cas de cet exemple, nous ferons très simple, le script va démarrer le service Windows Update sur l’ensemble des serveurs.

- Créer le répertoire « files »

Commençons par créer un répertoire nommé « files » qui servira à stocker les fichiers annexes, comme le fichier PowerShell (.ps1), par exemple.

root@JESSIE-01:~# cd /etc/ansible/
root@JESSIE-01:/etc/ansible# mkdir files
root@JESSIE-01:/etc/ansible# cd files/

- Créer le script PowerShell

Dans le répertoire « /etc/ansible/files », créez un fichier PowerShell nommé « script1.ps1 » et ajoutez ce contenu :

Start-Service -Name wuauserv

Il s’agit d’une commande PowerShell qui permet de démarrer un service, en l’occurrence le service Windows Update nommé « wuauserv ».

- Créer le PlayBook

Pour la création du PlayBook, créez-le dans le répertoire « /etc/ansible ». Pour ma part, je le nomme « service-wu.yml » - indiquez bien cette extension correspondante aux fichiers YAML.

Note : Si vous le souhaitez, vous pouvez chiffrer également vos fichiers de PlayBook avec ansible-vault.

Au niveau du contenu, voici ce que vous devez indiquer dans ce fichier :

- name: "Run powershell script"
  hosts: "windows"
  gather_facts: "false"
  tasks:
    - name: "Start Windows Update"
      script: "files/script1.ps1"

Note : Les espaces au début de ligne sont très importants. Sans cette indentation, le PlayBook ne fonctionnera pas et retournera une ou plusieurs erreur(s) de syntaxe.

On indique un nom général pour le PlayBook par l’attribut « name » et on précise qu’il s’applique aux hôtes du groupe nommé « windows ».

Le fait de mettre l’attribut « gather_facts » sur false, permet d’indiquer explicitement que l’on ne souhaite pas effectuer une collecte d’informations initiales auprès des machines cibles.

Nous définissions notre tâche, qui est unique dans le cas de ce PlayBook, mais il peut y avoir des PlayBooks multitâches et nettement plus complexe. Pour cela, on indique « tasks: ».

Après avoir nommée cette tâche avec l’attribut « name » (attention à l’indentation), on utilise l’attribut « script » pour indiquer le chemin vers notre script PowerShell.

- Exécution du PlayBook

Tout est prêt, nous allons pouvoir exécuter ce fameux PlayBook « service-wu.yml » ! Au sein de la ligne de commande Linux, exécutez ceci :

ansible-playbook service-wu.yml --ask-vault-pass

Vous remarquerez que l’on utilise la commande « ansible-playbook » comme il est question d’exécuter un PlayBook. On précisera une nouvelle fois « --ask-vault-pass » pour que l’on nous demande le mot de passe nécessaire au déchiffrement du fichier .yml de configuration des hôtes Windows (windows.yml).

Voici le retour que vous devez optionnel (si tout se déroule correctement) :

On remarque que la sortie est organisée en trois zones principales :

- PLAY [Run powershell script] : On indique que l’on commence le PLAY nommé « Run powershell script », ce qui correspond au nom que nous avons indiqué dans le fichier YAML.

- TASK: [Start Windows Update] : On indique que l’on entre dans l’exécution de la tâche nommée « Start Windows Update », et pour chaque hôte on indique un résultat.

- PLAY RECAP : Récapitulatif au niveau des actions effectuées, avec l’état pour chaque hôte. Il s’agit d’un résumé global pour l’ensemble du PlayBook.

Ce tutoriel est désormais terminé, j'espère que vous trouverez un intérêt à utiliser Ansible pour l'automatisation de tâches sur des serveurs Windows. Si vous avez des questions, vous pouvez venir en discuter dans notre forum directement.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio