Конвертер JSON в YAML Online
Конвертируйте JSON в читаемый YAML. Идеально для создания конфигураций Docker Compose, Kubernetes или GitHub Actions.
name: John Doe age: 30 active: true tags: - developer - javascript address: city: Madrid zip: 28001
Сценарии использования
Из JSON API в читаемую конфигурацию YAML
Создание DevOps-конфигураций
Преобразуйте ответы JSON от API Kubernetes, Docker или облачных инструментов в редактируемые файлы конфигурации YAML.
DevOps-рабочий процесс
Конвертируйте шаблоны CloudFormation или Azure ARM JSON в эквивалентный YAML для улучшения читаемости и удобства сопровождения.
100% конфиденциально
Ваш JSON обрабатывается в браузере. Никогда не загружается на сервер. Без регистрации, без ограничений использования.
Чистый YAML
Отступ 2 пробела, корректно типизированные значения, готово к вставке в docker-compose.yml или манифест Kubernetes.
Как это работает
Три шага — никаких сложностей
Вставьте ваш JSON
Вставьте любой валидный JSON: ответ API, конфигурацию, структурированные данные. Принимается как форматированный, так и минифицированный JSON.
Конвертация в чистый YAML
JSON конвертируется в YAML с отступом в 2 пробела, следуя соглашениям наиболее популярных DevOps-проектов.
Скопируйте и используйте YAML
Скопируйте получившийся YAML для использования в качестве основы вашего docker-compose.yml, манифеста Kubernetes или любой YAML-конфигурации.
FAQ
Остались вопросы?
YAML превосходит JSON по читаемости для длинных иерархических конфигураций. Основные преимущества YAML: поддержка комментариев (необходима в документированных файлах конфигурации), более лаконичный синтаксис (в большинстве случаев нет фигурных скобок или кавычек), лучшее представление многострочных строк (скрипты, команды, текст) и более естественное чтение списков. JSON превосходит YAML, когда назначением является API или программа, обрабатывающая его автоматически: разбор быстрее, спецификация проще и строже, и меньше неоднозначности. Практическое правило DevOps: YAML для файлов, которые люди редактируют напрямую, JSON для данных, передаваемых между системами.
Конвертер генерирует YAML, структурно эквивалентный входному JSON, без комментариев (JSON не имеет комментариев, поэтому нет информации для переноса). Однако сгенерированный YAML — отличная отправная точка: откройте его в любом редакторе и добавьте комментарии вручную с помощью # перед или после любой строки. В таких инструментах, как docker-compose.yml и манифесты Kubernetes, комментарии необходимы для документирования назначения каждого значения конфигурации.
JSON разбирается значительно быстрее, чем YAML. Разбор JSON является O(n) с очень низкими константами: парсеры вроде simdjson (используется в Node.js начиная с версии 17) обрабатывают до 3 ГБ/с на современном оборудовании. YAML требует более сложного парсера (обработка якорей, псевдонимов, явных типов, различных стилей строк) и обычно в 10–50 раз медленнее JSON для того же объёма данных. Для небольших файлов конфигурации (docker-compose.yml несколько КБ) разница незаметна. Для API, обрабатывающих миллионы сообщений в секунду, JSON — правильный выбор. Использование YAML в DevOps-инструментах — это решение, принятое из соображений удобства для людей, редактирующих эти файлы.
Конвертер использует отступ в 2 пробела, который является соглашением, принятым практически всей экосистемой DevOps: Kubernetes (kubectl генерирует YAML с 2 пробелами), Helm, GitHub Actions, GitLab CI, Ansible и Docker Compose. Некоторые проекты используют 4 пробела (распространено в Python-проектах, где соглашение PEP 8 об отступе в 4 пробела влияет на разработчиков), но 2 пробела — де-факто стандарт в сообществе DevOps.
Преобразование типов прямолинейно: числа JSON (целые и с плавающей точкой) представляются как неквотированные скаляры YAML; булевы значения JSON (true/false) становятся true/false в YAML; null в JSON становится null или ~ в YAML; строки представляются без кавычек, когда это однозначно, или в одинарных или двойных кавычках, когда значение может быть интерпретировано как другой тип (например, строка '42' требует кавычек, чтобы не стать числом, а 'true' — кавычек, чтобы не стать булевым значением).
Конвертировать JSON в YAML: от ответов API к читаемым DevOps-конфигурациям
Конвертация JSON в YAML — рутинная операция в современных DevOps-рабочих процессах. API Kubernetes (Kubernetes REST API по умолчанию возвращает ресурсы в JSON), AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager и большинство инструментов инфраструктуры как кода имеют нативные JSON-интерфейсы, но их пользователи предпочитают работать с YAML-файлами конфигурации для лучшей читаемости. kubectl, инструмент командной строки Kubernetes, автоматически конвертирует между YAML и JSON: при выполнении команды kubectl get deployment my-app -o yaml Kubernetes возвращает JSON-объект API, а kubectl конвертирует его в YAML для отображения. Обратная конвертация (JSON в YAML) полезна при создании YAML-манифеста из ответа API, при миграции конфигураций между инструментами или при документировании существующей конфигурации путём добавления комментариев YAML.
YAML (спецификация 1.2, опубликована на yaml.org в июле 2009 года) является надмножеством JSON, что гарантирует, что конвертация JSON в YAML всегда возможна без потери информации. Обратная операция (YAML в JSON) теряет только комментарии, которые JSON не может представить. Преимущества YAML для конфигураций, создаваемых людьми, хорошо задокументированы: отсутствие фигурных скобок и квадратных скобок снижает визуальный шум на 30–40% для типичных конфигураций; комментарии позволяют документировать назначение каждого параметра непосредственно в файле; многострочные строки (особенно с буквальным блоком |) позволяют включать скрипты оболочки, SQL-запросы или содержимое файлов непосредственно в конфигурацию без экранирования специальных символов.
В экосистеме Kubernetes выбор между YAML и JSON хорошо устоялся: файлы, создаваемые и поддерживаемые разработчиками в git-репозиториях, являются YAML; данные, которые kubectl отправляет на API-сервер, — JSON (kubectl внутренне конвертирует YAML в JSON перед HTTP-вызовом); ответы API-сервера — JSON; и инструменты автоматизации (Helm, Kustomize, Argo CD, Flux) работают с YAML в качестве входных данных и JSON в качестве внутреннего протокола. Это разделение между форматом для людей (YAML) и форматом для протокола (JSON) — паттерн, также соблюдаемый в GitHub Actions (рабочие процессы — YAML, GitHub API — JSON), GitLab CI, Ansible (плейбуки в YAML, данные динамического инвентаря в JSON) и Terraform (HCL — это альтернатива HashiCorp, но он также принимает нативный JSON в файлах .tf.json).