6 - Ansible
Playbook
Un Playbook est un fichier YAML qui décrit un ensemble de tâche à accomplir avec un ou plusieurs modules afin d'amener une cible d'un état à un autre de façon reproductible.
Exemple
Le plus simple et de voir le contenu d'un premier Playbook que vous sauvegarderez dans le fichier ~/ansible/admx.osef.yaml de votre serveur Debian.
---
# Les documents YAML débutent avec trois tiret
# il faut indiquer le nom de l'hôte ou du groupe concerné
- hosts: conteneur
# il est possible de préciser quelques variables
vars:
net_port: 80
fqdn: admx.osef
# demander les droits root via sudo
become: true
# puis viens la liste des tâches
tasks:
# pour chaque tâche il faut donner un nom pour l'affichage
- name: Mise à jour via APT
# indiquer le module à utiliser
apt:
# et ces paramètres
update_cache: yes
upgrade: full
- name: Installation & MàJ d'Apache
apt:
name: apache2
state: latest
notify:
- Redémarrage d'Apache
- name: Vérification que le mode rewrite est actif
apache2_module:
name: rewrite
state: present
notify:
- Redémarrage d'Apache
- name: Mise en place du fichier vhost
template:
src: ~/ansible/vhost.conf.j2
dest: /etc/apache2/sites-available/{{name}}.{{fqdn}}.conf
notify:
- Redémarrage d'Apache
- name: Création du dossier racine du vhost
file:
path: /srv/http/{{name}}.{{fqdn}}
state: directory
mode: "u=rwx,g=rwx,o=rx"
- name: Mise en place de l'index.html
template:
src: ~/ansible/index.html.j2
dest: /srv/http/{{name}}.{{fqdn}}/index.html
- name: Activation du vhosts
command: a2ensite {{name}}.{{fqdn}}
notify:
- Redémarrage d'Apache
handlers:
- name: Redémarrage d'Apache
service:
name: apache2
state: restarted
En dehors du déroulé classique de chaque tâche, vous noterez les nombreux appels au mot clé notify. Ce mot clé permet d'indiquer qu'en cas de changement du système suite à l'application d'une tâche, il faudra appeler le handlers correspondant. Ici, chaque modification du serveur Apache qui nécessite un redémarrage fait un appel notify: Redémarrage d'Apache. Ainsi, plutôt que de redémarrer Apache à chaque modification. Le playbook va dérouler son travail et ne redémarrer Apache qu'une seule fois lors du dernier appel à notify.
Ce playbook vient accompagné des templates Jinja2 suivant :
- ~/ansible/vhost.conf.j2
<VirtualHost *:{{net_port}}>
ServerAdmin webmaster@{{fqdn}}
ServerName {{name}}.{{fqdn}}
ServerAlias www.{{name}}.{{fqdn}}
DocumentRoot /srv/http/{{name}}.{{fqdn}}
ErrorLog ${APACHE_LOG_DIR}/{{name}}.{{fqdn}}-error.log
CustomLog ${APACHE_LOG_DIR}/{{name}}.{{fqdn}}-access.log combined
<Directory /srv/http/{{name}}.{{fqdn}}/>
Options -Indexes +FollowSymLinks
AllowOverride None
Require all granted
</Directory>
</VirtualHost>
- ~/ansible/index.html.j2
<!DOCTYPE html>
<html>
<head>
<title>{{name}}.{{fqdn}} work's !</title>
<meta charset="UTF-8" />
<style><!--
* { font-family:sans-serif; text-decoration:none; }
--></style>
</head>
<body>
<header><h1>{{name}}.{{fqdn}} work's !</h1></header>
<p>Change me if you can</p>
</body>
</html>
Une fois tout ces fichiers créés sur votre serveur Debian, il ne reste plus qu'a admirer le résultat :
ansible-playbook -i ansible/inventaire ansible/admx.osef.yaml
Vous constaterez que l'existance d'une précédente installation d'Apache ne perturbe en rien le déroulement des tâches. Chaque conteneur se voit modifié tel que décrit dans le fichier YAML et une fois les opérations terminées, vous pouvez accéder aux nouveaux site web depuis le client Ubuntu :
ou depuis votre machine hôte :
Roles
Lorsque des tâches complexes doivent être opérées, il devient nécessaire de trier et ordoner le travail. C'est là qu'interviennent les roles. Il s'agit d'une arborescence conventionnelle qui va accueillir les différentes données nécessaires à une automatisation. Notez qu'un rôle peut faire appel à un autre rôle.
Pour générer l'arborescence d'un rôle, ansible fourni la commande ansible-galaxy. La commande ansible-galaxy suivante va créer les dossiers du rôle test
mkdir ansible/roles && cd ansible/roles
ansible-galaxy init test
sudo apt install tree
tree test/
test/
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
Cette commande va créer le dossier test qui va contenir un fichier README.md et une collection de sous-dossier :
- defaults - pour définir les variables par défaut
- files - pour stocker des fichiers statiques
- handlers - pour stocker les événements
- meta - pour stocker les meta-données (auteurs, dépendances, ...)
- tasks - pour stocker les actions à opérer
- templates - pour stocker les fichiers dynamiques au format Jinja2
- tests - pour définir un environnement de test, notamment pour l'intégration continue
- vars - pour déclarer des variables (qui supplenterons les variables par défaut du dossier default)
De tout ces dossiers, il ne faut garder que ceux que l'on utilise. Beaucoup de rôles se contentent des dossiers tasks, templates et handlers.
Pour appeler un role dans un playbook, il suffit d'ajouter (par exemple) :
- hosts: conteneur
roles:
- test
Ainsi, vous pouvez organiser chaque groupe d'action (installer apache, installer mariadb) dans des roles séparés et appeler tel ou tel roles depuis les playbooks en fonction des scénarios à écrire.
Documentation officielle : Ansible roles
