Extension VS Code Ansible (v26.4 / 2026) : autocomplétion, lint, Lightspeed, MCP server

L’extension officielle Red Hat « Ansible » pour Visual Studio Code transforme l’éditeur en un véritable IDE Ansible. En version 26.4.4 (avril 2026), elle apporte : autocomplétion FQCN sur les modules de toutes vos collections installées, validation ansible-lint en temps réel, navigation vers la documentation officielle au survol, content creation tools (créer collections / playbooks / EE depuis l’UI), support natif des Dev Containers, assistance IA via Ansible Lightspeed, et un nouveau MCP server (Model Context Protocol) pour l’intégration avec les agents IA. Cette page couvre l’installation propre sur AlmaLinux 10 / Ubuntu 24.04, la configuration recommandée, et les pièges 2026.

Pressé ? Setup en 4 commandes

# 1. Prérequis : Ansible + ansible-lint via pipx (si pas déjà fait)
pipx install --include-deps ansible
pipx install ansible-lint

# 2. Installer l'extension VS Code (CLI ou via UI)
code --install-extension redhat.ansible

# 3. Vérifier que VS Code voit ansible-lint
which ansible-lint    # doit être dans ~/.local/bin/

# 4. Ouvrir un fichier .yml dans un dossier Ansible — l'extension auto-détecte
code labs/premiers-pas/premier-playbook/site.yml

Sécurité non négociable :

• pipx plutôt que pip --user ou apt install ansible — isolation, pas de pollution Python globale, mises à jour atomiques.
• Vérifier le python.interpreterPath dans Settings VS Code — sinon l’extension utilise un Python aléatoire et échoue silencieusement sur l’autocomplétion des collections installées via pipx.
• Lightspeed nécessite un compte Red Hat + acceptation des CGU + envoi de votre code à un service tiers. Désactivable via ansible.lightspeed.enabled: false si vous bossez sur du code propriétaire/classifié.
• Trust Workspace : refuser sur du code inconnu — un ansible.cfg malveillant peut exécuter des commandes au démarrage de l’extension.

Ce que vous allez apprendre

• Installer l’extension officielle Red Hat sur VS Code 1.94+ et configurer l’interpréteur Python.
• Activer la détection automatique des fichiers Ansible (associations YAML) sans renommer en .ansible.yml.
• Brancher ansible-lint en temps réel pour voir les erreurs dans l’éditeur.
• Utiliser l’autocomplétion FQCN, les snippets et la navigation vers la doc.
• Comprendre le périmètre et les limites d’Ansible Lightspeed (IA, accès gated, code envoyé au cloud).
• Découvrir les Content Creation Tools (collections, playbooks, EE depuis l’UI).
• Activer le MCP server pour intégrer Ansible à un agent IA externe.

Prérequis

Élément	Vérification
VS Code 1.94+	code --version
Ansible Core 2.18+ installé via pipx	ansible --version
ansible-lint 25+	ansible-lint --version
Python 3.12+	python3 --version
Compte Red Hat (pour Lightspeed, optionnel)	redhat.com/account

Glissez pour voir

Installation de l’extension

VS Code Marketplace (recommandé)

# CLI
code --install-extension redhat.ansible

# Ou via l'UI : Ctrl+Shift+X → rechercher "Ansible" → publisher Red Hat

L’éditeur officiel est Red Hat (badge bleu vérifié). Méfiez-vous des extensions tierces qui s’appellent aussi « Ansible » — elles sont souvent abandonnées ou incomplètes. La version actuelle disponible est v26.4.4 (avril 2026).

Open VSX (VS Codium / Cursor / Windsurf)

# Sur les forks open-source de VS Code
codium --install-extension redhat.ansible

L’extension est aussi publiée sur Open VSX Registry. Aucune fonctionnalité n’est manquante par rapport à la version Marketplace.

L’extension installe automatiquement l’Ansible Language Server (ALS), qui est le moteur derrière l’autocomplétion, la validation et la navigation. Le binaire ALS vit dans ~/.vscode/extensions/redhat.ansible-*/out/server/.

Configuration recommandée 2026

Ouvrez ~/.config/Code/User/settings.json (ou Ctrl+, puis cliquer sur l’icône {} en haut à droite) et ajoutez :

{
  "ansible.python.interpreterPath": "/home/<vous>/.local/share/pipx/venvs/ansible/bin/python3",
  "ansible.validation.enabled": true,
  "ansible.validation.lint.enabled": true,
  "ansible.validation.lint.path": "/home/<vous>/.local/bin/ansible-lint",
  "ansible.completion.provideRedirectModules": true,
  "ansible.completion.provideModuleOptionAliases": true,
  "ansible.executionEnvironment.enabled": false,
  "files.associations": {
    "*.yml": "ansible",
    "*.yaml": "ansible",
    "*.j2": "jinja"
  },
  "redhat.telemetry.enabled": false
}

Trois points à connaître :

1. ansible.python.interpreterPath doit pointer sur le Python utilisé par pipx pour Ansible. Sans ça, l’extension cherche les collections au mauvais endroit. Trouvez le bon chemin :

   pipx environment --value PIPX_LOCAL_VENVS
   # → /home/bob/.local/share/pipx/venvs
   
   ls /home/bob/.local/share/pipx/venvs/ansible/bin/python3
   # → c'est ce chemin qu'il faut mettre dans interpreterPath

2. files.associations force VS Code à reconnaître tous les .yml/.yaml du workspace comme Ansible. Vous pouvez aussi le faire au niveau projet dans .vscode/settings.json pour ne pas polluer la config globale.

3. redhat.telemetry.enabled: false désactive la télémétrie Red Hat (par défaut activée) — recommandé pour le dev sur du code sensible.

Le piège du mauvais Python

Si l’extension affiche Module not found: ansible.posix.firewalld alors que la collection est installée, 9 fois sur 10 c’est l’interpréteur Python qui est mal configuré. Vérifier dans VS Code : Ctrl+Shift+P → Ansible: Show Status affiche le Python actif et les paths résolus.

Détection des fichiers Ansible

Trois mécanismes coexistent (l’un suffit, les autres servent de fallback) :

1. Sans inspection (associations explicites)

"files.associations": {
  "*.yml": "ansible",
  "*.yaml": "ansible"
}

Avantage : tous les YAML du workspace passent en mode Ansible. Inconvénient : un docker-compose.yml ou un helmfile.yaml est aussi traité comme Ansible (faux positifs sur le lint).

2. Inspection du contenu (recommandée)

L’extension détecte automatiquement les mots-clés Ansible (hosts:, tasks:, roles:, vars:) en début de fichier YAML et bascule en mode Ansible uniquement pour ces fichiers.

3. Modeline en début de fichier

Pour forcer la détection sur un fichier ambigu :

# code: language=ansible
---
- hosts: webservers
  tasks: ...

La ligne de commentaire est lue par VS Code au chargement.

Validation ansible-lint en temps réel

Une fois l’extension activée, ouvrez un fichier YAML Ansible — les erreurs ansible-lint apparaissent en temps réel dans le panneau Problems (Ctrl+Shift+M) et avec des soulignés rouges/jaunes inline.

# Avant correction (3 warnings ansible-lint)
- name: Install package
  yum:                  # ⚠️ name[deprecated-module] → utiliser dnf
    name: nginx
    state: latest       # ⚠️ package-latest (devrait être present)

# Après auto-fix (Ctrl+. → "ansible-lint: Fix")
- name: Install package
  ansible.builtin.dnf:  # ✅ FQCN moderne
    name: nginx
    state: present      # ✅ pas d'upgrade silencieux

Profil par défaut : production (le plus strict). Pour relâcher temporairement (formation, exploration) :

"ansible.validation.lint.arguments": "--profile basic"

Autocomplétion FQCN intelligente

L’extension liste tous les modules de toutes vos collections installées — ansible.builtin.*, ansible.posix.*, community.general.*, plus celles de votre requirements.yml projet. Tapez le début du nom dans une ligne de tâche, l’autocomplétion propose les FQCN avec une description courte.

- name: Configurer firewalld
  ansible.posix.firewa█      # Ctrl+Espace
  # → ansible.posix.firewalld (Manage firewalld zones, services and ports)

L’autocomplétion s’améliore avec les modules ayant un argument_specs.yml : elle propose les paramètres avec leur type et leurs valeurs valides (choices: [...]). Pour les rôles que vous écrivez vous-même, ajouter meta/argument_specs.yml est donc un investissement double : validation runtime + autocomplétion VS Code.

L’option provideRedirectModules: true active aussi la résolution des redirects (meta/runtime.yml plugin_routing.redirect) — quand un module est renommé/déplacé entre collections, l’extension propose le nouveau nom plutôt que l’ancien.

Auto-closing Jinja expressions

Quand vous tapez {{ dans un template, l’extension complète automatiquement avec }} et place le curseur entre les deux. Idem pour {% %} (logique) et {# #} (commentaire). Un détail, mais qui évite les coupures de syntaxe Jinja les plus fréquentes.

Documentation reference

Survol d’un nom de module dans l’éditeur → tooltip avec :

• Les paramètres requis (en gras)
• Les valeurs par défaut
• La version Ansible mini requise (version_added)
• Un exemple copiable
• Lien vers la doc officielle ansible.com

Cette feature seule justifie l’extension — vous ne quittez plus VS Code pour aller chercher la doc.

Jump to module code

F12 ou Ctrl+Shift+P → Go to Definition ouvre :

• Pour un module builtin : la doc officielle
• Pour un module custom dans votre collection : le fichier Python source
• Pour un rôle : le tasks/main.yml du rôle

Pratique pour debugger un comportement étrange : aller voir directement le code Python du module.

Content Creation Tools (depuis l’UI)

Depuis fin 2024, l’extension intègre des scaffolders accessibles via la palette de commandes (Ctrl+Shift+P) :

Commande	Crée
Ansible: Create Collection	Squelette d’une collection complète (galaxy.yml, plugins/, roles/, meta/runtime.yml)
Ansible: Create Playbook	Playbook vide ou pré-rempli
Ansible: Create AI Playbook (Lightspeed requis)	Playbook généré par IA depuis une description en français
Ansible: Create Playbook Project	Structure complète projet (ansible.cfg, inventory/, playbooks/, roles/)
Ansible: Create Execution Environment	execution-environment.yml v3 + requirements.yml + bindep.txt

Glissez pour voir

Pratique pour démarrer rapidement un projet sans Googler la structure standard.

Dev Containers support

L’extension fonctionne nativement dans un Dev Container (image OCI fournissant l’environnement de dev). Idéal pour :

• Onboarding équipe : un .devcontainer/devcontainer.json + l’extension = tout le monde a le même Ansible/lint/Python.
• CI/CD reproductible : la même image consommée en local et en pipeline.

.devcontainer/devcontainer.json

{
  "image": "mcr.microsoft.com/devcontainers/python:3.12",
  "customizations": {
    "vscode": {
      "extensions": ["redhat.ansible"]
    }
  },
  "postCreateCommand": "pipx install --include-deps ansible && pipx install ansible-lint"
}

Avec Reopen in Container, VS Code redémarre dans le conteneur — Ansible, lint, et l’extension prêts à l’emploi.

Ansible Lightspeed (IA, optionnel)

L’extension intègre Ansible Lightspeed, l’assistance IA développée par Red Hat. Elle propose des suggestions de tâches à partir d’un commentaire ou d’un name: rédigé.

# Saisissez le commentaire en français, puis Ctrl+I (ou attente auto)
# Installer nginx, ouvrir le port 80 dans firewalld, démarrer le service

# Lightspeed propose :
- name: Installer nginx
  ansible.builtin.dnf:
    name: nginx
    state: present
- name: Ouvrir le port 80 dans firewalld
  ansible.posix.firewalld:
    service: http
    permanent: true
    immediate: true
    state: enabled
- name: Démarrer et activer nginx
  ansible.builtin.systemd_service:
    name: nginx
    state: started
    enabled: true

Conditions d’usage 2026 :

• Compte Red Hat actif + acceptation des CGU Lightspeed.
• Code envoyé à un service tiers Red Hat pour génération — incompatible avec du code propriétaire / classifié sans accord explicite.
• Gating géographique : non disponible dans certains pays (vérifier la liste à jour sur redhat.com/lightspeed).

Activation :

"ansible.lightspeed.enabled": true,
"ansible.lightspeed.URL": "https://c.ai.ansible.redhat.com"

Désactivation propre :

"ansible.lightspeed.enabled": false,
"ansible.lightspeed.suggestions.enabled": false

Lightspeed n'est pas un substitut à la compétence

Lightspeed produit du YAML qui ressemble à un playbook idempotent. Il ne sait pas pourquoi votre handler ne se déclenche pas, ni si command: casse l’idempotence dans votre contexte précis. Utilisez-le pour démarrer, jamais pour shipper en prod sans relecture experte. C’est un assistant, pas un remplaçant.

MCP Server (nouveauté 2026)

Depuis la version 26.x, l’extension expose un Model Context Protocol (MCP) server. Le MCP est un standard ouvert (Anthropic) qui permet à des agents IA externes (Claude Desktop, Cursor, etc.) de consommer les capacités de l’extension : autocomplétion, validation, génération de playbook.

Cas d’usage typique : un agent IA en CLI peut interroger « la liste des modules ansible.posix avec leur description » via le MCP server local, sans avoir à parser la doc officielle.

"ansible.mcpServer.enabled": true,
"ansible.mcpServer.port": 8765

Sécurité : le serveur MCP écoute en local par défaut (pas exposé réseau). Bloquer l’accès LAN avec un firewall si vous travaillez sur des projets multi-utilisateurs sur la même machine.

Détection des Execution Environments

L’extension peut valider votre playbook contre un Execution Environment plutôt que votre Ansible local — utile quand votre EE de prod a des collections différentes :

"ansible.executionEnvironment.enabled": true,
"ansible.executionEnvironment.image": "quay.io/ansible/creator-ee:latest",
"ansible.executionEnvironment.containerEngine": "podman"

L’extension utilise alors ansible-navigator pour valider la syntaxe et l’autocomplétion. Ralentit visiblement l’éditeur (chaque keystroke peut déclencher un round-trip Podman) — réservé aux projets prod où la cohérence avec l’EE est critique. Désactiver en dev, activer en validation pré-merge.

Pièges fréquents

Symptôme	Cause	Fix
Module not found: ansible.posix.firewalld	Mauvais python.interpreterPath	Pointer vers le venv pipx d’ansible
Pas de surlignage YAML	files.associations manquante ou détection contenu KO	Ajouter "*.yml": "ansible" ou modeline # code: language=ansible
ansible-lint ne tourne pas	lint.path introuvable	which ansible-lint puis chemin absolu
Autocomplétion lente	EE activé inutilement en dev	executionEnvironment.enabled: false
Pas de Lightspeed	Compte non lié	Ctrl+Shift+P → Ansible Lightspeed: Sign In
Erreurs ALS au démarrage	Cache extension corrompu	Ctrl+Shift+P → Developer: Reload Window

Glissez pour voir

À retenir

• Extension officielle Red Hat : redhat.ansible sur Marketplace ou Open VSX, version actuelle 26.4.4 (avril 2026).
• ansible.python.interpreterPath doit pointer sur le venv pipx — c’est la config qui rate le plus.
• Validation ansible-lint en temps réel + autocomplétion FQCN = double levier productivité/qualité.
• Content Creation Tools depuis la palette de commandes pour créer rapidement collections / playbooks / EE.
• Lightspeed = optionnel, code envoyé à un service tiers, compte Red Hat requis.
• MCP Server (nouveauté 2026) : intégration avec agents IA externes via le standard Anthropic.
• executionEnvironment.enabled: false en dev (lent), true seulement en validation pré-merge.

Pour aller plus loin

Steampunk Spotter L'autre outil qualité Ansible — lint cloud étendu, scoring qualité, recommandations multi-versions

ansible-lint production profile Le profil strict pour CI/CD — référence des 80+ règles activées

argument_specs.yml Pour booster l'autocomplétion VS Code sur vos rôles maison

Execution Environments Valider votre code contre l'EE de prod plutôt que l'Ansible local

Ressources officielles

• Documentation officielle vscode-ansible
• Repo GitHub ansible/vscode-ansible — issues, releases, contributions
• Marketplace Red Hat Ansible
• Open VSX Registry — version Open Source des forks VS Code
• Ansible Lightspeed — détails et conditions d’usage

×

📖 Voir la documentation →