Introduction à Ansible

By | 31 octobre 2014

ansible_wordlogo_blackDans cet article, je vais vous présenter un outil qui m’accompagne depuis quelques semaines pour mes tâches d’administration de serveurs, il s’agit d’Ansible.

Je ne suis pas sysAdmin, mais, j’ai par la force des choses pas loin d’une quarantaine de serveurs à administrer aujourd’hui. Et le moins que l’on puisse dire, c’est que maintenir à jour des serveurs sans outil consomme beaucoup de temps et d’énergie, même pour des actions simples. Ce qui m’a amené à m’intéresser à Ansible.

Ansible est un outil d’automatisation capable de gérer la configuration de serveurs, déployer des applications et d’effectuer des actions sur un ensemble de serveurs via une unique commande, tout ça sans nécessité l’installation d’agent sur les serveurs à administrer.

Installation

Pour l’installation, j’ai fait le choix d’utiliser pip, le gestionnaire de paquets python:

$ apt-get install python-pip python-dev sshpass
$ pip install ansible
$ ansible --version
ansible 1.7.2

Comme je l’ai précisé précédemment, les serveurs administrés par Ansible n’ont besoin d’aucune configuration particulière. Ansible communique avec les serveurs en utilisant le protocol ssh. Nous en avons donc fini avec l’installation.

La dernière chose que je fais lors de l’installation d’ansible, c’est désactiver la vérification des hosts.

$ mkdir /etc/ansible/
$ vim /etc/ansible/ansible.cfg
# Ansible configuration
[defaults]
host_key_checking = False

Inventaire

Une fois ansible installé, la seconde chose à faire est de définir l’inventaire de nos serveurs. Il s’agit tout simplement d’un fichier au format ini, dans lequel nous allons lister les serveurs que nous souhaitons administrer, et les informations nécessaire pour y accéder.

# /etc/ansible/hosts
[blogpostservers]
vm_ansible_1 ansible_ssh_host=192.168.56.210 ansible_ssh_user=root
vm_ansible_2 ansible_ssh_host=192.168.56.211 ansible_ssh_user=root

Dans l’exemple ci-dessus, j’ai défini 2 serveurs (vm_ansible_{1,2}). La section (blogpostservers) correspond au groupe auquel va appartenir ces serveurs. Les variables qui suivent le nom du serveur, vont permettre d’indiquer à ansible comment les atteindre. Il existe une dizaine de variables disponibles (user, host, port, pass, sudo …). Dans l’exemple, n’ayant pas défini de mot de passe, ansible tentera d’atteindre les serveurs en utilisant une clé ssh.

Exécuter des commandes

Après avoir générer un trousseau de clé pour ansible, et avoir déployé la clé publique sur les serveurs de l’inventaire, nous allons pouvoir exécuter notre première commande via ansible.

$ ansible * -m ping
vm_ansible_1 | success >> {
"changed": false,
"ping": "pong"
}

vm_ansible_2 | success >> {
"changed": false,
"ping": "pong"
}

La commande est assez simple à comprendre. L’étoile (*) correspond au pattern utilisé pour sélectionner les serveurs, et la seconde partie (-m ping) indique que nous souhaitons utiliser le module ping. Il existe dans ansible plusieurs centaines de modules que je vous laisse découvrir.

Voici un second exemple utilisant le module file, qui va créer un fichier sur nos serveurs:

$ ansible * -m file -a "dest=/tmp/from_ansible state=touch"

Dans ce dernier exemple, nous allons installer htop en utilisant le module apt:

$ ansible * -m apt -a "name=htop state=present"

pattern

Le pattern, comme je l’ai expliqué ci-dessus, nous permet de sélectionner les serveurs pour l’exécution de la commande. Ce pattern va s’appliquer non seulement sur le nom des serveurs, mais aussi les groupes.

Voici quelques autres pattern que nous aurions pu utiliser pour atteindre ces mêmes serveurs:

$ ansible * -m ping
$ ansible blogpostservers -m ping
$ ansible vm_ansible_* -m ping
$ ansible vm_ansible_1:vm_ansible_2 -m ping

Playbooks

Nous allons maintenant faire un tour sur la partie la plus intéressante d’ansible, les playbooks. Si vous connaissez chef, les playbooks sont l’équivalent des cookbooks. Si vous n’avez jamais entendu parlé de {cook,play}books, il s’agit de la mise en place de scénarios pour gérer la configuration de serveurs ou le déploiement d’applications.

Les playbooks s’écrivent en Yaml, et contiennent les différentes tâches à exécutés sur chacun de nos serveurs.

Exemple

Nous allons voir un exemple qui se veut le plus simple possible. Nous allons écrire un playbook permettant de s’assurer que php-fpm et NGinx soient installés sur nos serveurs. Nous écrirons notre playbook dans un unique fichier (~/lemp.yml) afin de faciliter  sa compréhension.

La première chose à faire est de définir les serveurs concernés par le playbook et l’utilisateur à utiliser pour exécuter les tâches:

---
- hosts: *
  remote_user: root

Dans la seconde partie nous allons définir les tâches à exécuter:

  tasks:
  - name: mise à jour des paquets debian 
    apt: update_cache=yes
  - name: installation de php-fpm 
    apt: name=php5-fpm state=present
  - name: installation de nginx
    apt: name=nginx state=present

Une tâche est identifiée par le champ name qui sera affiché lors de l’exécution du playbook, et apt le module à utiliser avec ses options.

Voilà, nous avons écrit notre premier playbook, il ne s’agit que d’une série de tâches à jouer, il ne reste plus qu’à l’exécuter:

$ ansible-playbook lemp.yml

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [vm_ansible_1]
ok: [vm_ansible_2]

TASK: [mise à jour des paquets debian] ****************************************
ok: [vm_ansible_1]
ok: [vm_ansible_2]

TASK: [installation de php-fpm] ***********************************************
changed: [vm_ansible_2]
changed: [vm_ansible_1]

TASK: [installation de nginx] *************************************************
changed: [vm_ansible_2]
changed: [vm_ansible_1]

PLAY RECAP ********************************************************************
vm_ansible_1               : ok=4    changed=2    unreachable=0    failed=0
vm_ansible_2               : ok=4    changed=2    unreachable=0    failed=0

Vous constaterez que l’état des tâches de NGinx et php-fpm sont en changed. Si nous rejouons ce même playbook, ansible nous informera via le statut ok que NGinx et php-fpm sont déjà présents sur les serveurs.

Ce playbook est volontairement simpliste, l’objectif était de vous en présenter sa structure. Je présenterai dans un prochain article comment mettre en place des playbooks plus complet intégrant les notions de rôles, les conditions (apt / yum suivant l’os), les templates de configurations de services …

Conclusion

Nous venons de voir comment installer et faire nos premiers pas avec Ansible. Nous avons rapidement survolé la notion de playbook, dans un prochain article nous irons plus loin sur la manière de les écrire, mais pour le moment rien ne vous empêche de commencer à utiliser Ansible pour les tâches d’administration récurrentes (comme vider le swap sur les serveurs … 😉 ).