Ansible : Quirks

Variables Utiles & Quirks divers

Ansible contient des variable globales assez utiles. Il contient également beaucoup de fonctions particulières et part un peu dans tous les sens; cependant, on trouve toujours réponse à ses problèmes.

Ne pas avoir à ajouter l'hôte au fichier known_hosts

Ajouter dans la partie [group:vars]:

ansible_ssh_common_args='-o StrictHostKeyChecking=no'

Des caractères spéciaux dans les mots de passe

En cas d'utilisation d'un fichier d'inventaire chiffré contenant des mots de passe, il faut que ceux-ci soient entre simples quotes afin d'éviter que les caractères spéciaux comme $ ne soient interprétés.

blocks

- name: Attempt and graceful roll back demo
  block:
    - debug:
        msg: 'I execute normally'
    - name: i force a failure
      command: /bin/false
    - debug:
        msg: 'I never execute, due to the above task failing, :-('
  rescue:
    - debug:
        msg: 'I caught an error'
    - name: i force a failure in middle of recovery! >:-)
      command: /bin/false
    - debug:
        msg: 'I also never execute :-('
  always:
    - debug:
        msg: "This always executes"

tags

Il est possible de taguer des tâches afin de "faire du tri". Le but est de pouvoir choisir de n'exécuter par exemple que certains tags (avec --tags), ou de les éviter (avec --skip-tags). Ajouter des tags sur des tâches individuelles est assez simple :

<syntaxhighlight lang='yaml'> tasks: - yum:

   name: "Modèle:Item"
   state: present
 loop:
 - httpd
 - memcached
 tags:
 - packages

- template:

   src: templates/src.j2
   dest: /etc/foo.conf
 tags:
 - configuration

</syntaxhighlight>

Bien entendu, on peut appliquer le même tag à plusieurs tâches.

Héritage des tags

L'héritage de tags, c'est le fait d'ajouter à un play, des tâches importées, ou autre... des tags qui seront appliqués à toutes les tâches incluses. Cela se fait avec la syntaxe "tags: " :

<syntaxhighlight lang='yaml'> - hosts: all

 tags:
 - bar
 tasks:
   ...

- hosts: all

 tags: [ foo ]
 tasks:
   ...

</syntaxhighlight>

Accéder à la documentation

La documentation est intégrée ! Il suffit d'utiliser Ansible-doc :

<syntaxhighlight lang='bash'> [justine@argonaut filetree]$ ansible-doc --help Usage: ansible-doc [-l|-F|-s] [options] [-t <plugin type> ] [plugin]

plugin documentation tool

Options:

 -h, --help            show this help message and exit
 -j, --json            **For internal testing only** Dump json metadata for
                       all plugins.
 -l, --list            List available plugins
 -F, --list_files      Show plugin names and their source files without
                       summaries (implies --list)
 -M MODULE_PATH, --module-path=MODULE_PATH
                       prepend colon-separated path(s) to module library (def
                       ault=~/.ansible/plugins/modules:/usr/share/ansible/plu
                       gins/modules)
 -s, --snippet         Show playbook snippet for specified plugin(s)
 -t TYPE, --type=TYPE  Choose which plugin type (defaults to module).
                       Available plugin types are : ('become', 'cache',
                       'callback', 'cliconf', 'connection', 'httpapi',
                       'inventory', 'lookup', 'shell', 'module', 'strategy',
                       'vars')
 -v, --verbose         verbose mode (-vvv for more, -vvvv to enable
                       connection debugging)
 --version             show program's version number, config file location,
                       configured module search path, module location,
                       executable location and exit

See man pages for Ansible CLI options or website for tutorials https://docs.ansible.com </syntaxhighlight>

Le module find

Le module find est un peu casse-pieds. Il si je le register dans "fichiers", alors ma variable fichiers contiendra une liste appellée "files" (et d'autres : cf la doc), laquelle sera une liste de collection clefs-valeurs :

<syntaxhighlight lang="yaml">

       [
       { path: "/var/tmp/test1",
         mode: "0644",
         "...": "...",
         checksum: 16fac7be61a6e4591a33ef4b729c5c3302307523
       },
       { path: "/var/tmp/test2",
         "...": "..."
       },
       ]

</syntaxhighlight>

Y accéder est un peu embêtant. Mettons que j'ai besoin d'accéder au path, je peux faire ça :

<syntaxhighlight lang='yaml'> --- - hosts: all

 become: true
 tasks:

   - name: Récupérer les fichiers
     find:
       patterns: "*log"
       paths: /var/log
       recurse: yes
     register: fichiers

   - name: debuggage
     debug:
       msg: "Modèle:Item.path"
     with_items: "Modèle:Fichiers.files"

</syntaxhighlight>

Mais bon, ce n'est pas génial... Ici, on doit faire une itération sur la liste et extraire les paths à chaque fois.

On peut aussi utiliser un filtre Jinja2:

<syntaxhighlight lang='yaml'> --- - hosts: all

 become: true
 tasks:

   - name: Récupérer les fichiers
     find:
       patterns: "*log"
       paths: /var/log
       recurse: yes
     register: fichiers

   - name: debuggage
     debug:
       msg: "{{ fichiers['files'] | map(attribute='path') | list }}"     

</syntaxhighlight>

Cette fois-ci, on a une liste de tous les paths. Mais bon, ce n'est pas génial non plus. Si j'avais des listes dans des listes, je devrais utiliser with_nested.

Assigner des variables au milieu d'un playbook

Pour cela, il faut utiliser le module set_fact. En reprenant l'exemple juste avant :

<syntaxhighlight lang='yaml'> --- - hosts: all

 become: true
 tasks:

   - name: Récupérer les fichiers
     find:
       patterns: "*log"
       paths: /var/log
       recurse: yes
     register: fichiers

   - name: Une nouvelle variable  
     set_fact:
       chemins: "{{ fichiers['files'] | map(attribute='path') | list }}"

   - name: debuggage
     debug:
       msg: "Modèle:Chemins"     

</syntaxhighlight>