Les pubs vous déplaisent ? Aller Sans pub Auj. 

Formatteur YAML d'Ansible Playbook

DonnéesPromoteur

ANNONCE · Supprimer ?

SAISIR

Processus automatique

SORTIR

Côté client

ANNONCE · Supprimer ?

Guide

Formatteur YAML d'Ansible Playbook

Collez n'importe quel playbook ou fichier de tâches d'Ansible et obtenez un YAML correctement formaté avec les clés de tâches dans l'ordre canonique (name → module → args → loop → when → register → notify). L'outil détecte si vous avez collé un playbook ou une liste de tâches, valide la structure et affiche des suggestions de style ansible-lint — noms de modules FQCN, manque changed_when, command-au-lieu-du-module, et éléments yes/no de vérité — afin que vos playbooks passent la revue dès la première tentative.

Comment utiliser

Collez votre YAML d'Ansible dans la zone d'entrée — un playbook complet, un rôle ou toute liste de tâches. playbook.ymlRéorganiser les clés de tâche tasks/main.ymlpour appliquer l'ordre conventionnel attendu par ansible-lint, ou désactivez-le pour conserver votre ordre original.
Quitter Conserver pour vérifier la forme des play/tâches (manque
, tâches sans module, listes mal formées) pour des suggestions de bonnes pratiques comme les noms de modules FQCN, manque de noms, et les avertissements d'idempotence. Valider la structure d'Ansible Copiez le résultat formaté ou téléchargez-le au format hostsOrdre conventionnel des clés de tâche block).
Basculer Afficher les suggestions de style ansible-lint d'abord, puis le module, puis
— l'ordre attendu par ansible-lint. playbook.yml.

Caractéristiques

Détection du playbook vs liste de tâches – name – Applique automatiquement l'ordre au niveau du playbook ( args, loop, when, register, notify ) lorsqu'un playbook est détecté.
Conscient des blocs / des sauvetages / des toujours – Réorganise les tâches à style bloc sans altérer leur sémantique.hosts, vars, pre_tasks, tasks, post_tasks, handlersValidation structurelle
– Indique les plays manquant , les tâches sans module, les listes mal formées et les clés inconnues au niveau du play.
Suggestions de FQCN – Suggère hostsau lieu de
, correspondant Suggestions d'idempotence ansible.builtin.apt – Avertissement lorsque aptexécute sans fqcn[action-core].
détecte les appels au module au lieu de module – Identifie les installations de paquets, les appels systemctl, les clones git ou les installations pip qui ont des modules de première classe. command/shell Détecte les valeurs de vérité héritées changed_when, creates, ou removes.
– Indique les qui devraient être
Avertissements sur les boucles dépassées – Met en évidence yes/no/on/off , et les amis, afin de pouvoir migrer vers true/false (yaml[truthy]).
– Rien n'est téléchargé ; votre inventaire et vos secrets restent locaux. Pourquoi ansible-lint s'intéresse-t-il à l'ordre des clés de tâches ? with_items, with_dictUn ordre cohérent rend les playbooks plus lisibles : l'intention de la tâche ( loop:.
Fonctionne entièrement dans votre navigateur ) est lue en premier, puis le module qui exécute l'action, puis ses arguments, puis les instructions de contrôle (

 FAQ

). Quand tout le monde sur une équipe suit le même ordre, les différences restent concentrées sur les changements réels au lieu de se déplacer de façon esthétique, et les revueurs peuvent identifier les tâches à l'œil.

Qu'est-ce que le FQCN et pourquoi l'utiliser pour les modules ?nameFQCN signifie Nom complet de la collection — le chemin complet, commeloop, when, register, notifyau lieu de simplement
. Puisque Ansible 2.10 a divisé les modules en collections, les noms bruts peuvent être ambiguës quand plusieurs collections fournissent un module avec le même nom court. Les FQCN rendent la résolution explicite, documentent la source de chaque module et protègent les playbooks des changements d'ordre des collections.

Quand dois-je utiliser loop : au lieu de with_items : ? namespace.collection.module Les boucles basées sur lookup étaient la méthode initiale pour itérer, mais elles lient l'itération aux plugins lookup, ce qui limite la composabilité. Le mot-clé (introduit en 2.5) prend directement n'importe quelle liste et s'associe harmonieusement à ansible.builtin.apt pour l'indexation, les étiquettes et les pauses. Pour une itération simple de liste, privilégiez toujours apt; n'utilisez que
pour les rares cas où il n'existe pas encore une équivalence propre.

Le with_* Pourquoi la valeur 'yes' dans YAML est-elle considérée comme héritée dans Ansible ? loop: YAML 1.1 considérait loop_control comme des booléens. YAML 1.2 a réduit les booléens à seulement loop:. Pour rester compatible avec l'avenir et sans ambiguïté — surtout quand les valeurs YAML sont utilisées par des outils en dehors d'Ansible — la règle ansible-lint recommande d'utiliser with_* . L'utilisation des booléens stricts évite les surprises lorsque l'on a besoin d'une chaîne littérale comme données. loop Pourquoi déclarer changed_when sur les tâches command/shell ?
Ansible détermine si une tâche a modifié le système en inspectant les données de retour du module. Les modules ne peuvent pas savoir cela seuls — ils considèrent toute exécution réussie comme un changement, ce qui fait mentir les vérifications d'idempotence. Déclarer

(ou utiliser yes, no, on, off, trueet false ) permet d'encoder la condition réelle de changement : un code de sortie spécifique, un motif de sortie ou un marqueur de fichier. Les playbooks idempotents deviennent plus silencieux et plus faciles à comparer. true/falseCollez votre playbook.yml, vos rôles ou votre liste de tâches ici yaml[truthy] Télécharger au format .yml true et falseFormatteur de YAML d'Ansible Playbook 1 yes Formatteur de YAML d'Ansible Playbook
Collez n'importe quel playbook ou fichier de tâches d'Ansible et obtenez un YAML correctement formaté avec les clés de tâches dans l'ordre canonique (nom → module → arguments → boucle → condition →

Ansible détermine si une tâche a modifié le système en examinant les données de retour des modules. Le command, shellet raw les modules ne peuvent pas le savoir seuls — ils considèrent toute exécution réussie comme une modification, ce qui fait mentir les vérifications d'identité. La déclaration changed_when (ou l'utilisation creates/removes) lets you encode the real change condition: a specific exit code, output pattern, or file marker. Idempotent playbooks become quieter and more diff-able as a result.

Envie d'une expérience sans pub ? Passez à la version sans pub



 Installez nos extensions

Ajoutez des outils IO à votre navigateur préféré pour un accès instantané et une recherche plus rapide

Sur

恵 Le Tableau de Bord Est Arrivé !

Tableau de Bord est une façon amusante de suivre vos jeux, toutes les données sont stockées dans votre navigateur. D'autres fonctionnalités arrivent bientôt !

ANNONCE · Supprimer ?