Инструмент для DevOps-инженеров и разработчиков

YAML валидатор
и форматтер

Q: Что такое YAML и для чего он используется?

YAML (YAML Ain't Markup Language) — это формат сериализации данных, оптимизированный для чтения человеком. Он используется для конфигурационных файлов в Kubernetes, Ansible, Docker Compose, GitHub Actions, GitLab CI, Spring Boot и десятках других инструментов. YAML описывает данные через отступы, двоеточия и дефисы, без фигурных скобок и кавычек.

Q: Чем YAML отличается от JSON?

YAML — надмножество JSON: любой валидный JSON является валидным YAML. Ключевые различия: YAML поддерживает комментарии (#), не требует кавычек для ключей и строк, использует отступы вместо скобок, поддерживает якоря и псевдонимы для повторяющихся блоков, а также многодокументные файлы (разделитель ---). JSON компактнее и быстрее парсится, поэтому используется в API.

Q: Почему мой YAML не проходит валидацию?

Самые частые причины: использование табуляции вместо пробелов (YAML запрещает Tab), отсутствие пробела после двоеточия (name:value вместо name: value), непоследовательные отступы (смешивание 2 и 3 пробелов), спецсимволы в строках без кавычек (двоеточие, #, [ ] и другие). Наш валидатор показывает номер строки и описание ошибки.

Q: Какой отступ использовать в YAML — 2 или 4 пробела?

Стандарт YAML не регламентирует размер отступа, но де-факто: Kubernetes, Ansible, Docker Compose и GitHub Actions используют 2 пробела. Spring Boot и некоторые Python-проекты — 4 пробела. Главное — единообразие внутри проекта. Настройте .editorconfig для всей команды.

Q: Можно ли конвертировать YAML в JSON и обратно?

Да, наш инструмент поддерживает двустороннюю конвертацию. YAML → JSON полезен для отладки (JSON строже, проще для программного анализа) и для интеграции с API, которые принимают только JSON. JSON → YAML удобен, когда нужно превратить ответ API в читаемую конфигурацию. При конвертации сохраняются типы данных (числа, булевы, null).

Q: Безопасно ли вставлять конфиденциальные данные в валидатор?

Да. Наш валидатор работает полностью на стороне клиента (в вашем браузере). Данные не отправляются на сервер и не сохраняются. Весь парсинг, валидация и конвертация выполняются в JavaScript прямо в браузере. Тем не менее, в продакшн-конфигурациях рекомендуется использовать переменные окружения вместо хардкода паролей и токенов.

Q: Что такое якоря и псевдонимы в YAML?

Якоря (&name) и псевдонимы (*name) — механизм переиспользования данных. Якорь сохраняет блок под именем, псевдоним ссылается на него. Merge key (<<: *name) объединяет словари. Это помогает избежать дублирования в конфигурациях с несколькими окружениями (dev, staging, production), где большая часть настроек совпадает.

Q: Как проверить YAML перед деплоем в Kubernetes?

Многоуровневая проверка: 1) Синтаксис — наш валидатор или yamllint. 2) Схема — kubectl apply --dry-run=client -f file.yaml проверяет, что поля соответствуют API Kubernetes. 3) Политики — OPA/Gatekeeper или Kyverno проверяют соответствие корпоративным правилам (лимиты ресурсов, метки, namespace). Лучше всего встроить все три уровня в CI/CD.

Q: Поддерживает ли валидатор многодокументные YAML-файлы?

Да. YAML позволяет хранить несколько документов в одном файле, разделяя их строкой --- (три дефиса). Это часто используется в Kubernetes для описания Deployment и Service в одном файле. Наш валидатор корректно обрабатывает разделители документов и показывает количество документов в статистике.

Q: Почему YAML интерпретирует 'NO' как false?

В YAML 1.1 значения yes, no, on, off, y, n распознаются как булевы true/false. Это частая проблема: country: NO (код Норвегии) становится false. В YAML 1.2 это поведение изменено — только true/false считаются булевыми. Для надёжности всегда оборачивайте такие значения в кавычки: country: "NO".

Проверяйте синтаксис YAML, форматируйте с нужными отступами и конвертируйте между YAML и JSON. Подсветка ошибок с номерами строк, статистика документа и поддержка многодокументных файлов.

Отступ:

YAML ввод1 строка

Результат

Вставьте YAML и нажмите кнопку

или загрузите пример для тестирования

Режима работы

Валидация, форматирование, YAML<>JSON

100%

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

Данные не отправляются на сервер

2/4

Пробела отступа

Настраиваемый размер отступов

YAML 1.2

Стандарт

Актуальная спецификация формата

Что такое YAML

YAML (YAML Ain't Markup Language) — это человекочитаемый формат сериализации данных, созданный в 2001 году. Формат стал стандартом де-факто для конфигурационных файлов в DevOps, облачной инфраструктуре и CI/CD-пайплайнах. В отличие от XML и JSON, YAML использует отступы для обозначения структуры, что делает его компактнее и удобнее для чтения и редактирования вручную.

YAML: простота и читаемость

YAML использует отступы пробелами для обозначения вложенности, двоеточия для пар ключ-значение и дефисы для списков. Никаких фигурных скобок, кавычек и запятых — только чистая, читаемая структура. Это делает YAML идеальным для конфигураций, которые часто редактируют вручную.

YAML vs JSON

JSON — подмножество YAML. Любой валидный JSON является валидным YAML, но не наоборот. JSON компактнее для машин и используется в API, а YAML — для конфигураций. JSON требует кавычки для ключей и строк, YAML — нет. JSON не поддерживает комментарии, YAML поддерживает через символ #.

YAML vs TOML

TOML (используется в Cargo.toml, pyproject.toml) — более строгий формат с явными типами данных. YAML гибче и поддерживает сложные структуры: якоря, псевдонимы, многодокументные файлы. TOML лучше для плоских конфигов, YAML — для глубоко вложенных структур вроде манифестов Kubernetes.

История YAML

YAML был создан в 2001 году Кларком Эвансом, Инги д'ет Нетом и Ореном Бен-Кики. Изначально аббревиатура расшифровывалась как «Yet Another Markup Language», но позже была изменена на рекурсивный акроним «YAML Ain't Markup Language», чтобы подчеркнуть: YAML — это формат данных, а не разметки.

Спецификация YAML 1.0 вышла в январе 2004 года. Текущая версия — YAML 1.2 (2009) — совместима с JSON и является надмножеством этого формата. YAML широко используется в экосистеме DevOps благодаря проектам Ruby on Rails, Ansible, Docker и Kubernetes.

2001Создание YAML, первый черновик спецификации

2004Выход YAML 1.0, стандартизация формата

2005YAML 1.1 — расширенная поддержка типов

2009YAML 1.2 — совместимость с JSON, текущий стандарт

2012Ansible выбирает YAML для плейбуков

2014Kubernetes использует YAML для манифестов

2019GitHub Actions — пайплайны на YAML

Где используется YAML

YAML стал стандартом конфигурации в облачных технологиях, CI/CD и инфраструктуре как коде (IaC). Вот основные области применения.

Kubernetes

Манифесты Deployments, Services, ConfigMaps, Ingress, Helm Charts — вся конфигурация кластера описывается в YAML. Ошибка в отступе может привести к падению деплоя.

Ansible

Плейбуки, роли, инвентори и переменные — Ansible полностью построен на YAML. Валидация плейбука перед запуском экономит часы отладки на продакшене.

Docker Compose

Файлы docker-compose.yml описывают многоконтейнерные приложения: сервисы, сети, volumes, зависимости. Невалидный YAML — контейнеры не поднимутся.

GitHub Actions

Workflows в .github/workflows/*.yml определяют CI/CD-пайплайны: сборку, тесты, деплой. Строгий синтаксис — ошибка в YAML блокирует весь пайплайн.

GitLab CI/CD

Файл .gitlab-ci.yml описывает стадии, джобы, артефакты и окружения. GitLab парсит YAML строго — невалидный файл отключает весь CI/CD проекта.

Spring Boot

Конфигурация application.yml в Java/Kotlin-приложениях. Профили (dev, prod, test) в одном файле, иерархическая структура настроек сервера, БД, кеша.

Синтаксис YAML/ справочник

Основные конструкции YAML, которые используются в повседневной работе с конфигурационными файлами Kubernetes, Ansible, Docker Compose и CI/CD.

Скаляры (простые значения)

Строки, числа, булевы значения и null. Строки обычно не требуют кавычек, но кавычки нужны, если значение содержит спецсимволы (: # [ ] , & * ? | - < > = ! % @ \).

name: my-app          # строка
port: 8080             # целое число
ratio: 3.14            # дробное число
enabled: true          # булево (true/false/yes/no)
empty: null            # пустое значение (null/~)
quoted: "value: here"  # кавычки нужны из-за двоеточия

Списки (последовательности)

Элементы списка начинаются с дефиса и пробела (- ). Списки могут быть вложенными и содержать объекты. Inline-форма: [a, b, c].

# Блочный стиль
fruits:
  - apple
  - banana
  - cherry

# Inline-стиль (flow)
colors: [red, green, blue]

# Список объектов
users:
  - name: Ivan
    role: admin
  - name: Maria
    role: editor

Словари (маппинги)

Пары ключ-значение через двоеточие и пробел. Вложенные словари создаются отступами. Inline-форма: {key: val}.

# Вложенный словарь
database:
  host: localhost
  port: 5432
  credentials:
    username: admin
    password: secret

# Inline-стиль
limits: {cpu: "500m", memory: "256Mi"}

Многострочные строки

Литеральный блок (|) сохраняет переносы строк. Свёрнутый блок (>) заменяет переносы на пробелы. Модификаторы: + (сохранить trailing newline), - (убрать trailing newline).

# Literal block (|) — переносы сохраняются
description: |
  Первая строка
  Вторая строка
  Третья строка

# Folded block (>) — переносы → пробелы
summary: >
  Это длинное описание,
  которое склеится
  в одну строку.

Якоря и псевдонимы (& / *)

Якорь (&name) сохраняет блок, псевдоним (*name) ссылается на него. <<: *name — merge key для объединения словарей. Помогает избежать дублирования конфигураций.

# Определяем якорь
defaults: &defaults
  adapter: postgres
  host: localhost
  pool: 5

# Используем псевдоним
development:
  <<: *defaults
  database: dev_db

production:
  <<: *defaults
  database: prod_db
  pool: 25

Частые ошибки в YAML

YAML чувствителен к отступам и форматированию. Вот наиболее распространённые ошибки, которые ловит наш валидатор.

Табуляция вместо пробелов

YAML запрещает символы табуляции. Настройте редактор на замену Tab пробелами (2 или 4).

Неправильноserver:\n\thost: localhost

Правильноserver:\n host: localhost

Отсутствие пробела после двоеточия

После двоеточия обязателен пробел (или конец строки для вложенных структур).

Неправильноname:value

Правильноname: value

Непоследовательные отступы

Элементы одного уровня должны иметь одинаковый отступ. Смешивание 2 и 3 пробелов — ошибка.

Неправильноserver:\n host: x\n port: 80

Правильноserver:\n host: x\n port: 80

Спецсимволы в строках без кавычек

Двоеточие с пробелом внутри значения воспринимается как новая пара ключ-значение. Оберните в кавычки.

Неправильноmessage: Error: not found

Правильноmessage: "Error: not found"

Дублирование ключей

Дублирующие ключи на одном уровне — поведение не определено. Второе значение может перезаписать первое.

Неправильноname: first\nname: second

Правильноfirst_name: first\nlast_name: second

Числа и булевы как строки

Кавычки превращают числа и булевы в строки. Kubernetes и Ansible могут обработать их неправильно.

Неправильноport: "8080"\nenabled: "true"

Правильноport: 8080\nenabled: true

Советы по работе с YAML

Практические рекомендации от DevOps-инженеров для безопасной и эффективной работы с YAML-конфигурациями.

1Используйте линтер в CI/CD

Добавьте yamllint в пайплайн CI/CD. Он проверяет не только синтаксис, но и стилистику: длину строк, отступы, пустые строки. Конфигурация .yamllint.yml позволяет настроить правила под проект. Это предотвращает мёрж некорректных конфигов в main-ветку.

2Настройте EditorConfig

Создайте .editorconfig с правилами для *.yml и *.yaml: indent_style = space, indent_size = 2, insert_final_newline = true. Это гарантирует единообразие отступов у всех участников команды, независимо от используемого редактора.

3Избегайте yes/no и on/off

В YAML 1.1 значения yes, no, on, off, y, n автоматически преобразуются в булевы true/false. Это частая причина багов: country: NO (Норвегия) становится false. Используйте true/false для булевых и кавычки для строк, похожих на булевы.

4Разделяйте окружения файлами

Вместо одного файла с якорями и merge keys для dev/stage/prod используйте отдельные файлы: values-dev.yaml, values-prod.yaml. Helm и Kustomize поддерживают наложение конфигураций. Это упрощает ревью и снижает риск случайного деплоя продакшн-настроек в dev.

5Всегда оборачивайте версии в кавычки

Значение version: 1.0 парсится как число 1 (не «1.0»). Аналогично version: 3.10 становится 3.1. Всегда пишите version: "1.0" или version: "3.10" для сохранения точного значения. Это особенно критично для Docker-тегов и Helm Charts.

6Валидируйте перед деплоем

Помимо синтаксической проверки, используйте схемную валидацию: kubectl --dry-run=client для Kubernetes, ansible-lint для Ansible, docker compose config для Docker Compose. Это проверяет не только формат YAML, но и корректность конкретных полей.

Как пользоваться валидатором

Пошаговая инструкция для быстрой проверки и форматирования YAML-файлов.

Вставьте YAML

Скопируйте содержимое YAML-файла в текстовое поле слева. Или нажмите кнопку «Пример» для загрузки тестовой конфигурации Kubernetes.

Выберите режим

Валидация проверит синтаксис и покажет ошибки. Форматирование выровняет отступы. Конвертация переведёт YAML в JSON или обратно.

Настройте отступ

Выберите 2 пробела (стандарт Kubernetes, Ansible) или 4 пробела (стандарт Python, Spring Boot). Настройка влияет на форматирование и конвертацию.

Скопируйте результат

Нажмите «Копировать» для копирования результата в буфер обмена. Отформатированный YAML или сконвертированный JSON готов к использованию.

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