Yannig : Comparaison de la gestion des FS avec Puppet et Ansible
jeudi 9 octobre 2014 à 21:42Suite de mes aventures avec Ansible : aujourd'hui c'est du système Linux.
Les données du problème : je veux pouvoir gérer le LVM Linux et retailler mes FS à la demande.
La recette sous Puppet
Sous Puppet, en utilisant un fichier yaml/Hiera, l'écriture de tout ceci se ferait avec quelque chose de ce genre :
---
classes: ['lvm']
lvm::volume_groups:
rootvg:
physical_volumes:
- /dev/sda2
logical_volumes:
tmp:
size: 2G
mountpath: /tmp
datavg:
physical_volumes:
- /dev/sdb
logical_volumes:
test:
size: 128
mountpath: /test
Ne pas oublier non plus d'inclure le code suivant dans le fichier site.pp :
hiera_include('classes','')
Bien penser également à installer le module lvm, sinon ça ne marchera pas (puppetlabs-lvm).
Bon, sous Ansible, toutes ces belles choses n'existent pas (encore) en l'état mais sous forme de brique à assembler. On va voir comment recréer un mécanisme à peu près similaire.
La recette sous Ansible
Je me place dans le cadre d'un playbook Ansible avec un fichier system.yml se trouvant dans un répertoire de travail ~/ansible avec le contenu suivant :
---
# Playbook de gestion du système
- name: Propriétés communes système
hosts: all
remote_user: root
roles:
- system
Autre fichier présent : group_vars/all avec le contenu suivant :
---
# Variable applicable à tous
vgs:
rootvg: "/dev/sda2"
datavg: "/dev/sdb"
lvs:
test:
vg: rootvg
mountpoint: /test
size: 256
Ce fichier sera a spécialiser par groupe de machine mais est l'équivalent de notre fichier yaml/Hiera. Reste maintenant à écrire notre liste de tâche qui nous permettra de gérer ces FS (qu'on mettra dans le fichier roles/system/tasks/main.yml) :
---
- name: VG/PV Configuration
lvg: vg={{ item.key }} pvs={{ item.value }} state=present
with_dict: vgs
- name: LV creation
lvol: vg={{ item.value.vg }} lv={{item.key}} size={{item.value.size}}
register: task
with_dict: lvs
- name: LV format
filesystem: fstype=ext4 dev=/dev/mapper/{{item.value.vg}}-{{item.key}}
with_dict: lvs
- name: Mount
mount: name={{item.value.mountpoint}} src=/dev/mapper/{{item.value.vg}}-{{item.key}} dump=1 passno=2 fstype=ext4 state=mounted
when: item.value.has_key('mountpoint')
with_dict: lvs
- name: FS resize
command: resize2fs /dev/mapper/{{item.item.value.vg}}-{{item.item.key}}
with_items: task.results
when: item.changed == True
NB : cette recette ne gère que des fs de type ext4. Si vous voulez gérer du xfs/btrfs/fegafatfs, il faudra changer la commande resize2fs par autre chose.
Le fonctionnement de la recette est assez simple : on enchaine les opérations (création du PV/VG, création du LV, formatage et montage) et on exécute la commande resize2fs qu'en cas de changement sur le LV (cf FS resize, ligne when: item.changed == True).
Reste maintenant à lancer notre playbook avec la commande ansible-playbook -i ./hosts ./system.yml. Vous devriez obtenir le résultat suivant :
PLAY [Propriétés communes système] ******************************
GATHERING FACTS *************************************************
ok: [machine1]
TASK: [common | VG/PV Configuration] ****************************
ok: [machine1] => (item={'key': 'datavg', 'value': '/dev/sdb'})
ok: [machine1] => (item={'key': 'rootvg', 'value': '/dev/sda2'})
TASK: [common | LV creation] ************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})
TASK: [common | LV format] **************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})
TASK: [common | Mount] ******************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})
TASK: [common | FS resize] **************************************
changed: [machine1] => (item={u'msg': u'', 'item': ...})
PLAY RECAP ******************************************************
machine1 : ok=6 changed=4 unreachable=0 failed=0
Changeons la taille de notre FS pour autre chose et relançons ansible pour vérifier la bonne prise en compte de tout ceci :
PLAY [Propriétés communes système] ******************************
GATHERING FACTS *************************************************
ok: [machine1]
[...]
TASK: [common | LV creation] ************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})
[...]
TASK: [common | FS resize] **************************************
changed: [machine1] => (item={u'msg': u'', 'item': ...})
PLAY RECAP ******************************************************
machine1 : ok=6 changed=2 unreachable=0 failed=0
Tout c'est bien passé. Il ne me reste plus qu'à vous souhaiter une bonne gestion de vos LV !
Original post of Yannig.Votez pour ce billet sur Planet Libre.
Articles similaires
- Yannig : Utilisation de Puppet sous AIX pour la gestion des logicals volumes (22/07/2013)
- Jonathan Le Lous : Cloud open source : the next step ? orchestration (puppet, rudder, juju, ansible) , virtualization (Xen), Ceph, Cloudstack, SDN et GNU .... (11/10/2013)
- Yannig : Premier pas avec Ansible et gestion du sudo (07/10/2014)
- Eddy33 : Fedora 15 vs Fedora 14 : comparaison des performances pour les versions 32 bits (29/08/2011)
- Eddy33 : Fedora 16 vs Fedora 15 : comparaison des performances pour les versions 32 bits (11/12/2011)