ansible-later lint vos playbooks Ansible

Ansible—later est comme ansible-lint un outil qui va scanner votre code Ansible à la recherche de portion de code ne respectant pas les meilleures pratiques.

Cela se révèle indispensable si vous souhaitez partager vos rôles Ansible avec votre équipe et pourquoi pas avec la communauté Ansible en les publiant sur Ansible-Galaxy.

Il scanne le code des fichiers d’inventaire, des fichiers de rôle, du code python (modules, plugins) et des playbooks Ansible.

Installation d’Ansible-Later

Ansible-later est écrit en python et donc le plus simple pour l’installer est d’utiliser pip :

pip install ansible-later --user

Lancement du lint de votre code Ansible

Ansible-lint possède tous les paramètres et options permettant définir les règles à respecter, à ignorer, mais aussi à utiliser vos propres règles que vous aurez écrites au préalable.

Bien sûr, il est possible de le lancer directement sans argument :

# Scan tous les fichiers yaml
ansible-later
# Vérfie le code d'un seul fichier
ansible-later meta/main.yml tasks/install.yml

# Idem que par défaut
ansible-later **/*.yml

Il utilisera ces paramètres :

---
ansible:
  # Add the name of used custom Ansible modules. Otherwise ansible-later
  # can't detect unknown modules and will through an error.
  # Modules which are bundled with the role and placed in a './library'
  # directory will be auto-detected and don't need to be added to this list.
  custom_modules: []

  # Settings for variable formatting rule (ANSIBLE0004)
  double-braces:
    max-spaces-inside: 1
    min-spaces-inside: 1

  # List of allowed literal bools (ANSIBLE0014)
  literal-bools:
    - "True"
    - "False"
    - "yes"
    - "no"

  # List of modules that don't need to be named (ANSIBLE0006).
  # You must specify each individual module name, globs or wildcards do not work!
  named-task:
    exclude:
      - "meta"
      - "debug"
      - "block"
      - "include_role"
      - "include_tasks"
      - "include_vars"
      - "import_role"
      - "import_tasks"

  # List of modules that are allowed to use the key=value format instead of the native YAML format (LINT0008).
  # You must specify each individual module name, globs or wildcards do not work!
  native-yaml:
    exclude: []

# Global logging configuration
# If you would like to force colored output (e.g. non-tty)
# set environment variable `PY_COLORS=1`
logging:
  # You can enable JSON logging if a parsable output is required
  json: False

  # Possible options debug | info | warning | error | critical
  level: "warning"

# Global settings for all defined rules
rules:
  # Disable build-in rules if required
  buildin: True

  # List of files to exclude
  exclude_files: []
  # Examples:
  #  - molecule/
  #  - files/**/*.py

  # Limit checks to given rule ID's
  # If empty all rules will be used.
  filter: []

  # Exclude given rule ID's from checks
  exclude_filter: []

  # List of rule ID's that should be displayed as a warning instead of an error. By default,
  # only rules whose version is higher than the current default version are marked as warnings.
  # This list allows to degrade errors to warnings for each rule.
  warning_filter:
    - "ANSIBLE9999"

  # All dotfiles (including hidden folders) are excluded by default.
  # You can disable this setting and handle dotfiles by yourself with `exclude_files`.
  ignore_dotfiles: True

  # List of directories to load standard rules from (defaults to build-in)
  standards: []

  # Standard version to use. Standard version set in a roles meta file
  # or playbook will takes precedence.
  version:

# Block to control included yamllint rules.
# See https://yamllint.readthedocs.io/en/stable/rules.html
yamllint:
  colons:
    max-spaces-after: 1
    max-spaces-before: 0
  document-start:
    present: True
  empty-lines:
    max: 1
    max-end: 1
    max-start: 0
  hyphens:
    max-spaces-after: 1
  indentation:
    check-multi-line-strings: False
    indent-sequences: True
    spaces: 2

En y regardant de plus près certaines options me dérange et donc je vous montre comment les modifier :

Modification du paramétrage

C’est assez simple il suffit de créer un fichier de config redéfinissant les paramètres à modifier, Ce fichier doit se nommer .later.yml :

---
ansible:
  literal-bools:
    - "True"
    - "False"
rules:
  warning_filter:
    - "ANSIBLE9999"
  exclude_filter:
    - "LINT0009"

Je ne veux pas que les booléens soient écrits sous la forme yes ou no. J’exclus la règle obligeant la présence des ... en fin de fichier.

Exclure des taches au contrôle

Pour exclure des taches de cette analyse, c’est assez simple, il suffit d’ajouter le tag : skip_ansible_later à la tâche en question :

- name: Tache à exclure (pas bien!)
  command: "sudo apt update"
  tags:
    - skip_ansible_later

Écrire ses propres règles

Dès que j’aurais une règle, j’ajouterai mon exemple. En attendant je vous renvoie à la documentation qui est assez sommaire.

Conclusion

Vous allez me dire pourquoi utiliser ansible-later plûtot qu’ansible-lint et bien je n’ai pas la réponse pour le moment, car je n’ai pas assez de recul dessus. Je vais le tester durant mes prochains développements et je vous donnerai mon avis à ce moment-là.