{{indexmenu_n>1}}

# C'est quoi Ansible ?

L'automatisation des tâches fonctionne grâce à [Ansible](https://docs.ansible.com/ansible/latest/index.html). Bien qu'une connaissance approfondie d'Ansible ne soit pas nécessaire pour exécuter les tâches, il est nécessaire d'en avoir une pour écrire des évolutions. Et c'est mieux de comprendre ce qu'il se passe derrière les commandes 😉. 

Ansible est un outil d'automatisation qui s'exécute traditionnellement depuis la machine locale, appelée *orchestrateur*, et qui exécute des commandes sur des hôtes distants, à travers SSH. Il opère sur des machines déjà crées, à la différences d'outils comme Puppet ou Chef qui ont pour objectif de *provisionner* des machines.

## Intérêts

Correctement utilisé, Ansible permet de :

* Créer des tâches génériques applicables et paramétrables sur un ensemble de machine (exemple : déployer un reverse proxy),
* Documenter la manière d'effectuer une tâche d'administration directement « dans le code » (YAML),
* Créer un véritable « plan de construction » d'une machine, permettant en théorie de la reconstruire intégralement (sans les données),
* Garder une trace des changements de la configuration (un changement = un commit), dans l'esprit de l'« Infrastructure As Code » (IAC).

Notre utilisation d'Ansible est limitée et concerne essentiellement le premier point.

## Exemples

Il faut voir les *tâches* exécutées par Ansible comme des « scripts shell améliorés ». Les tâches sont décrites en YAML et sont généralement agnostiques du système d'exploitation sous-jacent. Par exemple, la tâche...

```yaml
- name: Ensure postgres user exists
  user: 
    name: postgres
    state: present
```

...s'assure que l'utilisateur `postgres` existe sur le système distant. De plus, les tâches Ansible sont *idempotentes*, c'est-à-dire qu'elles peuvent être lancées plusieurs fois et donneront le même résultat. Dans cet exemple, si l'utilisateur existe déjà, Ansible le détectera et ne tentera pas d'en créer un nouveau.

<bootnote warning>
Ansible laisse énormément de libertés, ainsi il est possible d'écrire des tâches dangereuses, non-idempotentes, lourdes, etc. C'est à chacun·e de prendre le temps de réfléchir à la meilleure solution, voire de décider de ne pas automatiser.
</bootnote>

Ansible utilise un [inventaire](https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html) qui liste les différents hôtes de l'infrastructure et le moyen d'y accéder. Les [playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html) permettent d'appliquer des tâches *sur* des hôtes particuliers, dans un ordre donné. Les tâches sont souvent regroupées au sein de [rôles](https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#playbooks-reuse-roles) afin de former un ensemble cohérent et ré-utilisable (exemple : un rôle `nginx` permettant d'installer et de configurer un serveur web).

Ansible utilise le [moteur de template Jinja2](https://docs.ansible.com/ansible/latest/user_guide/playbooks_templating.html). Il est très utile pour rendre un fichier de configuration générique. Par exemple, l'extrait fictif suivant...

```jinja2
http {
  server {
    server_name {{ domain_name }};
  }
}
```

...produira un fichier de configuration pour serveur web, en ayant remplacé `{{ domain_name }}` par la valeur de la variable `domain_name`. Cette variable peut être, par exemple, attachée à un hôte précis ou calculée à la volée. Le même fichier, et par extension la même tâche, sera utilisable pour des hôtes différents.

## Vocabulaire

Dans la suite de la documentation, on utilise les mots suivants :

* Un **module** est souvent l'abstraction d'une commande shell et propose généralement une interface unique pour gérer un aspect particulier de l'administration système (exemple : systemd, synchronize...)
* Une **tâche** est l'unité d'action la plus petite dans Ansible : elle exécute un **module** avec des paramètres.
* Un **template** est un fichier avec des « trous » (cf Jinja2 plus haut), remplacés à l'exécution en fonction de la machine sur lequel il doit être déployé.
* Un **rôle** est un ensemble cohérent de tâches auto-suffisantes réalisant une fonction. Pour nous, c'est souvent le déploiement d'un service particulier. Le rôle est agnostique des machines où le service est déployé et doit être **paramétrable**. Il a souvent des **templates**.
* Un **hôte** est une machine accessible en SSH déclarée dans l'inventaire.
* Un **groupe** est un ensemble d'hôtes déclaré dans l'inventaire (exemple : tous les serveurs web, toutes les bases de données, etc).
* Un **playbook** est un ensemble de tâches et de rôles s'exécutant sur un ou plusieurs hôtes particuliers. Il est commun qu'un playbook combine plusieurs rôles pour effectuer une tâche d'administration complexe.