Playbooks complexes 2

Cet article a été initialement écrit sur le blog-libre aujourd’hui fermé, certains liens dans l’article peuvent donc être morts.

Nouveau palier supplémentaire mais pas réellement difficile où l’on va encore exposer les possibilités de Ansible devant vos yeux ébahis. On a vu un paquet de choses, on a quasiment tous les playbooks et toutes les commandes dont on pourrait avoir besoin pour configurer un ou cent nouveaux postes.

Oui mais c’est bien beau de pouvoir copier un fichier comme /etc/network/interfaces tout bien préparé et commenté avec amour mais à chaque nouveau poste je vais devoir ouvrir mon fichier de configuration /etc/ansible/files/interfaces pour changer l’adresse IP de mon nouveau poste ? Non, pour cela il y a les templates (module template pour être exact).

Utilisation du playbook : ansible-playbook copy_interfaces.yml -e ‘host=SRV-NEW ipv4=192.168.1.16’
Utilité du playbook : Copier le fichier interfaces avec des variables dedans
Playbook copy_interfaces.yml

---
- name: Copy /etc/network/interfaces
  hosts: "{{ host }}"
  tasks:
    - name: copy the file
      template: src=templates/interfaces.j2 dest=/etc/network/interfaces owner=root group=root mode=0644 backup=yes

Templates interfaces.j2

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
    address {{ ipv4 }}
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.255.255
    gateway 192.168.1.1

Explications : On peut remarquer dans notre playbook qu’on utilise le module template, on peut aussi remarquer qu’on y trouve que la variable host ? Oui, la seconde variable nommée ipv4 se trouve dans le fichier interfaces.j2. Le fichier interfaces.j2 est notre template, il se trouve dans le dossier templates qu’on aura pris soin de créer préalablement (mkdir -p /etc/ansible/templates). L’extension .j2 signifie par convention que c’est un fichier Jinja2.

Ici notre playbook va copier notre template interfaces.j2 sur le poste Client en remplaçant la variable ipv4 par l’adresse IP 192.168.1.16, on a affecté les bons droits à ce fichier et on fait un backup avant de modifier ce fichier.

Utilisation du playbook : ansible-playbook copy_hosts.yml -e ‘host=SRV-NEW ipv4=192.168.1.16’
Utilité du playbook : Copier le fichier hosts avec des variables dedans
Playbook copy_hosts.yml

---
- name: Copy /etc/hosts
  hosts: "{{ host }}"
  tasks:
    - name: copy the file
      template: src=templates/hosts.j2 dest=/etc/hosts owner=root group=root mode=0644 backup=yes

Template hosts.j2

127.0.0.1    localhost
127.0.1.1    {{ host }}
{{ ipv4 }}   {{ host }}.domain.tld    {{ host }}

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Explications : Même chose que l’exemple précédent mais avec le fichier hosts. Voyez la facilité et la puissance du truc.

Utilisation du playbook : ansible-playbook copy_cron.d_admin.yml -e ‘host=SRV-NEW minute=00 hour=23’
Utilité du playbook : Copier le fichier admin (/etc/cron.d/admin) avec des variables dedans
Playbook copy_cron.d_admin.yml

---
- name: Copy /etc/cron.d/admin
  hosts: "{{ host }}"
  tasks:
    - name: copy the file
      template: src=templates/admin.j2 dest=/etc/cron.d/admin owner=root group=root mode=0600 backup=yes

Template admin.j2

{{ minute }} {{ hour }} * * * caroot /bin/bash /backup.sh

Explications : Simple à comprendre je pense. Je n’utilise qu’une seule tâche commune à tous les postes, la sauvegarde. Vous utilisez peut-être crontab -e pour paramétrer vos crons ? Pas terrible. Il est recommandé de sauvegarder le dossier /etc/ sur un poste/serveur car 99% de la configuration de votre poste/serveur est dans ce dossier. En utilisant un fichier /etc/cron.d/admin (n’oubliez pas de le protéger avec un chmod 600 par exemple) vous avez donc vos crons sauvegardés dans votre sauvegarde. A titre informatif, crontab -e enregistre les données dans /var/spool/cron/crontabs/root. Le second avantage d’utiliser cette façon est d’avoir une maintenance plus claire/facile par exemple /etc/cron.d/backup pour les tâches de sauvegarde, /etc/cron.d/clean pour les tâches de nettoyage/suppression etc.

On a fait le tour pour les débutants de ce merveilleux outil au potentiel exponentiel qu’est Ansible, le but étant de vous mettre le pied à l’étrier. Je tenterai de répondre à toutes les questions mais merci d’être patient et je n’aide personne qui n’a pas fait l’effort de chercher un minimum par lui-même. On n’apprend vraiment qu’en cherchant et en commettant des erreurs, c’est le jeu.

Si vous êtes arrivés jusqu’ici vous n’êtes plus réellement débutants à vous de prendre votre envol (et j’espère revenir nous faire un article ici). Il y a de nombreux concepts de Ansible que je n’ai pas présentés :
– Les rôles sont un concept ultra-important que je n’ai pas abordé, commencez ici
– https://galaxy.ansible.com/ est un repository (dépôt ou référentiel) listant les rôles proposés par la communauté. Je le trouve personnellement encore bien vide et les rôles pas super top mais ça va vous donner des idées : LAMP, monit
– Ansible fonctionne sur Red Hat, Debian, CentOS, Ubuntu, Fedora ainsi que sur OS X et FreeBSD. D’après ici, cela fonctionne également pour Arch et Gentoo à vérifier
– Vraiment abusez de ansible SRV-NEW -m setup par exemple la variable ansible_os_family (pour tous les exemples ça aurait été == ‘Debian’) vous permettra de jouer avec les conditions et when.