Tutoriel pour Apprendre à utiliser Ansible

Vous vous doutez bien qu'il faut avant tout installer Ansible sur votre control machine. Rien de bien compliqué, ça tourne sur à peu près tout sauf Windows et il y a plusieurs procédures au choix : du git clone au apt-get. Elles sont pour la plupart détaillées sur la page d'install de Ansible.

En ce qui me concerne, j'ai voulu tenter de l'installer sur mon Mac via Macports, pour plus de facilité et des mises à jour en toute souplesse. L'install se passe assez simplement via un sudo port install ansible. Sur Mac, et c'est valable aussi pour l'install via Homebrew, au lieu d'avoir la config dans /etc/ansible/ tout se passe dans /opt/local/etc/ansible/, ça vous évitera de chercher.

Dans le cas où vous suivriez les instructions d'installation de la doc Ansible - laquelle suggère de procéder à l'installation via PIP -, il n'y a pas de fichier de config par défaut. Pourtant, Ansible le cherchera dans /etc/ansible, de la même manière que le fichier hosts.

Deux solutions sont possibles. Soit vous créez un fichier .ansible.cfg dans votre HOME, et vous précisez bien dans celui-ci où se trouve le fichier hosts, soit vous créez /etc/ansible et vous y placez le fichier hosts.

Avant tout, il faut bien comprendre que Ansible repose sur le protocole ssh. Ainsi, c'est via ce protocole qu'il se connectera à vos serveurs. Par défaut sur le port 22 évidemment. Il tentera aussi par défaut de se connecter via une clef ssh de ~/.ssh/. De plus, l'utilisation d'OpenSSH permet de lire le fichier de configuration ~/.ssh/conf. Néanmoins, l'usage d'OpenSSH est conditionné par une version récente de ce dernier. Dans le cas contraire, Ansible fallback sur une bibliothèque en Phyton.

Les hôtes se configurent dans /etc/ansible/hosts :

# les crochets permettent de définir des groupes
# on pourra ainsi appliquer la même conf à tous les serveurs de backup
# un serveur peut appartenir à plusieurs groupes 
[backup]
# on fait ici référence à un serveur présent dans le fichier conf de .ssh
jarjar

# définir un port non standard
www.buzut.fr:5309

# il est possible d'adresser plusieurs serveurs qui suivent un nommage spécifique
# en utilisant la notation intervalle des REGEX
www[01:50].buzut.fr

Beaucoup d'autres options sont disponibles, vous trouverez toutes les possibilités dans l'Inventory.

Une fois les hôtes configurés, vous pouvez tester une première commande afin de voir que la configuration fonctionne. Le module ping affiche simplement « pong », il n'a rien à voir avec le ping ICMP :

ansible all -m ping
buzut | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

# il se peut que vous ayez un problème 
buzut | UNREACHABLE! => {
    "changed": false, 
    "msg": "SSH encountered an unknown error during the connection. We recommend you re-run the command using -vvvv, which will enable SSH debugging output to help diagnose the issue", 
    "unreachable": true
} 

# après le -vvv et quelques recherches, Ansible crée un dossier .ansible dans votre home
# il se peut que ce répertoire n'appartienne pas au bon utilisateur
# pour remédier à cela
sudo chown -R votre_user ~/.ansible

Dernier petit détail, nous avons entraperçu dans les commentaires qu'il y a de puissants moyens de sélectionner les hôtes. On peut en sélectionner un unique ou tout un groupe, appliquer des REGEX pour en exclure ou préciser un intervalle. Pour tirer toute la souplesse et la puissance de cette notation, lisez rapidement la page patterns de la doc.

Ansible possède une ligne de commande. Pourquoi donc ? Eh bien ! c'est la même chose que pour les scripts. Parfois vous faites un script parce que vous savez que vous aurez à refaire cette manipulation, parfois, c'est juste du one shot - ou c'est super court - donc vous tapez directement ce que vous voulez faire. Par exemple, admettons que vous vouliez redémarrer tous les serveurs de base de données, vous pourriez faire :

# database est notre groupe de serveur [database]
# l'option -a permet de préciser l'argument de la commande
ansible database -a "/sbin/reboot"

# par défaut, ansible lance la commande sur cinq serveurs en parallèle en faisant des forks de son processus
# si votre groupe contient beaucoup de serveurs - front[1-500] par exemple - il peut être judicieux de l'augmenter
# vous pouvez gérer cela avec le paramètre -f
ansible database -a "/sbin/reboot" -f 25

Vous pouvez utiliser l'option -u username pour exécuter une commande depuis un autre utilisateur, -k pour passer en root et entrer le mot de passe root.

La CLI permet d'appeler des modules pour exécuter les commandes que nous voulons. Dans l'exemple ci-dessus, nous n'avons rien précisé, car le module par défaut est command et c'est ce que nous voulions. Admettons maintenant que nous voulions copier un fichier sur l'ensemble de nos serveurs web :

# le module copy permet de transférer un fichier
ansible web -m copy -a "src=/Users/Buzut/Desktop/super-site.conf dest=/etc/apache2/sites-available/super-site.conf"

Vous pouvez en savoir plus sur les modules disponibles directement sur la page de docs dédiée.

J'en ai rapidement parlé en introduction, les playbooks sont des fichiers en YAML qui décrivent les tâches qu'Ansible doit accomplir sur vos serveurs. Les playbooks utilisent une syntaxe très simple : on définit les hôtes, les variables éventuelles, puis on crée des tâches. Chaque tâche possède un nom et appelle des modules (les mêmes qu'en CLI).

Sachez que vous pouvez lancer vos playbooks avec l'option --syntax-check, qui comme son nom l'indique, s'assure qu'il n'y a pas d'erreur dans la syntaxe de vos playbooks. Ensuite, vous pouvez également utiliser --check afin de simuler un play sans effectuer aucun changement. Dans cette dernière option, Ansible va se connecter au(x) serveur(s) et lancer les modules en leur demandant de ne pas effectuer de modifications (tous les modules ne sont pas compatibles, auquel cas, ils ne retourneront pas les changements potentiels).

---
# les documents YAML commencent toujours par "---"

# le nom de l'hôte ou groupe concerné
- hosts: webserver

  # on déclare les éventuelles variables
  vars:
    http_port: 80
    domain: buzut.fr

  # nom de l'utilisateur du compte (lance celui du .ssh/conf par défaut)
  remote_user: root

  # ici débute la liste des tâches
  tasks:

  # nom d'une tâche
  - name: ensure server is up to date
    # nom du module à utiliser
    apt:
      update_cache: yes
      upgrade: full

  # installons apache
  - name: install apache2
    # il existe une syntaxe alternative, plus condensée
    # apt: name=apache2 update_cache=yes state=latest

    apt:
      name: apache2
      update_cache: yes
      state: latest

  # s'assurer que le mod rewrite est actif (l'activer sinon)
  - name: enabled mod_rewrite
    apache2_module:
      name: rewrite
      state: present

  # le module template fonctionne de manière similaire à copy (vu plus haut)
  # mais il injecte dynamiquement les variables nécessaires
  - name: write the apache config file
    template:
      src: /Users/Buzut/.ansible/templates/vhost.conf
      dest: /etc/apache2/sites-available/buzut.conf

  - name: enable vhost
    command: a2ensite buzut

  - name: restart apache
    service:
      name: httpd
      state: restarted

Pour que vous compreniez bien le fonctionnement des variables, voici à quoi ressemble le fichier de template vhost.conf :

<VirtualHost *:{{ http_port }}>
    ServerAdmin webmaster@{{ domain }}
    ServerName {{ domain }}
    ServerAlias www.{{ domain }}
    DocumentRoot /var/www/{{ domain }}

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory /var/www/{{ domain }}/>
       Options -Indexes +FollowSymLinks
       AllowOverride All
    </Directory>
</VirtualHost>

Comme expliqué en commentaire, le module template charge le fichier de template et pour chaque {{ variable }}, injecte la valeur correspondante depuis les variables définies au début. Vous rendez-vous compte de la puissance de la chose ?!

I-D-1. Les variables▲

ansible buzut -m setup
buzut | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "37.59.21.45"
        ], 
        "ansible_all_ipv6_addresses": [
            "2001:41d0:8:852d::", 
            "fe80::225:90ff:fe7c:fa36"
        ], 
        "ansible_architecture": "x86_64", 
        "ansible_bios_date": "01/03/2014", 
        "ansible_bios_version": "3.0a", 
        […]
        "ansible_lsb": {
            "codename": "trusty", 
            "description": "Ubuntu 14.04.4 LTS", 
            "id": "Ubuntu", 
            "major_release": "14", 
            "release": "14.04"
        }, 
       […]

# variable simple
{{ ansible_architecture }}

# pour accéder à une propriété
{{ ansible_lsb.major_release }}

# pour accéder à un tableau (première propriété)
{{ ansible_all_ipv4_addresses[0] }}

---
- hosts: buzut
  tasks:
    - name: determine vhosts
      command: /bin/ls /etc/apache2/sites-enabled/
      register: vhosts

    ---
    - hosts: "{{ servernames }}"
      vars_prompt:
        - name: "servernames"
          prompt: "Which hosts would you like to setup?"
          private: no
      tasks:
        […]

    ---
    - hosts: "{{ servernames }}"
      tasks:
        […]

    # ici la variable doit être entourée de guillemets
    - hosts: "{{ servernames }}"
      tasks:
        […]

    # mais pas dans ce cas là
    - name: Enable VirtualHost
      file:
        src: /etc/nginx/sites-available/{{ domain }}
        dest: /etc/nginx/sites-enabled/{{ domain }}
        state: link

---
- hosts: buzut
  tasks:
    - name: determine vhosts
      command: /bin/ls /etc/apache2/sites-enabled/
      register: vhosts
    - debug: msg="{{ vhosts }}"

---
# on lance le playbook
ansible-playbook test.yml 

PLAY ***************************************************************************

TASK [setup] *******************************************************************
ok: [buzut]

TASK [determine vhosts] ********************************************************
changed: [buzut]

TASK [debug] *******************************************************************
ok: [buzut] => {
    "msg": {
        "changed": true, 
        "cmd": [
            "/bin/ls", 
            "/etc/apache2/sites-enabled"
        ], 
        "delta": "0:00:00.014652", 
        "end": "2016-03-24 23:21:32.612755", 
        "rc": 0, 
        "start": "2016-03-24 23:21:32.598103", 
        "stderr": "", 
        "stdout": "buzut.conf\default.conf", 
        "stdout_lines": [
            "buzut.conf", 
            "default.conf"
        ], 
        "warnings": []
    }
}

PLAY RECAP *********************************************************************
cloud                      : ok=3    changed=1    unreachable=0    failed=0

I-D-2. Les boucles▲

---
- hosts: webserver
  vars:
    http_port: 80
    domain: buzut.fr
  remote_user: root
  tasks:
    […]
    - name: determine vhosts
      command: /bin/ls /etc/apache2/sites-enabled/
      register: vhosts

    # on enlève le (ou les) vhosts par défaut
    - name: deregister default vhosts
      command: a2dissite {{ item }}
      with_items: 
        - "{{ vhosts.stdout_lines }}"

    # maintenant on peut rajouter notre vhost
    - name: enable vhost
      command: a2ensite buzut
    […]

I-D-3. Le notify pattern▲

---
- hosts: webserver

  vars:
    http_port: 80
    domain: buzut.fr
  remote_user: root

  tasks:
    […]
    - name: determine vhosts
      command: /bin/ls /etc/apache2/sites-enabled/
      register: vhosts

    - name: deregister default vhosts
      command: a2dissite {{ item }}
      with_items: 
        - "{{ vhosts.stdout_lines }}"
      notify:
        - restart apache2

    - name: enabled mod_rewrite
      apache2_module:
        name: rewrite
        state: present
      notify:
        - restart apache2

    - name: enable vhost
      command: a2ensite buzut
      notify:
        - restart apache2
    […]

    handlers:
    - name: restart apache2
      service: 
        name: apache2 
        state: restarted

L'include dans Ansible, c'est exactement comme le include de PHP. Cela vous permet de scinder vos tâches en différents fichiers et de les importer au besoin dans vos playbooks. Imaginez par exemple que vous ayez une tâche qui se charge d'installer un dæmon de monitoring, vous voudrez certainement qu'elle s'exécute aussi bien sur vos serveurs de base de données, que sur vos serveurs front, etc.

Sans l'include, vous devriez répéter ça dans tous vos playbooks, tandis qu'avec cette petite magie, une simple référence suffit.

On définit donc nos tâches dans un fichier dédié, on l'appelle pour l'exemple setupMonitoring.yml.

---
- name: Install monitoring agent
  apt:
    name: blabla

# on ajoute toutes les tâches que l'on veut

Comme ce fichier sera intégré directement dans un playbook, nous n'avons pas à référencer tasks:, nous plaçons directement notre liste de tâches.

Une fois ce fichier créé et enregistré, admettons pour l'exemple que nous enregistrions toutes nos tâches dans tasks et que les playbooks soient à la racine, voici à quoi ressemblerait notre playbook :

---
- hosts: dbservers
  vars:
    email: mon@email.fr

  vars_prompt:
    - name: "dbrootpasswd"
      prompt: "Database root password"

  tasks:
    - include: tasks/commonSetup.yml
    - include: tasks/setupMonitoring.yml
    - include: tasks/installMySQL.yml

    # on peut bien entendu mélanger des includes et des tâches classiques
    - name: Install htop
      apt:
        name: htop

Il y a quelque chose que je ne vous ai pas dit concernant les includes. Nous avons vu comment inclure des tâches, mais l'on peut aussi inclure des playbooks. Tout dépend de l'endroit où l'include est utilisé.

Dans l'exemple précédent, nous l'avons inséré après tasks:, il est donc évident qu'il ne peut inclure que des tâches. Cependant, s'il est inséré au premier niveau du playbook, il insèrera un playbook. Il est ainsi possible de créer des meta-playbooks. Attention cependant, car la syntaxe de ces fichiers devra être celle d'un playbook !

C'est simple, mais redoutable de puissance ! Depuis sa version 1.2, Ansible a mis en place un mécanisme qui pousse encore plus loin cette logique afin de rendre les playbooks plus organisés, plus clairs et plus réutilisables, j'ai nommé : les rôles.

Les rôles constituent un moyen d'automatiser le chargement des variables, des tâches et des handlers grâce à une convention d'arborescence de fichiers. C'est une automatisation des includes qui permet une grande souplesse et une très bonne organisation des tâches complexes. J'y consacre un article entierTirer toute la puissance d'Ansible avec les rôles !

C'est une bonne pratique de versionner ses scripts Ansible. Cependant, qui dit versionning, dit souvent dépôt distant. Il va sans dire que certains éléments de configurations ne sont pas à laisser en clair sur n'importe quel dépôt : clef ssh, fichiers de conf avec mot de passe, etc.

D'une part, tous les collaborateurs n'ont pas forcement à y avoir accès, d'autre part, un Gitlab ou Github, même avec un dépôt privé et même s'il est installé sur vos serveurs, peut toujours être compromis.

Bien entendu, séparer les fichiers sensibles est envisageable. Mais vous n'aurez pas le confort d'avoir l'intégralité de vos éléments d'install ou deploy d'un simple petit coup de git clone, ou équivalent avec SNV ou Mercurial.

Pour répondre à cette problématique, Ansible propose un coffre - Vault dans la langue de Shakespeare. Vous spécifiez un mot de passe et Ansible chiffre le fichier (par défaut en AES). Lors de l'édition de fichiers, Ansible ouvrira votre l'éditeur défini dans la variable $EDITOR. Veillez à en définir un si ce n'est pas fait. Le cas échéant, votre fichier sera ouvert avec vi.

L'usage du vault est très simple. Vous n'aurez que quatre commandes à retenir :

# chiffrer des fichiers
ansible-vault encrypt fichierA [fichierB …]

# afficher un fichier
ansible-vault view fichierA [fichierB …]

# éditer un fichier déjà chiffré
ansible-vault edit fichierA

# si jamais vous avez envie de déchiffrer un fichier précédemment chiffré
ansible-vault decrypt ficherA [fichierB …]

Lorsque vous désirez lancer un playbook qui nécessitera d'utiliser des fichiers présents dans le vault, il faudra passer l'option --ask-vault-pass.

Enfin, il est possible d'utiliser des mots de passe différents pour différents fichiers. Cependant, tous les fichiers utilisés au sein d'un même Playbook doivent partager le même mot de passe.

Négligeable quand vous n'avez que quelques serveurs à traiter, les réglages qui influent sur les performances peuvent avoir un impact important en termes de temps d'exécution si vous gérez un parc de serveurs important. Passons en revue les optimisations qui permettent de doper les performances d'Ansible. Tout va se passer dans le fichier de config /etc/ansible/ansible.cfg ou /opt/local/etc/ansible/ansible.cfg.default (qu'il faudra d'ailleurs renommer pour lui enlever .default) sur OS X.

I-G-1. Forks▲

forks=20

I-G-2. Pipelining▲

pipelining=True

I-G-3. Exécution asynchrone et polling▲

# compilation du codec video x264, qui peut être assez longue
- name: compile x264
  environment: ffmpeg_env
  command: "{{ item }}"
  args:
    chdir: "{{ ffmpeg_source_dir }}/x264"
    creates: "{{ ffmpeg_bin_dir }}/x264"
  with_items:
    - ./configure --prefix={{ ffmpeg_build_dir }} --bindir={{ ffmpeg_bin_dir }} --enable-static
    - make
    - make install
    - make distclean
  # on déclare le temps maximum d'exécution
  async: 120
  # et intervalle de temps auquel vérifier l'état de l'opération
  poll: 10