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 icipython2
. 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