Dhall — программируемый язык для создания конфигурационных файлов различного назначения. Это Open Source-проект, первый публичный релиз которого состоялся в 2018 году. Как и всякий новый язык для генерации конфигурационных файлов, Dhall призван решить проблему ограниченной функциональности YAML, JSON, TOML, XML и других форматов конфигурации, но при этом оставаться достаточно простым. Язык распространяется всё шире. В 2020-м году представили его bindings, сделанные специально для Kubernetes. Рассказывая о Dhall применительно к созданию K8s-манифестов, начнем все же с краткого общего описания. Авторы проекта предлагают рассматривать Dhall как продвинутый JSON: с функциями, типами, импортами. Зачем нужен новый формат, если уже есть проверенные?  Главный аргумент создателей: упомянутые JSON и YAML — не программируемые языки. Это сужает их возможности и порой приводит к неоптимальным решениям. Например, к повторениям. Хороший тон для разработчика — следовать правилу DRY («Don’t repeat yourself»). Когда работаешь с ​​JSON и YAML, не повторять себя трудно. Из-за функциональной ограниченности в конфигурационных файлах часто приходится использовать повторяющиеся блоки конфигурации. Их нельзя упростить или отбросить. Dhall позиционируется как язык, который помогает придерживаться принципа DRY. Там, где в ​​JSON- или YAML-файл нужно вставить дополнительный блок кода, в Dhall можно подставить результат выполнения функции или значение переменной. В качестве иллюстрации в документации Dhall приводится пример, в котором сравниваются два конфигурационных файла, в JSON- и Dhall-формате соответственно. Каждый выполняет одну и ту же задачу: описывает место хранения публичного и приватного SSH-ключей пользователей. Исходный JSON-файл: Та же конфигурация в Dhall-формате: Пока по количеству строк файлы почти не отличаются.  Добавим нового пользователя — alice. Для этого в JSON-файл нужно вставить дополнительный блок из 5 строк: При этом даже при простом копипасте можно ошибиться: например, скопировать конфиг из блока для chad, но в одном из полей не поменять имя на alice. Для той же цели в Dhall-файл достаточно вызвать ещё раз ранее определенную функцию ordinaryUser — это займет одну строку: Чем сложнее конфигурационный файл, тем более очевидна негибкость JSON по сравнению с Dhall. Для экспорта конфигурации в нужный формат достаточно одной команды. Вот, например, как превратить вышеприведенный Dhall-файл в JSON: По тому же принципу организован экспорт в YAML, XML, Bash. Да, это не ошибка: dhall-bash превращает инструкции на Dhall в Bash-скрипты, однако для этого поддерживается только ограниченное количество конструкций. Dhall — программируемый язык, но при этом не тьюринг-полный. Авторы проекта говорят, что такое ограничение повышает безопасность кода и конфигурационных файлов, написанных на нем. Некоторые инструменты для своих конфигураций используют существующие языки программирования. Например, webpack поддерживает для этого TypeScript (и не только), Django — Python, sbt — Scala и т. п. Однако обратная сторона такой гибкости и свободы — это возможные проблемы со вставками ненадежного кода, межсайтовым скриптингом (XSS), подделками запросов со стороны сервера (SSRF) и другими атаками. Dhall от этого защищен. Ок, а что насчет применимости Dhall к генерации манифестов K8s?  Неудобство работы со множеством объектов в Kubernetes во многом обуcловлено особенностью дизайна YAML. Хотя YAML поддерживает минимальную шаблонизацию, прежде всего это формат для хранения конфигурации. Обойти его ограничения можно, например, с помощью Helm-шаблонов, но это не всегда просто и даже не всегда выполнимо (у нас была подробная статья на эту тему). Альтернатива — использовать другой, более гибкий язык для конфигурации, например Dhall (а некоторые другие примеры будут приведены ниже). Потому что это язык со встроенными шаблонами, которые в то же время не строго типизированы. Он, как отмечают создатели, предлагает простое описание конфигурации независимо от того, сколько абстракций создается. Объекты Kubernetes можно генерировать с помощью выражений Dhall, а затем экспортировать их в YAML-формат утилитой dhall-to-yaml. В публичном GitHub-репозитории dhall-kubernetes содержатся так называемые bindings — типы и функции Dhall, предназначенные для работы с объектами Kubernetes. Вот, например, как выглядит Dhall-конфигурация Deployment’а: При его экспорте в привычный YAML-формат с помощью dhall-to-yaml получится следующее: Говоря о «модульности» Dhall, создатели языка рассматривают случай, когда нужно определить: а) некоторый тип MyService с настройками для разных deployment’ов, б) функции, которые можно применять к MyService, чтобы создавать объекты для K8s. Это удобно, потому что позволяет определять сервисы не только в контексте Kubernetes и переиспользовать абстракции для работы с другими типами конфигурационных файлов. При этом принцип DRY остается в силе: чтобы внести небольшое изменение в конфигурации нескольких объектов, чаще всего достаточно изменить функцию в одном Dhall-файле — вместо того, чтобы руками править все связанные YAML’ы. Пример такой «модульности» Dhall — конфигурация контроллера Nginx Ingress, который настраивает TLS-сертификаты и маршруты для нескольких сервисов: Результат экспорта dhall-to-yaml: Здесь определенная функция services была вызвана дважды: с параметрами, указанными в defaultService (с хостом default.example.com), и переданными вручную значениями (с хостом foo.example.com). Таким образом, в итоговом манифесте получаем ресурс Ingress с двумя этими хостами. На конференции OSDNConf 2021 Олег Николин из Portside рассказал, как Dhall помог его инженерной команде. После перехода на Kubernetes и усложнения CI/CD-процесса количество YAML-конфигураций, используемых в компании, выросло до 12 тысяч. Если нужно было добавлять новую переменную в один из сервисов, приходилось вносить изменения в 40 файлов, которые лежали в разных репозиториях. Проводить ревью кода было очень сложно. Проблемы накапливались, но при этом проявлялись не всегда сразу после деплоя. Если сервис некоторое время работал с некорректной конфигурацией, отследить исходную причину проблемы было тяжело. После перехода на Dhall и рефакторинга команда избавилась от 50% ненужной конфигурации. Dhall повысил безопасность CI/CD: стало легче проверять манифесты K8s и переменные окружения до деплоя. Также появилась общая библиотека с описанием всех используемых ресурсов K8s. Всё это упростило работу DevOps-инженеров и проверку корректности конфигураций. Другой интересный пример того, как Dhall упрощает работу с YAML-файлами, приводит Christine Dodrill из Tailscale. Она хотела упростить проверку конфигурационных файлов K8s на предмет их корректности. С этим ей не помогали ни Helm, ни Kustomize — в отличие от Dhall. И она пришла к такому выводу: «Dhall, вероятно, наиболее жизнеспособная замена Helm или другим инструментам для создания манифестов Kubernetes». Да, кроме Dhall есть и другие фреймворки и языки, с которыми можно обойти ограничения YAML, сделать работу с манифестами в Kubernetes более удобной. Примеры Open Source-проектов: Cue. Язык с широким набором инструментов для определения, генерации и валидации конфигурационных файлов, API, схем баз данных и других типов данных. Jsonnet. Язык для создания шаблонов конфигураций. Как видно из названия, jsonnet — комбинация JSON и sonnet. Язык во многом похож на Cue. jk. Шаблонизатор для написании структурированных конфигурационных файлов, включая манифесты K8s. HCL. Язык, разработанный в HashiCorp. У HCL есть собственный «человекоориентированный» синтаксис, а также вариант на основе JSON, адаптированный для машинной обработки. cdk8s. Фреймворк для «программирования» Kubernetes-манифестов на JavaScript, Java, TypeScript и Python. Обзор по нему мы недавно публиковали. Хотя синтаксис Dhall несложный, а варианты использования языка подробно описаны в документации, кому-то он может показаться трудным для изучения. Чтобы освоить Dhall более или менее быстро, нужен хотя бы базовый опыт работы с программируемыми языками. Некоторые согласны с тем, что у существующих языков для создания конфигураций есть проблемы с гибкостью, но не согласны с решением, которое предлагает Dhall. «Привычным языкам не хватает полезных инженерных свойств, — говорит Andy Chu, программист и создатель Oil Shell, — но зато у них нет и побочных эффектов. И Dhall не избавлен от этих эффектов». Ему вторит сотрудник Earthly Adam Gordon Bell который считает, что «Dhall странный» — даже более странный, чем HCL, а ведь последний лучше известен в сообществе. Несмотря на свою относительную новизну, Dhall — это достаточно зрелый фреймворк, который развивается с учетом отзывов и пожеланий сообщества. У проекта 3300+ звезд на GitHub, уверенная база контрибьюторов и регулярные релизы. Dhall, по меньшей мере, достоин рассмотрения как один из вариантов для случаев, когда простых манифестов и их шаблонов перестает хватать. Язык применяется в production рядом компаний; в частности, среди пользователей, которые используют Dhall для создания и управления манифестами Kubernetes, упоминаются KSF Media, Earnest Research и IOHK. Читайте также в нашем блоге: «Обзор фреймворка cdk8s для программирования Kubernetes-манифестов»; «Продвинутая Helm-шаблонизация: выжимаем максимум».