Ansible s'installe sur sa machine à soi (pas sur un serveur), afin d'administrer ses serveurs en automatisant pleins de choses. C'est censé simplifier le boulot du sysadmin¹⁾.

Donc, suivant votre système :

sudo apt-get install ansible
yaourt -S ansible
dnf install ansible
...

Le fichier de configuration se trouve dans /etc/ansible/ansible.cfg ; il est en principe fonctionnel tel quel.

Ensuite on va renseigner ses serveurs.

Par défaut, Ansible les cherche dans /etc/ansible/hosts (à créer et paramétrer). Mais on peut créer le fichier du nom qu'on veut à l'emplacement qu'on veut ; il suffira soit de le renseigner dans /etc/ansible/ansible.cfg probablement en renseignant la variable inventory = /chemin/fichier, soit de lancer Ansible avec la variable -i en indiquant le chemin.

ansible -i /chemin/fichier

Créer un ou des fichiers ailleurs a deux avantages :

• cela permet de séparer suivant les infrastructures, par exemple un fichier pour les serveurs en production, un autre pour les serveurs en pré-production ;
• cela permet de renseigner son fichier hosts sans avoir besoin des droits root, par exemple en le mettant dans /home/ansible/khanat_hosts.

Il y a visiblement plusieurs syntaxes possibles (peut-être à paramétrer dans /etc/ansible/ansible.cfg ?), on va rester au truc par défaut qui est la syntaxe de type INI, c'est à dire avec des crochets pour les sections, dans ce genre-là :

mail.example.com
 
[webservers]
foo.example.com
bar.example.com
 
[dbservers]
one.example.com
two.example.com
three.example.com

Ce qui est entre crochets est le nom donné à un groupe et ce nom est libre, mais il ne doit pas reprendre un nom des serveurs gérés dessous. Ici par exemple, il y a un groupe de serveurs qui concerne le web, un autre groupe avec les machines hébergeant les bases de données ; les noms ont été choisis pour être parlants.

Les serveurs renseignés dessous peuvent l'être suivant diverses syntaxes :

• d'après le nom de domaine qui leur est lié (par exemple foo.example.com)
• d'après leur ip (par exemple 9.9.9.9)
• d'après leur raccourci renseigné dans .ssh/config (le plus pratique car cela précise le port, l'utilisateur…)

L'une des grandes forces d'Ansible va être d'automatiser des opérations qu'on répète sur plusieurs serveurs ; dit autrement, Ansible permet (entre autres) de faire des opérations sur plusieurs serveurs et ce en parallèle.

Un exemple très bête : la mise à jour des dépôts, le téléchargement et déployement de nouveaux paquets. Le tout en gardant un œil quand même pour voir si tout se passe bien… Cette action est à faire régulièrement sur les serveurs : elle peut se scripter via Ansible.

La première manipulation de cet article permet d'envoyer une commande sur plusieurs serveurs (un ping dans l'exemple). Pour passer plusieurs commandes, on crée des “playbooks”. Ce sont des fichiers écrits au format YAML. À noter qu'Ansible a pour but de favoriser la lecture par des êtres humains : il y a donc beaucoup de façons d'écrire ces playbooks…

Créez un répertoire dans lequel seront stockés vos playbooks, puis un playbook :

mkdir ./ansible/playbooks
nano  ./ansible/playbooks/maj_base.yml

Pour exécuter le playbook :

ansible-playbook -i ./khanat_host ./ansible/playbooks/maj_base.yml

Mais avant de l'exécuter, il faut l'écrire…

Pour la rédaction des playbooks, les possibilités sont nombreuses et il vaut mieux se référerer à la documentation officielle. Pour les options de base :

1. Nous renseignons les hosts où le playbook sera lancé
2. Nous listons les tâches qui seront exécutées dessus

Il est possible de renseigner des variables et diverses options.

Chaque tâche (task) démarre par un tiret - après lequel on peut spécifier un ensemble d'options. On peut renseigner une variable “name”, qui nous indiquera, lors du lancement du playbook, à quel stade il en est. On peut faire appel au shell, ou même directement à un programme. On peut passer root via sudo, ou devenir un autre utilisateur (pour peu qu'on aie les droits), le temps d'une commande. On peut avoir des retours si un reboot est nécessaire, etc.

- name: Texte décrivant la tâche
  module: option=value

Commençons en douceur… on reproduit notre “ping” via le playbook.

khanatping.yml

# Indiquer sur quels serveurs ce playbook va marcher, ici ceux du groupe "khanat"
- hosts: khanat
#  Nous indiquons les tâches qui vont s'exécuter
  tasks:
    - action: ping

Lors de l'exécution de ansible-playbook -i ./khanat_host ./ansible/playbooks/khanatping.yml, la réponse est affichée différemment de la commande ansible -i ./khanat_host -m ping khanat mais le résultat est le même : ça marche.

Allons un peu plus loin et créons un playbook pour mettre à jour un serveur Debian. La lecture des possibilités offerte par les modules apt sous ansible est utile.

Les mises à jour doivent se faire avec les droits root. Mais comme on respecte les règles de sécurité, on ne se connecte jamais directement en root mais via un utilisateur ayant le droit de devenir root via sudo. Et toujours pour des questions de sécurité, cet utilisateur doit taper son mot de passe pour devenir root. On ajoutera donc la commande –ask-become-pass en appelant le script. On va aussi ajouter dans le playbook de quoi passer en root quand nécessaire.

maj_base.yml

# Nos hôtes concernés par le playbook
- hosts: khanat
# On prévient que sur cet host et pour ce playbook, on va utiliser sudo.
  become: yes
  become_method: sudo
# On renseigne les tâches et on leur donne des descriptions
  tasks:
    - name: mise à jour des dépôts
      apt: update_cache=yes
 
    - name: Mettre à jour les paquets
      apt: upgrade=yes
 
    - name: Vérifie s'il faut rebooter
      register: reboot
      stat: path=/var/run/reboot-required get_md5=no

Puis lancer :

ansible-playbook -i ./khanat_host ./ansible/playbooks/maj_base.yml --ask-become-pass

Imbriquer les playbooks peut être utile. Par exemple, vous avez un playbook bien fait pour les mises à jour, mais vous souhaitez le lancer parfois pour un groupe de serveur, parfois pour un autre²⁾.

Il y a plusieurs façon de réaliser des imbrications, définir des rôles, inclure des tâches… Cette dernière façon de faire est assez simple.

Créez votre premier playbook contenant vos hosts, et appelez dedans un second playbook, qui contiendra la liste des tâches :

khanat.yml

- hosts: khanat
  tasks:
  - import_tasks: includeping.yml

includeping.yml

  - action: ping

• Ansible : mes premiers pas (memo-linux.com)
• Présentation d'Ansible et version 2 à venir (Linuxfr.org)
• https://www.abyssproject.net/2016/09/gerer-mises-a-jour-de-bsd-linux-windows-ansible/
• Utilisation avancée : piste pour utiliser des boucles, en français. Le détail dans la documentation officielle en anglais
• Galaxy : exemples de playbooks