Сравнение YAML
Сравните два YAML-файла рядом. Автоформатирование, сортировка ключей и подсветка различий.
Как использовать
- Paste your first YAML into the left panel
- Paste your second YAML into the right panel
- Click Compare — both sides are auto-formatted and sorted
- Differences are highlighted: red for removed lines, green for added lines
Часто задаваемые вопросы
-
Does key order matter?
No. Both YAML files are sorted by keys before comparing, so differences in key order are ignored.
-
Can I compare nested YAML?
Yes. Nested objects and lists are fully compared after formatting.
-
What do the colors mean?
Red lines exist only in the left input. Green lines exist only in the right input. Unchanged lines have no highlight.
-
Is my data sent to a server?
No. All processing happens entirely in your browser.
YAML diff в мире DevOps и Kubernetes
Сравнение YAML-файлов стало повседневной задачей для DevOps-инженеров, SRE и разработчиков, работающих с современными облачными инфраструктурами. Kubernetes, Helm, ArgoCD, Terraform, Ansible — все эти инструменты активно используют YAML, и управление изменениями в конфигурациях требует чёткого понимания, что именно меняется.
Kubernetes: жизненный цикл манифестов
Kubernetes-манифесты описывают желаемое состояние кластера: какие Pod'ы запустить, какие ресурсы выделить, как настроить сетевые политики. Файлы типичного Production-кластера могут содержать сотни строк YAML.
Команда kubectl diff
Kubernetes предоставляет встроенный инструмент сравнения:
kubectl diff -f deployment.yaml
Эта команда показывает, что изменится в кластере после применения манифеста. Однако её вывод — стандартный текстовый diff, который сложно читать при большом количестве изменений.
Онлайн-инструмент визуализирует те же различия с цветовой подсветкой и удобным параллельным отображением.
Helm: сравнение values
Helm-чарты параметризуют Kubernetes-манифесты через файлы values.yaml. При обновлении чарта или изменении конфигурации среды (dev/staging/prod) необходимо отслеживать изменения values. Diff-инструмент помогает проверить, что конфигурация staging действительно отличается от prod ровно в тех местах, где это ожидается.
GitOps: изменения конфигурации в системе контроля версий
В GitOps-подходе (ArgoCD, Flux) вся инфраструктурная конфигурация хранится в Git. Pull-request с изменением YAML-манифеста требует тщательного ревью. Структурный YAML diff помогает:
- Выявить случайные изменения форматирования (которые не несут смысловой нагрузки, но замусоривают diff)
- Сосредоточиться на содержательных изменениях: новых переменных окружения, изменённых лимитах ресурсов, обновлённых именах образов
Почему обычный git diff недостаточен для YAML
Проблемы текстового diff для YAML аналогичны JSON, с дополнительными нюансами:
Переформатирование через инструменты
Helm, kustomize и другие инструменты нередко переформатируют YAML при применении. Это создаёт «шумный» diff с множеством строк, изменившихся только по форматированию.
Порядок ключей
Разные YAML-генераторы могут создавать ключи в разном порядке. Семантически идентичные файлы дают многострочный текстовый diff.
Якоря раскрываются по-разному
После обработки через helm template или kustomize build якоря YAML раскрываются в повторяющиеся блоки. Сравнение источника с результатом через текстовый diff почти нечитаемо.
CI/CD: автоматическая проверка конфигураций
В пайплайнах CI/CD YAML diff используется для автоматической проверки:
# .github/workflows/review.yml
- name: Diff Kubernetes manifests
run: |
kubectl diff -f k8s/ || true
Вывод diff сохраняется как артефакт и прикрепляется к pull-request для ревью. Это обязательная практика в командах, серьёзно относящихся к управлению изменениями инфраструктуры.
Ansible: сравнение плейбуков и инвентарей
Ansible использует YAML для определения плейбуков, ролей и переменных. При рефакторинге плейбука или обновлении роли визуальное сравнение версий помогает убедиться, что изменения соответствуют намерениям и не затрагивают критические задачи.
Лучшие практики управления YAML-конфигурациями
- Хранить все конфигурационные YAML в системе контроля версий
- Использовать diff перед каждым применением изменений в production
- Разделять environment-специфичные параметры (через values или kustomize overlays)
- Документировать нетривиальные изменения в комментариях