Tutoriel Ansible pour les débutants sous Linux

Un administrateur système, dans la grande majorité des cas, doit s’occuper de plus d’un serveur, il doit donc souvent effectuer des tâches répétitives sur chacun d’entre eux. Dans ces cas, l’automatisation est indispensable. Ansible est un logiciel open source appartenant à Red Hat ; il est écrit dans le langage de programmation Python, et c’est un logiciel de gestion de provisionnement et de configuration qui nous aide dans les cas susmentionnés. Dans ce tutoriel, nous allons voir comment l’installer et les concepts de base derrière son utilisation.

Dans ce tutoriel, vous allez apprendre :

Comment installer Ansible sur les distributions Linux les plus utilisées
Comment configurer Ansible
Qu’est-ce que l’inventaire Ansible ?
Quels sont les modules Ansible ?
Comment exécuter un module à partir de la ligne de commande
Comment créer et exécuter un playbook

Configuration logicielle requise et conventions utilisées

Installation d’Ansible

Le package Ansible est contenu dans les dépôts officiels des distributions Linux les plus utilisées, il peut donc être facilement installé à l’aide de leurs gestionnaires de packages natifs. Pour l’installer sur Debian, nous pouvons exécuter :

sudo apt-get update && apt-get install ansible

Pour installer Ansible sur Fedora, procédez plutôt comme suit :

sudo dnf install ansible

Ansible se trouve dans le dépôt « Community » d’Archlinux ; Nous pouvons l’installer à l’aide de Pacman :

sudo pacman -Sy ansible

Si nous voulons installer Ansible sur CentOS8, nous devons ajouter la source logicielle epel-release à notre système, car le paquet n’est pas disponible dans les dépôts par défaut. Pour ce faire, nous exécutons la commande suivante :

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

Après cela, nous pouvons simplement exécuter :

sudo dnf install ansible

Pour d’autres instructions d’installation spécifiques à la distribution, nous pouvons consulter la page dédiée
de la documentation officielle d’Ansible.

Présentation d’Ansible

La particularité fondamentale d’Ansible est qu’il s’agit d’un système de provisionnement sans agent. Cela signifie que nous n’avons pas besoin d’installer d’agent ou de démon logiciel sur les serveurs que nous voulons contrôler. Tout ce dont nous avons besoin est d’installer et de configurer Ansible sur la machine de contrôle. Les tâches que nous configurons seront effectuées, dans la grande majorité des cas, via une simple connexion ssh.

Le fichier de configuration d’Ansible

Ansible peut être configuré en spécifiant des paramètres et leurs valeurs dans un ou plusieurs fichiers de configuration. L’application, par ordre de priorité, recherche les fichiers suivants :

Le fichier spécifié via la variable ANSIBLE_CONFIG
Le fichier ansible.cfg dans le répertoire de travail actuel
Le fichier .ansible.cfg dans le répertoire personnel de l’utilisateur
Le fichier /etc/ansible/ansible.cfg

Le fichier /etc/ansible/ansible.cfg est le dernier, il est donc utilisé comme solution de secours et par défaut. Pour des raisons évidentes, ce n’est pas l’endroit approprié pour décrire tous les paramètres possibles qui peuvent être spécifiés dans un fichier de configuration, cependant, voici un extrait du contenu du fichier :

[defaults]

some basic default values...

#inventory      = /etc/ansible/hosts
#library        = /usr/share/my_modules/
#module_utils   = /usr/share/my_module_utils/
#remote_tmp     = ~/.ansible/tmp
#local_tmp      = ~/.ansible/tmp
#plugin_filters_cfg = /etc/ansible/plugin_filters.yml
#forks          = 5
#poll_interval  = 15
#sudo_user      = root
#ask_sudo_pass = True
#ask_pass      = True
#transport      = smart
#remote_port    = 22
#module_lang    = C
#module_set_locale = False

Ceux de l’exemple sont des paramètres commentés qui sont définis avec leurs valeurs par défaut. Parmi eux, vous pouvez voir les paramètres d’inventaire, qui a la valeur /etc/ansible/hosts. Nous verrons ce que c’est dans la section suivante.

Le fichier « hosts » ou « inventory »

Le fichier « hosts » d’Ansible, c’est là que l’on définit essentiellement l’adresse IP ou les noms d’hôtes des machines que l’on souhaite contrôler avec Ansible (c’est l'"inventaire » dans le jargon d’Ansible). Sur une installation standard, le fichier se trouve dans le répertoire /etc/ansible. À l’intérieur du fichier d’inventaire, les hôtes peuvent être groupés ou dissociés. Nous pouvons spécifier un hôte par lui-même, par exemple :

server1

Cependant, lorsque l’on veut effectuer des opérations sur plus d’un hôte, il est très utile de mettre les hôtes dans des groupes, créés, par exemple, en utilisant leur « rôle » comme critère. En supposant que les hébergeurs auxquels nous avons affaire soient tous utilisés comme serveurs web, nous pourrions écrire :

[webservers]
server1
server2

Modules Ansible

Les modules Ansible sont essentiellement de petits programmes utilisés pour effectuer les tâches dont nous avons besoin ; Chacun d’entre eux est conçu pour effectuer une seule opération de base, afin d’assurer la granularité. Ils peuvent être exécutés à partir de la ligne de commande ou dans des playbooks. La liste complète de tous les modules se trouve sur la page dédiée de la documentation officielle. Encore une fois, nous ne pouvons pas examiner tous les modules ici, mais en voici quelques exemples.

Les modules apt, dnf et yum sont utilisés pour gérer les paquets avec les gestionnaires de fichiers dont ils tirent leur nom
. Le module seboolean est utilisé pour gérer l’état des booléens SELinux, le module utilisateur est utilisé pour gérer les comptes utilisateurs, etc.

Utilisation de modules à partir de la ligne de commande

Comme nous l’avons dit dans la section précédente, les modules peuvent être utilisés à partir de la ligne de commande ou des playbooks. Nous nous concentrerons sur ce dernier dans la section suivante ; Ici, nous allons montrer comment utiliser un module à partir de la ligne de commande, avec la commande Ansible. Dans cet exemple, nous allons utiliser le module ping. Ce module n’a rien à voir avec la commande ping, mais il sert à vérifier que l’on peut se connecter sur les serveurs distants, et qu’un interpréteur Python est installé sur ceux-ci. Le module renvoie la valeur « pong » en cas de succès :

ansible webservers -m ping --ask-pass

Nous avons invoqué la commande ansible en spécifiant que nous voulons exécuter la tâche sur les hôtes membres du groupe « webservers » et avec l’option -m nous avons passé le nom du module que nous voulons utiliser. Nous avons également utilisé l’option --ask-pass, pourquoi ? Bien que j’aie précédemment ajouté l’empreinte digitale des serveurs distants au fichier ssh « hôtes connus » de la machine de contrôle, je n’ai pas configuré l’accès ssh via la clé publique, donc un mot de passe ssh doit être fourni lorsque nous exécutons une tâche. L’option --ask-pass permet de demander le mot de passe de manière interactive. Voici le résultat de la commande
ci-dessus :

SSH password:
server2 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
server1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

Playbooks Ansible

Qu’est-ce qu’un playbook ? Les playbooks Ansible ne sont autres que des fichiers YAML dans lesquels nous spécifions les tâches que nous voulons effectuer à l’aide d’Ansible et les hôtes sur lesquels elles doivent être effectuées. Voyons un exemple de playbook. Dans le fichier suivant, nous configurons une tâche pour nous assurer que l’éditeur de texte Vim est installé et qu’il dispose de la dernière version disponible :

---

- name: Update webservers
  hosts: webservers
  remote_user: egdoc
  become: yes

  tasks:
    - name: Ensure Vim is installed and at the latest version
      dnf:
        name: vim
        state: latest

...

Analysons ce qui précède. Les --- et ... que l’on peut voir, respectivement au début et à la fin du fichier, font partie de la syntaxe YAML standard : ils sont facultatifs et marquent le début et la fin du fichier. Les instructions et leurs valeurs sont représentées dans un format de dictionnaire, sous forme de paires clé :valeur.

Un playbook peut contenir plusieurs ce que l’on appelle des jeux ; Dans ce cas, nous n’en avons défini qu’un. En effet la première chose que nous avons faite a été de préciser son nom, qui dans cet exemple est « Mettre à jour les serveurs web ». La deuxième clé que nous avons utilisée est celle des hôtes : avec elle, nous pouvons définir le groupe d’hôtes sur lequel les tâches doivent être effectuées. Dans ce cas, nous avons spécifié webservers comme valeur, ce qui comprend les machines que nous avons définies dans les exemples précédents (serveur1 et serveur2).

La touche suivante que nous avons utilisée était remote_user. Avec lui, nous pouvons spécifier quel est l’utilisateur avec lequel nous devons nous connecter, via ssh, dans les serveurs distants. Après cela, nous avons utilisé la clé devenir. Cette clé accepte une valeur booléenne et avec elle, nous spécifions si l’élévation de privilèges
doit être utilisée pour effectuer les tâches ou non. Dans ce cas, puisque nous nous connectons aux machines distantes en utilisant l’utilisateur « egdoc », et que nous avons besoin des privilèges root pour installer un paquet, nous le définissons à yes. Il est important de noter
que l’élévation de privilèges est configurée dans le fichier de configuration /etc/ansible/ansible.cfg, dans la section dédiée. Dans ce cas, les valeurs par défaut sont les suivantes :

[privilege_escalation]
#become=True
#become_method=sudo
#become_user=root
#become_ask_pass=False

Après avoir défini les informations de jeu, nous avons commencé à spécifier notre liste de tâches. Pour ce faire, nous avons utilisé le mot-clé tasks. Chaque tâche a un nom qui est utilisé pour la documentation et dans les gestionnaires de tâches.

Avec dnf : nous avons spécifié que nous voulons utiliser le module « dnf », qui, comme nous l’avons vu précédemment, est utilisé pour gérer les paquets en utilisant le gestionnaire de paquets par défaut dans la famille de distributions Red Hat. À l’intérieur de cette section, avec le nom mot-clé
nous avons spécifié le nom du package. Dans cet exemple, nous ne nous intéressons qu’à un seul package, mais plusieurs packages peuvent être spécifiés à l’aide d’une liste. Par exemple:

dnf:
    name: [vim, nano]

Avec le mot-clé state du module dnf, nous spécifions essentiellement ce que nous voulons faire avec le(s) paquet(s) spécifié(s). Dans ce cas, nous avons utilisé latest comme valeur : avec elle, nous nous assurons que le paquet est installé et à la dernière version disponible sur la distribution utilisée sur la machine distante. D’autres valeurs possibles que nous pouvons utiliser sont remove ou absent, ce qui entraîne la désinstallation du ou des paquets, ou present qui garantit simplement que le paquet est installé. Je vous recommande de consulter la documentation officielle du module pour obtenir la liste complète des clés et des valeurs qui peuvent être utilisées avec le module.

Voilà, nous venons de définir notre premier playbook. Comment pouvons-nous le faire fonctionner ?

Exécution d’un playbook

Pour exécuter un playbook, nous utilisons la commande ansible-playbook dédiée. La commande accepte une série d’options et prend un ou plusieurs fichiers de playbook comme arguments. Pour exécuter le playbook que nous avons défini dans la section précédente, par exemple, nous devons exécuter la commande suivante :

ansible-playbook --ask-pass ---ask-become-pass  /path/to/playbook.yml

Vous pouvez remarquer que dans ce cas, nous avons appelé la commande avec les options --ask-become-pass. Cette option est nécessaire car dans le fichier du playbook, nous avons attribué la valeur yes à la clé devenir, car nous avons besoin d’une élévation de privilèges pour installer des packages sur les machines distantes. L’option --ask-become-pass fait en sorte que le mot de passe sudo est demandé lorsque nous exécutons le playbook. Dans ce cas, puisque nous avons également utilisé --ask-pass, le mot de passe SSH sera utilisé comme mot de passe par défaut pour l’élévation de privilèges. Voici le résultat que nous recevons lorsque nous exécutons le playbook :

SSH password:
BECOME password[defaults to SSH password]:

PLAY [Update webservers] *******************************************************************************************************************************************

TASK [Gathering Facts] *********************************************************************************************************************************************
ok: [server1]
ok: [server2]

TASK [Ensure Vim is installed at the latest version] ***************************************************************************************************************
changed: [server1]
changed: [server2]

PLAY RECAP *********************************************************************************************************************************************************
server1                    : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
server2                    : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

On nous demande d’abord de fournir le mot de passe « SSH », puis le mot de passe « BECOME ». Comme nous l’avons déjà dit, le mot de passe SSH sera utilisé comme valeur par défaut dans ce cas. Comme vous pouvez le voir avant la tâche que nous avons spécifiée dans le playbook, une autre tâche est exécutée : « Collecte des faits ». Cette tâche est exécutée par défaut afin de collecter des variables utiles sur les hôtes distants qui peuvent être utilisées dans les playbooks.

Une fois les tâches exécutées, nous obtenons un récapitulatif de la ou des pièces que nous avons spécifiées. Dans ce cas, nous pouvons voir que deux tâches ont été exécutées correctement (ok=2) et qu’une tâche a provoqué un changement (changed=1). C’est logique : le changement a eu lieu depuis l’installation du paquet vim.

Maintenant, si nous essayons d’exécuter à nouveau le playbook, nous pouvons voir qu’aucun changement ne se produit, puisque vim est déjà installé et à la dernière version disponible :

PLAY RECAP *********************************************************************************************************************************************************
server1                    : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
server2                    : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Conclusions

Dans ce tutoriel, nous avons appris ce qu’est Ansible et quelles sont ses particularités. Nous avons vu comment l’installer sur certaines des distributions Linux les plus utilisées, comment le configurer et quelques concepts de base : qu’est-ce qu’un inventaire et quels sont les modules Ansible
. Nous avons également vu comment exécuter un module à partir de la ligne de commande et comment écrire et exécuter un playbook. Il s’agissait simplement d’une introduction au monde d’Ansible ; Mettez les mains dans le cambouis, expérimentez et lisez la documentation officielle pour une connaissance plus approfondie !