Journal Ansible ton conteneur !

Posté par Anonyme le 26 mars 2015 à 21:50. Licence CC By‑SA.

Étiquettes :

mar.

2015

Salut là dedans,

Je viens tout juste de voir qu’hier est sorti Ansible 1.9 et qu’il intègre le module lxc_container. Ayant rédigé un petit quelque chose sur ma page perso, je vous le retranscrit ici afin de, peut-être, vous faire passer le pas de la galaxie Ansible.

Il vous sera peut-être nécessaire d’avoir quelques bases concernant Ansible pour comprendre pleinement ce dont il est question, mais j’espère que je vous donnerai envie d’essayer :-)

Je ne couvrirai pas tout, ce sera mise en œuvre assez simple, se basant sur l’inventaire ansible pour créer un conteneur à partir d’un template LXC existant.

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, car Ansible est écrit en Python 2.

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égueux consistant à 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 dont on se fout complètement 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'
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

Bisous.

(NdM: contenu réédité lors de l'anonymisation)

# Oubli…

Posté par Anonyme le 26 mars 2015 à 21:56. Évalué à 2.

Forcément, il fallait que j’oublie quelque chose.

Dans la définition de l’inventaire, 01-mail doit avoir une variable mytemplate valant, par exemple debian, et qui sera le template LXC à utiliser.
- [^] # Re: Oubli…
  
  Posté par Serge Julien le 26 mars 2015 à 22:27. Évalué à 10.
  
  Dans les choses que tu as oubliées: expliquer de quoi il est question, comme le veut l'usage dans ces colonnes. Tout le monde ne sait pas ce qu'est Ansible, à quoi ça sert, à qui ça s'adresse…
  
  Par exemple:
  
  Pour rappel, Ansible est une plate-forme libre permettant la configuration et la gestion d'un parc de machines.
  - [^] # Re: Oubli…
    
    Posté par feth le 27 mars 2015 à 08:32. Évalué à 3.
    
    Dont la principale différence avec ses concurrents est de fonctionner par fichier batch.
    
    Docker, à un extrêmité du spectre, est l'équivalent moderne des images disques à partager qu'on faisait avec Norton Ghost sur les windows 98.
    
    Salt, à l'autre extrêmité, décrit l'état attendu et la manière d'y parvenir.
    Le principe de CFEngine est en gros le même, mais il va parcourir les états de façon récursive et ne découvrir qu'un seul niveau de dépendance à chaque lancement.
    
    Et si j'ai bien compris, je mettrais ansible au milieu, j'ai bon ? (je ne connais bien que Salt)
    - [^] # Re: Oubli…
      
      Posté par Misc (site web personnel) le 27 mars 2015 à 10:23. Évalué à 6.
      
      Ça depend ou tu situes ton spectre.
      
      Ansible est un moteur d'execution de modules via ssh. Tu décrit un tache ( 'installer un paquet via yum' ), et tu lances la tache sur X machines décrit dans un fichier d'inventaire. C'est le mode le plus simple.
      
      Ensuite, tu as "décrire plusieurs taches, et les lancer sur une ou plusieurs machines", ce qui est un playbook. La, tu peut soit faire de la convergence de configuration ( ie, relancer le playbook qui indique comment ton serveur doit être installé, et miser sur le fait que les taches soient idempotentes pour que ça marche ), soit faire de l'orchestration ( genre je prends 3 serveurs, je les retire de nagios et du load balancer, j'upgrade, je reboote, je remets dans nagios, le load balancer, et je passe aux 3 suivants ).
      
      Et comme ansible est flexible, tu peux faire plus que du ssh. Par exemple, considerer que "chroot /foo" est une connexion à un os différent. Ou dans le cas de l'article, que lxc ou docker le soit. Et donc, tu peut preparer une arborescence pour usage futur. Genre pour usage dans une image docker. Ou comme j'ai tenté de le faire, pour une image ostree.
      - [^] # Re: Oubli…
        
        Posté par feth le 27 mars 2015 à 11:51. Évalué à 3.
        
        C'est rigoureusement tout pareil avec Saltstack, en fait (sauf que ssh est pour Saltstack un moyen de transport très secondaire et qui ne propose pas forcément toutes les capacités de l'outil).
        
        [^] # Re: Oubli…
        
        Posté par flan (site web personnel) le 27 mars 2015 à 14:17. Évalué à 3.
        
        Avec Salt, tu as un unique serveur maître qui va jouer l'intermédiaire, et qui a une configuration globale.
        Dès que tu vas demander quelque chose, tu vas passer par ce maître (et tu n'as pas besoin d'avoir le droit de connexion directe aux serveurs).
        
        Avec Ansible, n'importe quel admin sys va se connecter directement aux machines qui sont définies dans le fichier de conf' spécifique au projet, sans passer par un intermédiaire.
        
        [^] # Re: Oubli…
        
        Posté par Seb (site web personnel) le 27 mars 2015 à 15:47. Évalué à 2.
        
        Avec ansible-pull on n'est pas forcé non plus d'avoir une connexion directe aux serveurs : http://docs.ansible.com/playbooks_intro.html#ansible-pull
        Je ne l'ai jamais utilisé, mais a priori c'est équivalent à un checkout Git d'une configuration sur laquelle on exécute ansible-playbook.
        
        [^] # Re: Oubli…
        
        Posté par Misc (site web personnel) le 27 mars 2015 à 23:53. Évalué à 4.
        
        Tu es pas obligé. Tu as comme dit "ansible-pull", ou tu peux utiliser mon role de bastion ( https://github.com/OSAS/ansible-role-ansible_bastion ), ou tu commites via git et ça déclenche la mise à jour sélective depuis une machine central ( et idéalement mieux sécurisé ).
        
        J'ai tenté de travailler sur un setup avec ansible-pull , mais j'ai encore le souci de distribution des secrets ( ie, comment je m'assure qu'un serveur compromis n'a pas d'accés au mot de passe des autres serveurs,
        
        J'utilise assez souvent le cache des facts pour avoir une vue globale de mon infra, et ça utilise le fait d'avoir un seul serveur pour ça. Mais je pense que le partage des données en cache devrait être reglé par : https://github.com/ansible/ansible/pull/9804 ), j'ai juste pas tenté.
        
        [^] # Re: Oubli…
        
        Posté par Misc (site web personnel) le 27 mars 2015 à 23:59. Évalué à 4.
        
        Sauf que salt-ssh ne fait que du ssh.
        
        Ansible propose ça :
        https://github.com/ansible/ansible/tree/devel/lib/ansible/runner/connection_plugins
        
        Par exemple, ansible tourne par dessus funcd, ou supporte d'entrer dans une zone, un lxc, ou un chroot.
        
        Et j'ai un bout de code qui le fait marcher par dessus salt, modulo le dernier bug que je doit corriger ( je sais pas si c'est du coté de salt ou du coté d'ansible, mais la ligne de commande shell que ansible utilise coince avec salt )

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.