Intro

Cet article a été initialement écrit sur le blog-libre aujourd’hui fermé, certains liens dans l’article peuvent donc être morts.

Ansible avec Docker sont les deux projets open source qui font le plus de buzz en ce moment. Vous allez très vite comprendre pourquoi. Je précise de suite que cette série d’articles s’adresse aux débutants qui ne sont pas nécessairement au courant de ce qui buzze dans le monde professionnel mais qui peuvent être très intéressés par des solutions que je qualifierai de Power-user.

Afin de faire économiser du temps aux lecteurs pressés, je leur signale qu’ils pourront trouver des exemples de l’utilisation d’Ansible dans les Sources en bas de la page. Le but de cette série d’articles est de présenter la solution mais également ses possibilités (son périmètre). Pour faire simple répondre aux questions : Qu’est-ce que je peux faire avec, c’est quoi et à quoi ça sert ?

Ansible est un outil de gestion de configuration écrit en Python et actuellement en version 1.7. Je prends grand soin de ne pas suivre le buzz général dès qu’un nouvel outil hype sort. Si je présente cet outil c’est parce qu’il est stable, simple d’accès, open source, libre (GPL v3), largement utilisé, très bien documenté (mais uniquement en Anglais…), activement développé (https://github.com/ansible/ansible), nécessite un prérequis logiciel minime et enfin vous trouverez de nombreux tutos et forums (encore essentiellement en Anglais) sur Internet.

Il est le concurrent direct des projets Puppet, Chef, Salt. Il se démarque principalement par l’absence de logiciels client à installer sur les postes cibles car sa force est qu’il nécessite uniquement une connexion SSH et Python 2.5 ou plus récent sur les clients. Vous l’aurez compris, ça fonctionne sur GNU/Linux et on peut piloter des postes/serveurs clients sous GNU/Linux et Unix (et bientôt Windows mais j’y reviendrai dans le futur).

Un outil de gestion de configuration (Configuration Management Tool) sert principalement à déployer des configurations à travers un parc informatique sous formes de fichiers et données (dixit Wikipedia). En Français maintenant, maintenir une cohérence au niveau de la configuration et de la maintenance de vos serveurs/postes. Je pense qu’il y a un sens à s’investir dans cet outil à partir de 3 serveurs/postes. Pour les personnes qui ne sont pas dans ce cas, vous pouvez reprendre votre activité habituelle.

Passons aux exemples toujours plus parlant.

Sans Ansible : On se connecte sur chaque poste (Debian évidemment) et on fait un aptitude update && aptitude safe-upgrade
Avec Ansible : On lance la commande ansible all -a « aptitude update && aptitude safe-upgrade » et cette commande est exécutée sur tous les postes avec un retour

Sans Ansible : On se connecte sur chaque poste et on fait un /sbin/reboot -t now
Avec Ansible : On lance la commande ansible all -a « /sbin/reboot -t now » et cette commande est exécutée sur tous les postes avec un retour

Sans Ansible : On se connecte sur chaque poste et on modifie notre fichier de configuration (ntp, rsyslog…)
Avec Ansible : On lance la commande ansible all -m copy -a « src=/etc/ansible/files/ntp.conf dest=/etc/ntp.conf » et cette commande est exécutée sur tous les postes avec un retour

Sans Ansible : On configure à la main chaque nouveau poste
Avec Ansible : On écrit un Playbook (livre de recettes) dans un format simple et lisible (YAML) afin qu’il configure chaque nouveau poste de la même manière

Sans Ansible : On copie son script sur chaque poste, on se connecte sur chaque poste et on lance le script
Avec Ansible : On lance la commande ansible all -m script -a « /etc/ansible/files/script.sh » et le script est exécutée sur tous les postes

Je commence à vous intéresser ? Continuons ou plutôt commençons.

Sources : http://www.silicon.fr/ansible-json-ssh-au-service-du-cloud-97062.html
http://sametmax.com/introduction-a-ansible-loutil-du-sysadmin-paresseux-mais-pragmatique/
https://serversforhackers.com/editions/2014/08/26/getting-started-with-ansible/