ansible-lint profile production : configuration stricte pour rôles publiés

ansible-lint --profile=production est le filtre qualité le plus strict d'ansible-lint. Il cumule les règles des cinq profils précédents et y ajoute les siennes : FQCN partout, pas de dépendances dans meta/main.yml, un seul point d'entrée par rôle, loop: plutôt que with_items:. Tout rôle destiné à publication doit passer ce profil.

Cette page configure ansible-lint, yamllint et pre-commit ensemble, la stack qualité 2026 pour un rôle Ansible.

Ce que vous allez apprendre

• Les 6 profils d'ansible-lint (min → production).
• Configurer .ansible-lint avec exclude_paths, warn_list, mock_modules.
• Configurer .yamllint strict (pas de yes/no ambigus).
• Pre-commit hooks pour bloquer les commits non conformes.
• Tester le linter en local et en CI.

Les 6 profils ansible-lint

min → basic → moderate → safety → shared → production

Chaque profil englobe les règles des précédents. Plus on monte, plus c'est strict.

Profil	Cas d'usage
min	Premier déchiffrage YAML/Ansible, quasi tout passe
basic	Conventions de base (FQCN, naming)
moderate	+ idempotence, no_log, secret detection
safety	+ sécurité avancée (no shell sans creates, no_log password)
shared	+ qualité des rôles partagés (galaxy, meta-no-tags, no-changed-when, no-handler)
production	+ fqcn, meta-no-dependencies, single-entry-point, use-loop, import-task-no-when

Glissez pour voir

Le contenu exact de chaque profil se lit avec ansible-lint --list-profiles, qui affiche les règles ajoutées par chaque niveau et la phrase « It extends … profile » qui matérialise le chaînage. La liste ci-dessus est celle de la version 26.1, et elle bouge d'une version majeure à l'autre : c'est la commande qui fait foi, pas un tableau recopié.

Une règle absente de tous les profils mérite une mention, parce que la documentation la présente souvent comme un acquis du profil production : args, qui confronte les variables reçues par un rôle à son meta/argument_specs.yml. Elle ne s'active que par la clé enable_list, ce que fait la configuration de la section suivante.

Recommandation 2026 : moderate pendant le dev, production avant publication.

Le fichier .ansible-lint

Ce fichier se pose à la racine du dépôt et remplace la ligne de commande : le profil, les exclusions et les règles ajoutées y sont versionnés, donc identiques sur votre poste et sur la chaîne d'intégration. Les clés ci-dessous se rangent en trois familles, ce qui est analysé avec exclude_paths, la sévérité des règles avec skip_list et warn_list, et ce que l'environnement de lint doit faire semblant de connaître avec mock_modules.

---
profile: production

exclude_paths:
  - .cache/
  - .git/
  - molecule/
  - tests/

skip_list: []                          # règles ignorées (avec justification)

warn_list:
  - experimental                       # règles expérimentales en warn
  - role-name                          # autorise les '-' dans noms (Galaxy)

use_default_rules: true
verbosity: 1

enable_list:
  - args
  - empty-string-compare
  - no-log-password
  - no-same-owner
  - yaml

mock_modules:
  - amazon.aws.ec2_instance            # collections optionnelles non installées

mock_roles:
  - geerlingguy.docker

Champs clés :

• profile: production : la base.
• exclude_paths : chemins à ignorer (cache, tests Molecule).
• skip_list : règles à skipper (à utiliser avec parcimonie + justification en commentaire).
• warn_list : règles en warn au lieu d'erreur.
• mock_modules / mock_roles : modules/rôles cités dans le code mais non installés (évite les warnings).

Le fichier .yamllint

---
extends: default

rules:
  line-length:
    max: 160
    level: warning

  truthy:
    allowed-values:
      - "true"
      - "false"
    check-keys: false

  comments:
    min-spaces-from-content: 1

  comments-indentation: false
  document-start: enable
  empty-lines:
    max: 2

ignore: |
  .cache/
  molecule/
  .tox/

Règle critique, truthy.allowed-values: [true, false] : interdit yes/no/on/off qui sont des strings en YAML 1.2 strict (et provoquent des comportements subtils).

Pre-commit hooks

.pre-commit-config.yaml

---
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files
      - id: detect-private-key
      - id: check-merge-conflict

  - repo: https://github.com/adrienverge/yamllint.git
    rev: v1.35.1
    hooks:
      - id: yamllint
        args: [-c, .yamllint]

  - repo: https://github.com/ansible/ansible-lint
    rev: v25.1.0
    hooks:
      - id: ansible-lint
        args: ["--profile=production"]
        additional_dependencies:
          - ansible-core>=2.16

Installation :

pipx install pre-commit
pre-commit install              # active les hooks
pre-commit run --all-files      # lance sur tout le repo (1ère fois)

À partir de là, git commit déclenche automatiquement les linters. Si un hook échoue, le commit est bloqué, vous corrigez, vous re-stagez, vous re-commitez.

Lancer les linters manuellement

Le hook de commit est un filet, pas un outil de travail : pendant la correction, on veut relancer un seul linter sur un seul chemin, sans passer par un commit. Les quatre commandes ci-dessous vont du plus ciblé au plus large, et la dernière rejoue un hook précis de pre-commit sur tout le dépôt, ce qui est la façon la plus sûre de vérifier une correction avant de recommiter.

# yamllint
yamllint roles/

# ansible-lint
ansible-lint --profile=production roles/webserver/

# Pre-commit (équivalent au hook automatique)
pre-commit run --all-files

# Pre-commit hook spécifique
pre-commit run ansible-lint --all-files

Pièges courants en production

Ces sept règles sont celles qui tombent le plus souvent au premier passage en profil production, et aucune ne signale une erreur d'exécution : le playbook tourne, il est simplement non publiable. Trois portent sur la reproductibilité, no-changed-when et latest-version en tête, deux sur la sécurité des secrets et des permissions, deux sur les conventions de nommage. La colonne de droite donne la correction attendue.

Règle	Détecte	Fix
fqcn[action-core]	Module sans FQCN (dnf: au lieu de ansible.builtin.dnf:)	Toujours FQCN
args	Argument manquant requis	Ajouter le param
no-changed-when	command: sans changed_when:	Ajouter changed_when: false ou creates:
no-log-password	Variable *password* sans no_log: true	Ajouter no_log: true sur la tâche
var-naming	Variable mal nommée	snake_case + préfixe rôle
meta-no-info	meta/main.yml incomplet	Compléter galaxy_info:
latest-version	state: latest sur paquet	Pinner avec state: present, version: X

Glissez pour voir

Justifier un skip avec commentaire

- name: Lancer le script de migration legacy
  ansible.builtin.shell: /opt/migrate.sh
  args:
    creates: /var/lib/.migrated
  # noqa: command-instead-of-shell
  # Le script fait du redirect bash incompatible avec command:

# noqa: <règle> désactive localement la règle. Toujours justifier en commentaire, sinon code review bloque.

Mettre en pratique

Une configuration de lint ne prouve sa valeur que le jour où elle bloque un commit. Le lab vous fait poser les trois fichiers de cette page, .ansible-lint en profil production, un .yamllint strict et le .pre-commit-config.yaml qui les enchaîne, puis y ajouter un hook qui refuse une clé privée committée par erreur. La validation relit chaque fichier et exige que le profil, les règles strictes et le hook anti-fuite soient effectivement branchés.

Lab pratique

ansible-lint profil production avec pre-commit

$ dsoxlab run tests-ansible-lint-production

Environnement : Shell·Durée : ~40 min

Validé : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run tests-ansible-lint-production
dsoxlab check tests-ansible-lint-production

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• 6 profils ansible-lint : min → basic → moderate → safety → shared → production.
• production mandatory pour publication Galaxy.
• .yamllint : interdire yes/no (truthy.allowed-values: [true, false]).
• Pre-commit hooks = ansible-lint, yamllint, detect-private-key, check-yaml.
• # noqa: <règle> + commentaire pour skip local justifié.

Pour aller plus loin

• CI GitLab : brancher le stage de lint en amont des tests, pour un échec rapide.
• Auditer un rôle existant : appliquer ces mêmes critères à un rôle que vous n'avez pas écrit.
• Versionner et publier : le profil production est le prérequis d'une publication Galaxy.

×

📖 Voir la documentation →