RHCE EX294 — Workflow VS Code + Dev Container + ansible-navigator

Red Hat a aligné les objectifs EX294 actuels sur un workflow moderne : VS Code comme éditeur, Dev Container Ansible (image Red Hat ou communautaire) comme runtime reproductible, ansible-navigator comme orchestrateur, Git comme système de versioning. Ce trio remplace l'ancien combo « éditeur libre + ansible-playbook local + RPM RHEL » qui n'est plus supporté sur RHEL 10. Cette page détaille le pipeline complet : cloner un repo, ouvrir en Dev Container, configurer ansible-navigator.yml, lancer un playbook, pousser le code. Public visé : candidats RHCE EX294 et toute équipe DevOps qui veut un environnement Ansible reproductible. À la fin, vous aurez le même setup que celui que Red Hat utilise pour la formation AU294.

Ce que vous allez apprendre

Préparer VS Code avec l'extension Ansible officielle (autocomplétion, lint, snippets).
Cloner un dépôt Git directement depuis VS Code sans CLI séparée.
Ouvrir un projet en Dev Container Ansible (image creator-ee ou Red Hat officielle).
Configurer ansible-navigator.yml pour lier le projet à l'EE.
Lancer un playbook avec ansible-navigator run depuis le terminal intégré.
Pousser les modifications via Git sans quitter l'éditeur.
Comprendre pourquoi ce workflow est devenu le standard Red Hat.

Prérequis

VS Code 1.95+ installé (Linux, macOS, Windows + WSL2).
Docker Desktop ou Podman Desktop installé et démarré.
Git configuré (git config --global user.email "..." et user.name "...").
Pour la version Red Hat officielle : compte Red Hat Developer (gratuit, login pour registry.redhat.io).
Connaissances de base en Git (clone, add, commit, push).

Pourquoi ce workflow plutôt qu'un setup ad-hoc

Pilier Operational Excellence. Red Hat a réaligné l'examen RHCE EX294 sur ce workflow pour 4 raisons que vous devriez vous approprier :

Reproductibilité — un Dev Container démarre dans un état identique sur tous les postes. Pas de dérive « ça marche chez moi mais pas chez l'examinateur ».
Pas d'install RPM sur RHEL 10 — Red Hat a annoncé que les outils de développement Ansible ne sont plus packagés en RPM sur RHEL 10. Le Dev Container est devenu la voie officielle.
Cohérence avec AAP — les Execution Environments d'AAP 2.5/2.6 utilisent la même mécanique conteneur que le Dev Container. Apprendre l'un = comprendre l'autre.
Fidélité à l'examen — le poste d'examen RHCE est configuré exactement comme ce workflow. Si vous vous entraînez avec ce setup, vous ne perdez pas de temps à découvrir l'environnement le jour J.

L'extension Ansible VS Code — installation

VS Code embarque par défaut un éditeur YAML générique mais sans connaissance d'Ansible. L'extension Ansible officielle ajoute :

Autocomplétion des modules, paramètres, et tâches connues.
Validation YAML + détection des erreurs Ansible (FQCN manquant, indentation cassée).
Intégration ansible-lint au save (configurable).
Snippets des structures fréquentes (play, task, role).
Ansible Lightspeed (optionnel, IA Red Hat — désactivable pour l'examen).
Serveur MCP intégré (Red Hat) pour assistance IA contextuelle.

# Installation depuis CLI
code --install-extension redhat.ansible

Ou via l'UI : Ctrl+Shift+X → chercher « Ansible » → identifier l'extension publiée par Red Hat (badge vérifié) → Install.

Pour la préparation pure RHCE, désactivez Ansible Lightspeed (IA générative). L'examen n'autorise pas l'aide IA. S'entraîner avec Lightspeed activé crée une dépendance qui ne sera pas disponible le jour J.

{
  "ansible.lightspeed.enabled": false
}

Cloner un dépôt Git depuis VS Code

Plus besoin de CLI séparée. Le menu Source Control de VS Code (Ctrl+Shift+G) propose « Clone Repository » :

Ouvrir Source Control : Ctrl+Shift+G (ou icône Git dans la barre latérale).
Cliquer sur « Clone Repository ».

Coller l'URL Git (HTTPS ou SSH).

https://github.com/votre-org/ansible-rhce-prep.git

Choisir le dossier local où cloner (par exemple ~/Projets/ansible-rhce-prep/).
VS Code propose d'ouvrir le repo cloné. Accepter.

Pour un workflow d'examen blanc, créez un dépôt Git local sans remote (git init dans un dossier neuf). Le workflow Dev Container fonctionne identiquement avec ou sans remote.

Le Dev Container Ansible — `.devcontainer/devcontainer.json`

Un Dev Container est défini par un fichier .devcontainer/devcontainer.json à la racine du projet. VS Code lit ce fichier au démarrage et propose « Reopen in Container » — VS Code construit (ou pull) l'image, monte le code, et redémarre l'éditeur dans le conteneur.

Variante 1 — communautaire (creator-ee)

C'est l'option par défaut si vous n'avez pas de compte Red Hat. Image publique, pas d'auth requise.

{
  "name": "Ansible RHCE Prep (creator-ee)",
  "image": "quay.io/ansible/creator-ee:latest",

  "customizations": {
    "vscode": {
      "extensions": [
        "redhat.ansible",
        "redhat.vscode-yaml"
      ],
      "settings": {
        "ansible.python.interpreterPath": "/usr/bin/python3",
        "ansible.lightspeed.enabled": false
      }
    }
  },

  "remoteUser": "runner",

  "mounts": [
    "source=${localEnv:HOME}/.ssh,target=/home/runner/.ssh,type=bind,readonly"
  ],

  "postCreateCommand": "ansible --version && ansible-navigator --version"
}

creator-ee embarque ansible-core 2.16+, ansible-navigator, ansible-lint, ansible-builder, et les collections les plus courantes.

Variante 2 — Red Hat officiel (recommandé pour RHCE strict)

Pour reproduire exactement l'environnement d'examen, utiliser un Execution Environment supporté Red Hat depuis registry.redhat.io. Login préalable nécessaire.

# Login une fois sur le poste (compte Red Hat Developer gratuit)
podman login registry.redhat.io

{
  "name": "Ansible RHCE Prep (Red Hat EE)",
  "image": "registry.redhat.io/ansible-automation-platform-25/ee-supported-rhel9:latest",

  "customizations": {
    "vscode": {
      "extensions": ["redhat.ansible", "redhat.vscode-yaml"]
    }
  },

  "remoteUser": "runner"
}

L'image ee-supported-rhel9 est l'EE supporté Red Hat — pas exactement l'image d'examen mais le plus proche disponible publiquement. Les versions et collections sont alignées sur AAP 2.5.

latest est OK pour l'apprentissage mais à éviter en CI/production. Pour pinner une version stable :

"image": "registry.redhat.io/ansible-automation-platform-25/ee-supported-rhel9:1.0.0-123"

Vérifier les tags disponibles via podman pull <image> ou la console console.redhat.com.

Reopen in Container — la magie en 1 clic

Une fois le devcontainer.json créé, VS Code détecte le fichier et affiche une notification « Folder contains a Dev Container configuration. Reopen in Container ? ». Cliquer Reopen in Container.

Au premier lancement :

VS Code pull l'image (peut prendre 2-5 minutes selon la connexion).
Démarre un conteneur basé sur cette image.
Bind-mount le code dans /workspaces/<repo-name>.
Installe les extensions VS Code listées dans le conteneur (pas sur l'hôte).
Redémarre l'éditeur connecté au conteneur — visible en bas à gauche : Dev Container: Ansible RHCE Prep.

Au redémarrage suivant, VS Code réutilise le conteneur — aucune attente. Si vous modifiez devcontainer.json, la commande « Rebuild Container » force un rebuild.

Configuration `ansible-navigator.yml` — lier projet et EE

Une fois dans le Dev Container, créez ansible-navigator.yml à la racine du projet pour fixer la configuration par défaut :

ansible-navigator:
  execution-environment:
    image: quay.io/ansible/creator-ee:latest
    container-engine: podman
    pull:
      policy: missing
    volume-mounts:
      - src: "{{ HOME }}/.ssh"
        dest: "/home/runner/.ssh"
        options: "ro,Z"

  mode: stdout                    # stdout (CI/scripts) | interactive (debug TUI)

  playbook-artifact:
    enable: true                  # produit un artefact JSON par run
    save-as: "artifacts/{playbook_name}-{ts_utc}.json"

  logging:
    level: warning
    file: ".ansible-navigator.log"

Trois conventions à connaître :

Image identique au Dev Container quand c'est possible. Sinon, vous travaillez dans un EE (Dev Container) et lancez vos playbooks dans un autre EE (ansible-navigator) — duplication d'images, deux niveaux de cache.
pull.policy: missing est le bon défaut en dev. always en CI pour garantir l'image fraîche. never en air-gapped strict.
volume-mounts — ~/.ssh n'est pas accessible par défaut au conteneur. Sans ce mount, ansible-navigator run échoue à se connecter en SSH aux managed nodes.

Lancer un playbook avec ansible-navigator

Le terminal intégré VS Code (Ctrl+`) tourne dans le conteneur depuis qu'on est en Dev Container. Toutes les commandes exécutées le sont dans l'EE — pas besoin de podman run manuel.

# Mode stdout (sortie linéaire — CI, scripts)
ansible-navigator run playbooks/site.yml \
    --inventory inventory/hosts.yml

# Mode interactive (TUI plein écran — debug, exploration)
ansible-navigator run playbooks/site.yml \
    --inventory inventory/hosts.yml \
    --mode interactive

Le mode interactive ouvre une interface plein écran qui permet de naviguer dans les plays, voir les tâches en cours, drill-down sur un échec. Pour l'examen, le mode stdout est plus rapide à diagnostiquer (sortie complète d'un coup).

Validation rapide avant un vrai run

# 1. Syntax check (parse YAML + Ansible structure)
ansible-navigator run playbooks/site.yml --syntax-check

# 2. Check mode (dry-run — montre ce qui changerait sans modifier)
ansible-navigator run playbooks/site.yml --check

# 3. Exécution réelle
ansible-navigator run playbooks/site.yml

Cette séquence en 3 temps évite 80 % des erreurs en examen — un YAML mal indenté ne plante pas le check syntaxique côté playbook, mais bloque souvent au check mode parce qu'un module reçoit un type incorrect.

Pousser les modifications via Git

Tout VS Code Source Control fonctionne dans le conteneur :

Ouvrir Source Control : Ctrl+Shift+G.
Voir les changements dans la liste « Changes ».
Stager un fichier (+ à côté du nom) ou tous (+ au-dessus de la liste).
Écrire le message de commit dans la zone texte en haut.
Committer : Ctrl+Enter ou bouton ✓.
Pousser : icône Sync Changes en bas, ou Ctrl+Shift+P → « Git: Push ».

Les credentials Git sont partagés avec l'hôte via le bind mount ~/.gitconfig (Dev Container par défaut). Les clés SSH passent par le mount ~/.ssh configuré plus haut.

Arborescence type d'un projet RHCE

Répertoireansible-rhce-prep/
- Répertoire.devcontainer/
  - devcontainer.json
- Répertoire.vscode/
  - settings.json
  - extensions.json
- ansible-navigator.yml
- ansible.cfg
- Répertoireinventory/
  - hosts.yml
  - Répertoiregroup_vars/
    all.yml
  - Répertoirehost_vars/
    …
- Répertoireplaybooks/
  - site.yml
  - 01-bootstrap.yml
  - 02-users-groups.yml
  - 03-services.yml
- Répertoireroles/
  - Répertoirecommon/
    …
  - Répertoirewebserver/
    …
- Répertoirecollections/
  - requirements.yml
- .gitignore

C'est la structure recommandée par Red Hat — toute la formation AU294 utilise une arborescence proche. Le collections/requirements.yml permet de pinner les collections nécessaires :

collections:
  - name: ansible.posix
    version: ">=1.5.0"
  - name: community.general
    version: ">=7.0.0"
  - name: redhat.rhel_system_roles
    version: ">=1.21.0"

# Installation au démarrage du Dev Container (postCreateCommand)
ansible-galaxy collection install -r collections/requirements.yml

Pièges courants

Symptôme	Cause	Solution
`Reopen in Container` n'apparaît pas	Extension « Dev Containers » non installée	`code --install-extension ms-vscode-remote.remote-containers`
Pull `registry.redhat.io` échoue 401	Pas authentifié	`podman login registry.redhat.io` (compte Red Hat Developer gratuit)
Build Dev Container échoue sur les extensions	VS Code ne peut pas atteindre marketplace depuis le conteneur	Vérifier la config réseau Docker/Podman (`bridge` ok, `none` non)
`ansible-navigator run` retourne `permission denied` SSH	`~/.ssh` non monté dans le Dev Container	Ajouter `mounts` dans `devcontainer.json` (voir variante 1)
Lightspeed propose des suggestions pendant l'entraînement	Extension active	`"ansible.lightspeed.enabled": false` dans `.vscode/settings.json`
Rebuild Container ignore les changements `devcontainer.json`	VS Code utilise cache	Palette → « Dev Containers: Rebuild Container Without Cache »
Terminal intégré utilise la machine hôte au lieu du conteneur	Mauvaise sélection de profil	Bas de fenêtre VS Code : icône `Dev Container: ...`, vérifier qu'on n'est pas en « Local »

À retenir

Le workflow officiel Red Hat 2026 = VS Code + Dev Container + ansible-navigator + Git.
L'install RPM des outils Ansible n'est plus supportée sur RHEL 10 — le Dev Container devient mandatory.
L'extension Red Hat Ansible est non négociable — autocomplétion, lint, validation. Désactiver Lightspeed pour la prép RHCE pure.
2 variantes de Dev Container : creator-ee communautaire (par défaut) ou ee-supported-rhel9 Red Hat officiel (login registry.redhat.io requis).
ansible-navigator.yml au project root fixe l'EE par défaut — pull.policy: missing en dev, always en CI.
Mode stdout pour l'examen (sortie complète, diagnostic rapide). Mode interactive pour le debug exploratoire.
3 commandes obligatoires avant chaque vrai run : --syntax-check, --check, puis exécution réelle.
Tout VS Code Source Control marche dans le conteneur — clone, commit, push. ~/.gitconfig et ~/.ssh sont bind-mountés.

Prochaines étapes

Doc pendant l'examen — `ansible-doc` survie Comment trouver un module et un exemple en moins de 30 secondes sans Internet sur le poste d'examen.

Aide-mémoire RHCE EX294 Cheatsheet en une page : commandes essentielles, modules par catégorie, ansible.cfg, vault, FQCN.

Execution Environments — installation et config Pour aller plus loin sur les EE : ansible-builder, custom EE, debug, premier playbook complet.

Préparation RHCE — vue d'ensemble La page pivot certifications RHCE EX294 avec tous les liens et le plan de révision.