C'est quoi Ansible ?

L’automatisation des tâches fonctionne grâce à Ansible. 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.

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.

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…

snippet.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.

Ansible utilise un inventaire qui liste les différents hôtes de l’infrastructure et le moyen d’y accéder. Les playbooks 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 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. Il est très utile pour rendre un fichier de configuration générique. Par exemple, l’extrait fictif suivant…

snippet.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.

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.