Ansible ton conteneur !

On va pouvoir créer de A à Z notre environnement à base de conteneurs LXC, grâce au module lxc_container maintenant supporté par Ansible 1.9.

Pour cela, je vais faire une mise en œuvre assez simple, se basant sur l’inventaire ansible pour créer un conteneur à partir d’un template.

Prérequis

Premièrement, soit vous installez à la mode gros porc, soit vous utilisez les paquets, soit il n’y a pas de paquet et vous utilisez virtualenv.

Je vais vous montrer l’installation via un environnement virtuel, car c’est la moins simple et que je ne veux pas traiter la méthode dégueue concistant à pourrir sciemment son système.

Déjà, débrouillez-vous pour installer, selon votre distribution, virtualenv pour Python 2. Car c’est avec cette version que Ansible fonctionne. Pour Debian/Ubuntu et CentOS/RedHat, le paquet devrait s’appeler python2-virtualenv ou python-virtualenv.

Ensuite, suivez le guide :

virtualenv pyvenv-ansible
source pyvenv-ansible/bin/activate
pip install ansible
git clone https://github.com/lxc/python2-lxc.git
cd python2-lxc
python setup.py install
cd ../

Inventaire

Disons que nous avons trois machines :

• Celle qui exécute Ansible et qui va donc héberger les conteneurs.
• Une machine qui n’existe encore pas et que nous allons LXC-ifier.
• Une autre machine mais qui n’est pas sous LXC.

À partir de là, nous aurons donc besoin de faire un rôle un peu "intelligent" capable de dire si oui ou non nous allons créer la machine avec LXC.

Déjà, commençons par notre inventaire :

# hosts

[setuplxc]
localhost ansible_connection=local ansible_python_interpreter=python2 mytype='physical'

[blabla]
01-mail mytype='lxc' mytemplate='debian'
02-web mytype='kvm'

Quelques explications sur les variables de localhost :

• ansible_connection=local : permet de ne pas lancer de connexion SSH.
• ansible_python_interpreter : il se peut que votre $ python soit un Python 3. Pour utiliser l’interpréteur de votre choix, et de préférence un qui fonctionnera, je précise ici python2. C’est le cas de ArchLinux par exemple.

Playbook

Le playbook quant à lui se passera d’explications :

--- localhost-site.yml
- hosts: localhost
  roles:
    - setuplxc

Heu oui enfin, quand même, tu le sors d’où ton rôle setuplxc ?

Chhhhhhh… laissez-moi finir.

Rôle

Bon… je disais… oui, le rôle setuplxc.

Bien, on attaque la partie un poil poilue, le filtrage de notre inventaire pour ne garder que les machines devant tourner sous LXC. Ce n’est pas spécialement compliqué une fois qu’on est tombé sur le bon bout de documentation permettant d’utiliser les variables :

--- roles/setuplxc/tasks/main.yml
- name: setup containers
  lxc_container:
    name: "{{ item }}"
    container_log: true
    template: "{{ hostvars[item]['mytemplate'] }}"
    state: started
  when:
    - hostvars[item]['mytype'] == 'lxc'
  with_items:
    - "{{ groups['all'] }}"

Vous l’aurez sans doute compris, groups contient tous les groupes d’hôtes disponibles dans l’inventaire.

Nous appelons ici le group spécial all, et nous bouclons sur toutes les entrées pour en trouver qui aient leur variable mytype à la valeur lxc. Le seul problème ici, c’est qu’une entrée n’ayant pas la variable va un peu faire planter le bouzin. Mais un peu de rigueur ne fait pas de mal, donc mettez cette variable, un point c’est tout.

Ensuite bah, on utilise tout simplement le module lxc_container ! Je pense que les quelques paramètres présents sont limpides, aussi je vous laisser aller lire la documentation du module que vous pourrez trouver en find pyvenv-ansible -name lxc_container.py -exec $EDITOR {} \;

Exécution | FIRE!

Bon, là, il faut soit passer en root directement, soit demander à ansible d’exécuter la tâche en root via un sudo: yes \ sudo_user: root, mais je vous laisse faire.

Puis, en toute simplicité :

ansible-playbook -i hosts localhost-site.yml