2018-02-26 08:05:38 +00:00
|
|
|
|
\newpage
|
|
|
|
|
|
|
|
|
|
Automatiser la configuration de son SI
|
|
|
|
|
=======================================
|
|
|
|
|
|
2018-03-07 03:14:36 +00:00
|
|
|
|
Comme tout bon ~~paresseux~~ sys. admin qui se respecte, sans plus attendre,
|
2019-03-15 11:59:55 +00:00
|
|
|
|
vous allez vouloir automatiser toutes ces actions rébarbatives (configurer des
|
|
|
|
|
services). Comme de très nombreuses personnes sont passées par là avant vous,
|
|
|
|
|
il existe un grand nombre de solutions pour gérer les configurations d'un parc
|
|
|
|
|
de machines. Parmi les plus connues, citons : [Puppet](https://puppet.com/),
|
2018-03-07 03:14:36 +00:00
|
|
|
|
[Chef](http://www.chef.io/), [SaltStack](https://saltstack.com/) ou encore
|
|
|
|
|
[Ansible](https://www.ansible.com/).
|
|
|
|
|
|
|
|
|
|
|
2018-02-26 08:05:38 +00:00
|
|
|
|
Introduction à Ansible
|
|
|
|
|
----------------------
|
|
|
|
|
|
2018-03-07 03:14:36 +00:00
|
|
|
|
Ansible est une solution de gestion de configuration. Basé sur
|
|
|
|
|
[Python](https://www.python.org/) et
|
|
|
|
|
[YAML](http://www.yaml.org/spec/1.2/spec.html), sa principale particularité est
|
2019-03-12 12:02:39 +00:00
|
|
|
|
de ne pas nécessité de daemon sur les machines qu'il va gérer : tout se fait
|
2018-03-07 03:14:36 +00:00
|
|
|
|
exclusivement via SSH, à partir de la machine d'un administrateur, possédant
|
|
|
|
|
Ansible.
|
|
|
|
|
|
|
|
|
|
Son installation est très simple, car les dépendances sont minimes et l'outil
|
2019-03-12 12:02:39 +00:00
|
|
|
|
n'a pas besoin de base de données pour fonctionner : tout va se faire à partir
|
2018-03-07 03:14:36 +00:00
|
|
|
|
d'une arborescence de fichiers, qui sera gérée par Git.
|
2018-02-26 08:05:38 +00:00
|
|
|
|
|
2018-03-07 03:14:36 +00:00
|
|
|
|
Commencez par installer Ansible, sur une machine distincte de la machine
|
2019-03-12 12:02:39 +00:00
|
|
|
|
virtuelle démarrée : la machine hôte sera parfaitement adaptée à cette tâche,
|
|
|
|
|
d'autant plus que l'installation de la plate-forme est propre et légère : vous
|
2018-03-07 03:14:36 +00:00
|
|
|
|
ne risquez pas de vous retrouver avec une usine à gaz impossible à retirer.
|
|
|
|
|
|
|
|
|
|
[Consultez la procédure d'installation pour votre distribution ici](http://docs.ansible.com/ansible/latest/intro_installation.html).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Résultat attendu
|
2018-02-26 08:05:38 +00:00
|
|
|
|
----------------
|
|
|
|
|
|
2018-03-07 03:14:36 +00:00
|
|
|
|
À la fin de cette partie, vous devez être en mesure de pouvoir déployer une
|
|
|
|
|
nouvelle machine, identique à celle que vous venez de configurer, à partir
|
|
|
|
|
d'une ISO et d'un nouveau disque.
|
|
|
|
|
|
2019-03-15 11:59:55 +00:00
|
|
|
|
Le fichier à rendre est un playbook `login_x-TP2/basis.yml`, accompagné de
|
|
|
|
|
toutes ses dépendances : celui-ci doit faire les configurations basiques du
|
|
|
|
|
système et des utilisateurs.
|
|
|
|
|
|
|
|
|
|
Un deuxième playbook est à rendre : `login_x-TP2/vitrine.yml`, celui-ci doit
|
|
|
|
|
permettre de déployer (en parallèle de tous les autres), une page vitrine
|
|
|
|
|
typique d'une entreprise (cf. la 4e question de cours ;)). Cette page doit être
|
|
|
|
|
accessible depuis votre domaine <https://login_x.adlin2020.p0m.fr/>.
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mon première commande
|
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
|
|
### Inventaire
|
|
|
|
|
|
|
|
|
|
Comme il sera bientôt question de maintenir plusieurs machines, la première
|
|
|
|
|
chose à faire consiste à les inventorier.
|
|
|
|
|
|
|
|
|
|
Commençons par créer un répertoire, qui contiendra l'ensemble de nos
|
|
|
|
|
configurations à destination d'Ansible. Dans ce répertoire, créons un fichier
|
2019-03-12 12:02:39 +00:00
|
|
|
|
d'inventaires `hosts`, contenant l'IP de notre machine :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
|
|
|
|
all:
|
|
|
|
|
hosts:
|
|
|
|
|
192.168.0.106
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Vous pouvez lancer une autre machine virtuelle à ce stade et ajouter son IP sur
|
|
|
|
|
une nouvelle ligne du fichier `hosts`.
|
|
|
|
|
|
|
|
|
|
Plus tard, c'est dans ce fichier que vous pourrez créer des groupes de machines
|
|
|
|
|
(par exemple pour regrouper les serveurs web, les bases de données, etc.) ou
|
|
|
|
|
donner des caractéristiques spécifiques à vos machines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### `ping`
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Lancez ensuite la commande suivante :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```
|
2019-03-10 20:58:40 +00:00
|
|
|
|
42sh$ ansible --inventory-file hosts all --module-name ping --user root --ask-pass
|
|
|
|
|
192.168.0.106 | SUCCESS => {
|
|
|
|
|
"changed": false,
|
|
|
|
|
"ping": "pong"
|
|
|
|
|
}
|
2018-03-07 03:14:36 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Vous devriez avoir un retour similaire à celui-ci, indiquant simplement que la
|
|
|
|
|
connexion a bien été effectuée et que le nécessaire est bien installé sur la
|
|
|
|
|
machine distance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Confort
|
|
|
|
|
|
|
|
|
|
Une des premières choses que nous devrions faire, est d'installer notre clef
|
|
|
|
|
SSH sur les machines, pour éviter d'avoir à taper le mot de passe à chaque
|
|
|
|
|
test.
|
|
|
|
|
|
|
|
|
|
Si vous avez bien suivi jusqu'ici, vous savez qu'il ne faut pas utiliser le
|
2019-03-12 12:02:39 +00:00
|
|
|
|
compte `root` directement ! Pas d'inquiétude, tout est prévu dans Ansible :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
retirer l'option `--user root` si votre nom d'utilisateur local est identique
|
|
|
|
|
que celui dans la machine virtuelle, ou adaptez l'option en conséquence.
|
|
|
|
|
|
|
|
|
|
Et ajoutez les options `--become` et `--ask-become-pass` (utilisez `--sudo` et
|
2019-03-12 12:02:39 +00:00
|
|
|
|
`--ask-sudo-pass` pour les vieilles versions) :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
2019-03-10 20:58:40 +00:00
|
|
|
|
```bash
|
|
|
|
|
ansible --inventory-file hosts all -m ping -u bruce --become --ask-become-pass
|
2018-03-07 03:14:36 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Les modules
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Les modules Ansible ont généralement deux missions distinctes :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
- récupérer des informations en allant les extraire sur chaque machine ;
|
2018-03-07 03:14:36 +00:00
|
|
|
|
- pousser des nouvelles informations pour atteindre un état précis.
|
|
|
|
|
|
|
|
|
|
Lorsque les informations récupérées montrent que l'état est déjà atteint,
|
|
|
|
|
aucune modification n'est faite sur la machine, on parle d'idempotence.
|
|
|
|
|
|
|
|
|
|
À noter cependant que lorsque l'on retire un état de notre recette, il est
|
|
|
|
|
conservé tel quel sur la machine. Par exemple, si un utilisateur `toto` est
|
2019-03-12 12:02:39 +00:00
|
|
|
|
créé suite à l'application d'une recette décrivant l'utilisateur `toto` ; si
|
2018-03-07 03:14:36 +00:00
|
|
|
|
l'on supprime la description, l'utilisateur ne sera pas supprimé des machines
|
|
|
|
|
sur lequel la recette aura été appliquée. Pour qu'il soit supprimé, il faut
|
|
|
|
|
modifier la description pour signaler que cet utilisateur ne doit pas
|
|
|
|
|
exister. À l'application de cette nouvelle recette, si un tel utilisateur est
|
|
|
|
|
trouvé, il sera donc supprimé.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Collecte du mercredi
|
|
|
|
|
|
|
|
|
|
Parmi les modules de base, le module `setup` permet de récupérer un grand
|
2019-03-12 12:02:39 +00:00
|
|
|
|
nombre de caractéristiques de la machine distance, voyez plutôt :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
2019-03-10 20:58:40 +00:00
|
|
|
|
```bash
|
|
|
|
|
ansible -i hosts all -m setup
|
2018-03-07 03:14:36 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Les informations récupérées (quelque soit le module), sont ensuite accessible
|
|
|
|
|
dans des variables afin de permettre de compléter des modèles ou pour faire de
|
|
|
|
|
l'exécution conditionnelle d'état (par exemple on pourra utiliser la variable
|
|
|
|
|
`ansible_facts.ansible_distribution` pour distinguer les gestionnaires de
|
|
|
|
|
paquets).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ma première recette
|
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
|
|
Un livre de recettes (*playbook* dans le vocabulaire d'Ansible), regroupe les
|
|
|
|
|
descriptions des états que l'on souhaite obtenir sur un groupe de machines données.
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Par exemple, voici à quoi pourrait ressembler un tel recueil :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
|
|
|
|
---
|
|
|
|
|
- hosts: webservers
|
|
|
|
|
remote_user: root
|
|
|
|
|
|
|
|
|
|
tasks:
|
|
|
|
|
- name: ensure nginx is at the latest version
|
|
|
|
|
apt: name=nginx state=latest
|
|
|
|
|
- name: write the apache config file
|
|
|
|
|
template: src=/srv/httpd.j2 dest=/etc/httpd.conf
|
|
|
|
|
|
|
|
|
|
- hosts: databases
|
|
|
|
|
remote_user: root
|
|
|
|
|
|
|
|
|
|
tasks:
|
|
|
|
|
- name: ensure postgresql is at the latest version
|
|
|
|
|
yum: name=postgresql state=latest
|
|
|
|
|
- name: ensure that postgresql is started
|
|
|
|
|
service: name=postgresql state=started
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
On filtre d'abord sur les hôtes concernés par la configuration, on donne
|
|
|
|
|
ensuite des paramètres qui seront utilisées pour chaque tâche et enfin on
|
|
|
|
|
décrit les tâches.
|
|
|
|
|
|
|
|
|
|
Le guide de référence pour connaître toutes les syntaxes possibles est
|
|
|
|
|
disponible dans [la documentation
|
|
|
|
|
d'Ansible](http://docs.ansible.com/ansible/latest/playbooks.html).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Exécution d'un *Playbook*
|
|
|
|
|
|
|
|
|
|
Placer le contenu dans un fichier YAML, par exemple `playbook.yml`, non loin du
|
2019-03-12 12:02:39 +00:00
|
|
|
|
fichier `hosts` créé à la section précédentes, puis lancez :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
2019-03-10 20:58:40 +00:00
|
|
|
|
```bash
|
|
|
|
|
ansible-playbook -i hosts playbook.yml
|
2018-03-07 03:14:36 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Coup de pouce
|
|
|
|
|
|
|
|
|
|
Voici à quoi ressemblerait votre premier playbook créant l'utilisateur
|
2019-03-12 12:02:39 +00:00
|
|
|
|
`adeline` :
|
2018-03-07 03:14:36 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
|
|
|
|
---
|
|
|
|
|
- hosts: all
|
|
|
|
|
remote_user: root
|
|
|
|
|
|
|
|
|
|
tasks:
|
|
|
|
|
- name: ensure adeline as an account
|
|
|
|
|
user:
|
|
|
|
|
name: adeline
|
|
|
|
|
state: present
|
|
|
|
|
shell: /bin/fish
|
|
|
|
|
groups: sudo
|
|
|
|
|
append: yes
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
La création de l'utilisateur se fait à l'aide du module
|
|
|
|
|
[`user`](http://docs.ansible.com/ansible/latest/user_module.html).
|
|
|
|
|
|
|
|
|
|
À vous maintenant, à l'aide [des modules à votre
|
|
|
|
|
disposition](http://docs.ansible.com/ansible/latest/modules_by_category.html)
|
|
|
|
|
de copier vos fichiers de configuration à leur place et avec les bons droits
|
|
|
|
|
(`authorized_keys`, `.bashrc`, ...). Installez également les paquets que vous
|
|
|
|
|
aviez installé à la main (client DHCP, `htop`, ...).
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Les notifications
|
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
|
|
Au sein d'un *playbook*, il est possible de définir des tâches particulières
|
|
|
|
|
(nommées *handlers* dans le vocabulaire Ansible), qui ne seront exécutées que
|
|
|
|
|
si un changement à eu lieu. Par exemple, nous pourrions déclarer une tâche de
|
|
|
|
|
redémarrage du serveur web, seulement lorsque sa configuration est mise à
|
|
|
|
|
jour.
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Pour se faire, il faut ajouter un élément `notify` à sa tâche :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
- name: template configuration file
|
|
|
|
|
template: src=template.j2 dest=/etc/httpd.conf
|
|
|
|
|
notify:
|
|
|
|
|
- restart cherokee
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Puis, au même niveau que les *tasks*, on déclare nos *handlers* :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
handlers:
|
|
|
|
|
- name: restart cherokee
|
|
|
|
|
service: name=cherokee state=restarted
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Il est attendu que le nom de la notification corresponde à l'attribut `name`
|
|
|
|
|
d'un handler.
|
|
|
|
|
|
|
|
|
|
Voir [la
|
|
|
|
|
documentation](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change)
|
|
|
|
|
pour davantage de détails et d'exemples.
|
|
|
|
|
|
|
|
|
|
La configuration de votre serveur SSH laisse à désirer. Corriger les problèmes
|
2019-03-12 12:02:39 +00:00
|
|
|
|
énoncés par ces deux articles :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
- <https://ringyt.wordpress.com/2017/05/23/default-hardened-ssh-server-config/> ;
|
2018-03-30 16:58:37 +00:00
|
|
|
|
- <https://stribika.github.io/2015/01/04/secure-secure-shell.html>.
|
|
|
|
|
|
|
|
|
|
Mettez en place un *handler* pour relancer votre serveur SSH en cas de
|
|
|
|
|
modification de sa configuration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Les variables
|
|
|
|
|
-------------
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Les variables peuvent provenir de très nombreux emplacements : définies
|
2018-03-30 16:58:37 +00:00
|
|
|
|
spécifiquement pour l'hôte, chargées depuis des fichiers lié au groupe auquel
|
|
|
|
|
appartient la machine, liées à la recette ou à la tâche en cours d'exécution,
|
|
|
|
|
récupérée par un module (comme le module `setup`).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Définition
|
|
|
|
|
|
|
|
|
|
#### Dans l'inventaire
|
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
all:
|
|
|
|
|
hosts:
|
|
|
|
|
192.168.0.106
|
|
|
|
|
vars:
|
|
|
|
|
ntp_server: ntp.epitech.eu
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Cet inventaire définit une variable `ntp_server` qui pourra ensuite être
|
|
|
|
|
utilisée par une recette installant un serveur NTP. Le cadre d'utilisation de
|
|
|
|
|
ce genre de variable est adapté lorsqu'un hôte ou un groupe d'hôte seulement
|
|
|
|
|
partagent des caractéristiques, comme par exemple leur localisation ou
|
|
|
|
|
datacenter de rattachement, etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Dans un *playbook*
|
|
|
|
|
|
|
|
|
|
De la même manière que dans l'inventaire, il est possible de définir des
|
2019-03-12 12:02:39 +00:00
|
|
|
|
variables dans une recette :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
- hosts: webservers
|
|
|
|
|
vars:
|
|
|
|
|
http_port: 80
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Ces variables peuvent être placées dans un fichier, pour plus de lisibilité :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
- hosts: webservers
|
|
|
|
|
vars_files:
|
|
|
|
|
- /vars/webservers_common.yml
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Le format correspond au sous arbre que l'on pourrait trouver sous `vars` :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
http_port: 80
|
|
|
|
|
https_port: 443
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Utilisation
|
|
|
|
|
|
|
|
|
|
#### Modèles
|
|
|
|
|
|
|
|
|
|
Ces variables peuvent être utilisées pour remplir un emplacement de texte dans
|
|
|
|
|
un modèle. Ansible utilise [Jinja2](http://jinja.pocoo.org/) comme moteur de
|
|
|
|
|
template, un format très courant dans le milieu du développement Python.
|
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```
|
2019-03-10 20:58:40 +00:00
|
|
|
|
I'm running {{ ansible_system }} {{ ansible_os_family }} on {{ ansible_system_vendor }},
|
|
|
|
|
with {{ ansible_memory_mb.swap.free }} MB Swap available.
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Ce format est relativement générique. Ainsi, pour accéder aux éléments d'une
|
2019-03-12 12:02:39 +00:00
|
|
|
|
table de hash/dictionnaire, on utilise le caractère `.` ; les crochets `[x]`
|
|
|
|
|
sont utilisés principalement pour accéder aux éléments des tableaux :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
2019-03-10 20:58:40 +00:00
|
|
|
|
<div lang="en-US">
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
2019-03-10 20:58:40 +00:00
|
|
|
|
My first nameserver is: {{ ansible_dns.nameservers[0] }}.
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
2019-03-10 20:58:40 +00:00
|
|
|
|
</div>
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
2019-03-12 12:02:39 +00:00
|
|
|
|
ou d'un dictionnaire lorsque la clef doit être récupérée d'une variable :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
2019-03-10 20:58:40 +00:00
|
|
|
|
<div lang="en-US">
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
2019-03-10 20:58:40 +00:00
|
|
|
|
My disks are: {% for disk in ansible_device_links.uuids %}
|
|
|
|
|
- {{ disk }}: {{ ansible_device_links.uuids[disk] }}, {{ ansible_device_links.ids[disk]|join(', ') }}
|
|
|
|
|
{% endfor %}
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
2019-03-10 20:58:40 +00:00
|
|
|
|
</div>
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
Notez dans ce dernier exemple l'utilisation d'un filtre `join` permettant
|
|
|
|
|
d'aplatir la liste retournée.
|
|
|
|
|
|
|
|
|
|
#### Dans les recettes
|
|
|
|
|
|
|
|
|
|
Au sein même de votre description YAML, vous pouvez utiliser la puissance de
|
2019-03-12 12:02:39 +00:00
|
|
|
|
Jinja2 :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
- hosts: webservers
|
|
|
|
|
vars_files:
|
|
|
|
|
- /vars/webservers_common.yml
|
|
|
|
|
- /vars/webservers_{{ ansible_os_family }}.yml
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Dans cet exemple, les variables des fichiers `/vars/webservers_common.yml`,
|
|
|
|
|
puis celles de `/vars/webservers_Debian.yml` seront chargées dans le contexte.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Conditions
|
|
|
|
|
|
|
|
|
|
Une autre utilisation possible des variables est d'appliquer ou de passer des
|
2019-03-12 12:02:39 +00:00
|
|
|
|
tâches. Par exemple :
|
2018-03-30 16:58:37 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```yaml
|
2019-03-10 20:58:40 +00:00
|
|
|
|
tasks:
|
|
|
|
|
- name: "pkg setup (Debian)"
|
|
|
|
|
apt: name=chrony state=present
|
|
|
|
|
when: ansible_os_family == "Debian"
|
|
|
|
|
- name: "pkg setup (CentOS)"
|
|
|
|
|
yum: name=chrony state=present
|
|
|
|
|
when: ansible_os_family == "CentOS"
|
2018-03-30 16:58:37 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Vous trouverez bien d'autres cas d'utilisation dans [la
|
|
|
|
|
documentation](http://docs.ansible.com/ansible/latest/playbooks_conditionals.html).
|