Реклама мешает? Идти Без рекламы Сегодня 

Форматировщик YAML Ansible Playbook

ДанныеРазработчик

Реклама · УДАЛИТЬ?

ВХОД

Автоматический процесс

ВЫХОД

Клиентская сторона

Реклама · УДАЛИТЬ?

Гид

Форматировщик YAML Ansible Playbook

Вставьте любой Ansible playbook или файл с задачами и получите валидно отформатированный YAML с ключами задач в каноническом порядке (name → module → args → loop → when → register → notify). Инструмент определяет, является ли вставленный текст playbook или списком задач, проверяет структуру и показывает советы по стилю ansible-lint — полные имена модулей (FQCN), отсутствующие changed_when, command-instead-of-module, и устаревшие yes/no значения истинности — чтобы ваши playbooks проходили проверку на первом этапе.

Как использовать

Вставьте ваш YAML Ansible в поле ввода — полный playbook.yml, файл роли tasks/main.yml, или любой список задач.
Оставить Переупорядочивание ключей задач включено для применения традиционного порядка ключей ansible-lint, или отключено, чтобы сохранить ваш исходный порядок.
Оставить Проверка структуры Ansible включено для проверки формы play/task (отсутствующие hosts, задачи без модуля, неправильные block).
Переключать Показать советы по стилю ansible-lint для рекомендаций по лучшим практикам, таким как полные имена модулей (FQCN), отсутствующие имена и предупреждения о идемпотентности.
Скопируйте отформатированный вывод или загрузите его как playbook.yml.

Возможности

Традиционный порядок ключей задач – name сначала, затем модуль, затем args, loop, when, register, notify — порядок, ожидаемый ansible-lint.
Проверка playbook vs список задач – Автоматически применяет порядок на уровне play (hosts, vars, pre_tasks, tasks, post_tasks, handlers) при обнаружении playbook.
Блок / rescue / always осознаны – Переупорядочивают вложенные задачи блокового типа без нарушения их семантики.
Структурная валидация – Выявляет отсутствующие plays, задачи без модуля, неправильные списки и неизвестные ключи на уровне play. hostsFQCN советы
– Предлагают вместо ansible.builtin.apt , соответствующие aptИдемпотентность советы fqcn[action-core].
– Предупреждают, когда выполняется без command/shell команды-instead-of-module обнаружение changed_when, creates, или removes.
– Выявляет установки пакетов, вызовы systemctl, клонирование git и установки pip, которые имеют собственные модули. Обнаружение устаревших значений истинности
– Выявляет значения которые должны быть yes/no/on/off Устаревшие предупреждения по циклу true/false (yaml[truthy]).
– Выделяет и подобные, чтобы вы могли перейти к with_items, with_dict– Ничего не загружается; ваша инвентаризация и секреты остаются локальными. loop:.
Работает полностью в браузере Почему ansible-lint заботится о порядке ключей задач?

 Часто задаваемые вопросы

Соответствующий порядок ключей делает playbooks легко читаемыми: намерение задачи (

) сначала читается, затем модуль, выполняющий действие, затем его аргументы, затем любые операторы управления (name). Когда все участники команды следуют одному и тому же порядку, различия остаются фокусированными на реальных изменениях, а ревьюерам удаётся быстро распознавать задачи.loop, when, register, notifyЧто такое FQCN и зачем использовать его для модулей?
FQCN означает Полностью Квалифицированное Имя Коллекции — полный путь, например

вместо просто namespace.collection.module . Поскольку Ansible 2.10 разделил модули на коллекции, короткие имена могут разрешаться неоднозначно, когда несколько коллекций содержат модуль с таким же коротким именем. FQCN делают разрешение явным, документируют источник каждого модуля и защищают playbooks от изменений порядка коллекций. ansible.builtin.apt Когда следует использовать loop: вместо with_items:? aptЦиклы на основе lookup были первоначальным способом итерации, но они связывают итерацию с плагинами lookup, что ограничивает композицию. Ключевое слово
(введённое в 2.5) принимает любые списки напрямую и хорошо сочетается с

The with_* для индексирования, меток и пауз. Для простой итерации по списку всегда предпочитайте loop: ; используйте только loop_control для редких паттернов, которые пока не имеют чистого loop:эквивалента. with_* Почему в YAML 'yes' считается устаревшим в Ansible? loop YAML 1.1 рассматривал
как логические значения. YAML 1.2 ограничил логические значения только

. Чтобы оставаться совместимым и однозначным — особенно когда значения YAML позже используются внешними инструментами — ansible-lint рекомендует использовать yes, no, on, off, trueи false . Использование строгих логических значений также избегает неожиданных ситуаций при необходимости использовать строку как данные. true/falseПочему объявлять changed_when на задачах command/shell? yaml[truthy] Ansible определяет, изменился ли системный уровень, анализируя возвращаемые данные модуля. Модули не могут сами понять это — они считают успешное выполнение изменением, что делает проверки идемпотентности ложными. Объявление true и false(или использование yes ) позволяет вам указать реальное условие изменения: конкретный код выхода, шаблон вывода или маркер файла. Идемпотентные playbooks становятся тише и лучше отображаются при сравнении.
Вставьте ваш playbook.yml, роли или список задач здесь

Ansible Playbook YAML Formatter 1 command, shellи raw Ansible Playbook YAML Formatter changed_when Вставьте любой Ansible playbook или файл с задачами и получите валидно отформатированный YAML с ключами задач в каноническом порядке (name → module → args → loop → when → creates/removes) позволяет закодировать реальное условие изменения: конкретный код выхода, шаблон вывода или маркер файла. Идемпотентные playbook становятся тише и более поддающимися сравнению при помощи diff.