Les configurations via Ansible doivent être testées et éprouvées. Et il est parfois délicat d’obtenir une infrastructure disponible. Personnellement, pour mes développements, mes essais, et mes premières validations, je provisionne des VMs Virtualbox sur mon laptop à l’aide de Vagrant. Le cas d’usage du lab’ nécessitant plusieurs VMs d’usage différent et donc de ressources variées a été présenté dans mon précédent article pour la partie provision. Voyons donc maintenant comment y intégrer Ansible en un exposé étape par étape.

Considérant que beaucoup de sites proposent des get started voire présentent en détails Ansible, je fais l’impasse pour rentrer dans le vif du sujet : Remplir son inventaire des arguments SSH, générer cet inventaire, et appliquer un playbook à cet inventaire, le tout en automatique à l’aide d’un seul vagrant up !

Pour commencer sur des bonnes bases, reprenons le code de l’article précédent (dépôt github v1.2)

Pour se connecter à l’aide de la commande vagrant ssh, l’outil Vagrant utilise une clef privée qui est stockée dans un répertoire caché de notre répertoire. On peut tenter de se connecter au kiwi par cette commande :

$ ssh -i .vagrant/machines/kiwi/virtualbox/private_key vagrant@192.168.10.10

A savoir que le mot de passe par défaut est vagrant. Et nous voilà sur la machine kiwi ! Nous allons pouvoir utiliser la couche SSH de Ansible.
Dans un premier temps créons un playbook très simple qui ne servira qu’à confirmer le bon fonctionnement de notre mécanique :

$ cat playbook.yml
 ---
 - name: Loadbalancer
   hosts: loadbalancer
 - name: Le site
   hosts: site

Puis, aménagons-nous un inventaire contenant les paramètres SSH nécessaires. A noter que le user vagrant est le propriétaire de la clef privée déclarée.

$ cat inventaire
 [loadbalancer]
 kiwi ansible_host=192.168.10.10 ansible_user=vagrant ansible_ssh_private_key_file=.vagrant/machines/kiwi/virtualbox/private_key
 [site]
 koala-01 ansible_host=192.168.10.11 ansible_user=vagrant ansible_ssh_private_key_file=.vagrant/machines/koala-01/virtualbox/private_key
 koala-02 ansible_host=192.168.10.12 ansible_user=vagrant ansible_ssh_private_key_file=.vagrant/machines/koala-02/virtualbox/private_key

Puis on applique notre playbook à notre inventaire. Bingo !

$ ansible-playbook playbook.yml --inventory-file=inventaire
PLAY [Loadbalancer] ************************************************************
TASK [setup] *******************************************************************
 ok: [kiwi]
PLAY [Le site] *****************************************************************
TASK [setup] *******************************************************************
 ok: [koala-01]
 ok: [koala-02]
PLAY RECAP *********************************************************************
 kiwi : ok=1 changed=0 unreachable=0 failed=0
 koala-01 : ok=1 changed=0 unreachable=0 failed=0
 koala-02 : ok=1 changed=0 unreachable=0 failed=0

Certains objecteront que la bonne pratique en matière de Vagrant est d’éviter de se connecter par SSH et d’utiliser la commande vagrant ssh. Cette commande utilise les redirections de port (2200 ou autre).
En bref, on peut accéder aux VMs par l’IP localhost sur le port déclaré (que l’on a pris le soin de forcer dans l’article précédent). Un exemple vaut discours, je peux me connecter au premier koala par cette commande :

$ ssh -i .vagrant/machines/koala-01/virtualbox/private_key vagrant@localhost -p2211

Utilisons donc l’usage des ports tel que Vagrant le pratique au travers d’une autre méthode pour renseigner notre inventaire comme ceci :

$ cat inventaire
 [loadbalancer]
 kiwi ansible_host=localhost ansible_port=2210 ansible_user=vagrant ansible_ssh_private_key_file=.vagrant/machines/kiwi/virtualbox/private_key
 [site]
 koala-01 ansible_host=localhost ansible_port=2211 ansible_user=vagrant ansible_ssh_private_key_file=.vagrant/machines/koala-01/virtualbox/private_key
 koala-02 ansible_host=localhost ansible_port=2212 ansible_user=vagrant ansible_ssh_private_key_file=.vagrant/machines/koala-02/virtualbox/private_key

L’appel au même ansible-playbook fournit le même résultat. Vous pouvez essayer avec le dépôt github v2.1.

Un peu long à remplir cet inventaire, alors qu’on a déjà rempli un provision.json dont toutes les informations découlent. Et si nous produisions cet inventaire dynamiquement ? Encore mieux que ce soit le Vagranfile lui-même qui le crée !

Nous allons donc déclarer une variable ansibleHosts, elle sera alimenté des différents paramètres SSH construits lors de la lecture du fileContent dans la boucle, puis on l’écrira dans un fichier dédié vagrant_hosts.

On vérifie le résultat en listant le fichier vagrant_hosts et en lui appliquant le playbook :

$ vagrant up
 $ cat vagrant_hosts
 # Generated by Vagrantfile
 [all]
 kiwi ansible_user=vagrant ansible_host=127.0.0.1 ansible_port=2210 ansible_ssh_private_key_file=.vagrant/machines/kiwi/virtualbox/private_key
 koala-01 ansible_user=vagrant ansible_host=127.0.0.1 ansible_port=2211 ansible_ssh_private_key_file=.vagrant/machines/koala-01/virtualbox/private_key
 koala-02 ansible_user=vagrant ansible_host=127.0.0.1 ansible_port=2212 ansible_ssh_private_key_file=.vagrant/machines/koala-02/virtualbox/private_key

$ ansible-playbook playbook.yml --inventory-file=vagrant_hosts
PLAY [Loadbalancer] ************************************************************
 skipping: no hosts matched
PLAY [Le site] *****************************************************************
 skipping: no hosts matched
PLAY RECAP *********************************************************************

Oui, c’est un peu ennuyeux… Ce résultat est bien logique. Aucun « loadbalancer » ni « site » du playbook ne correspond à ce qui est déclaré dans l’inventaire. Afin de corriger cet état de faits, plusieurs options : créer un mécanisme qui attribue chaque serveurs à un sous-ensemble, corriger l’inventaire afin qu’il corresponde au playbook, corriger le playbook afin qu’il corresponde à l’inventaire.

La première option est fastidieuse, je la laisse de côté, la seconde consiste à ajouter des [loadbalancer] et [site] aux bons endroits, enfin la troisième consiste à utiliser le fait qu’on a anticipé en nommant nos machines koala-*. Nous corrigerons le playbook ainsi :

$ cat playbook.yml
---
- name: Loadbalancer
  hosts: kiwi*
- name: Le site
  hosts: koala*

Chacun opérera comme il l’entend. Voyons surtout comment déclencher l’application de notre playbook une fois les VMs créées. Allez, un peu de ruby pour la route. Le principe est simple, si le noeud en cours de création est le dernier de la liste, on lance l’ansible.

if node == fileContent.last
  machine.vm.provision :ansible do |ansible|
    # Disable default limit to connect to all the machines
    ansible.limit          = 'all'
    ansible.playbook       = "playbook.yml"
    ansible.inventory_path = "vagrant_hosts" # Previously generated
    ansible.raw_arguments  = [
      "--verbose"]
    end
end

Vous pouvez essayer avec le dépôt github v2.2. Amusez-vous bien !