Dhall — программируемый язык для создания конфигурационных файлов различного назначения. Это Open Source-проект, первый публичный релиз которого состоялся в 2018 году.
Как и всякий новый язык для генерации конфигурационных файлов, Dhall призван решить проблему ограниченной функциональности YAML, JSON, TOML, XML и других форматов конфигурации, но при этом оставаться достаточно простым. Язык распространяется всё шире. В 2020-м году представили его bindings, сделанные специально для Kubernetes.
Рассказывая о Dhall применительно к созданию K8s-манифестов, начнем все же с краткого общего описания.
Чем Dhall отличается от других языков
Авторы проекта предлагают рассматривать Dhall как продвинутый JSON: с функциями, типами, импортами. Зачем нужен новый формат, если уже есть проверенные?
Just because
Главный аргумент создателей: упомянутые JSON и YAML — не программируемые языки. Это сужает их возможности и порой приводит к неоптимальным решениям. Например, к повторениям.
Фокус на DRY
Хороший тон для разработчика — следовать правилу DRY («Don’t repeat yourself»). Когда работаешь с JSON и YAML, не повторять себя трудно. Из-за функциональной ограниченности в конфигурационных файлах часто приходится использовать повторяющиеся блоки конфигурации. Их нельзя упростить или отбросить.
Dhall позиционируется как язык, который помогает придерживаться принципа DRY. Там, где в JSON- или YAML-файл нужно вставить дополнительный блок кода, в Dhall можно подставить результат выполнения функции или значение переменной. В качестве иллюстрации в документации Dhall приводится пример, в котором сравниваются два конфигурационных файла, в JSON- и Dhall-формате соответственно. Каждый выполняет одну и ту же задачу: описывает место хранения публичного и приватного SSH-ключей пользователей.
Исходный JSON-файл:
[
{
"privateKey": "/home/john/.ssh/id_rsa",
"publicKey": "/home/john/.ssh/id_rsa.pub",
"user": "john"
},
{
"privateKey": "/home/jane/.ssh/id_rsa",
"publicKey": "/home/jane/.ssh/id_rsa.pub",
"user": "jane"
},
{
"privateKey": "/etc/jenkins/jenkins_rsa",
"publicKey": "/etc/jenkins/jenkins_rsa.pub",
"user": "jenkins"
},
{
"privateKey": "/home/chad/.ssh/id_rsa",
"publicKey": "/home/chad/.ssh/id_rsa.pub",
"user": "chad"
}
]Та же конфигурация в Dhall-формате:
-- config0.dhall
let ordinaryUser =
\(user : Text) ->
let privateKey = "/home/${user}/.ssh/id_rsa"
let publicKey = "${privateKey}.pub"
in { privateKey, publicKey, user }
in [ ordinaryUser "john"
, ordinaryUser "jane"
, { privateKey = "/etc/jenkins/jenkins_rsa"
, publicKey = "/etc/jenkins/jenkins_rsa.pub"
, user = "jenkins"
}
, ordinaryUser "chad"
]Пока по количеству строк файлы почти не отличаются.
Добавим нового пользователя — alice. Для этого в JSON-файл нужно вставить дополнительный блок из 5 строк:
[
…
{
"privateKey": "/home/alice/.ssh/id_rsa",
"publicKey": "/home/alice/.ssh/id_rsa.pub",
"user": "alice"
}
]При этом даже при простом копипасте можно ошибиться: например, скопировать конфиг из блока для chad, но в одном из полей не поменять имя на alice.
Для той же цели в Dhall-файл достаточно вызвать ещё раз ранее определенную функцию ordinaryUser — это займет одну строку:
…
in [ ordinaryUser "john"
, ordinaryUser "jane"
, { privateKey = "/etc/jenkins/jenkins_rsa"
, publicKey = "/etc/jenkins/jenkins_rsa.pub"
, user = "jenkins"
}
, ordinaryUser "chad"
, ordinaryUser "alice" -- та самая новая строка
]Чем сложнее конфигурационный файл, тем более очевидна негибкость JSON по сравнению с Dhall.
Быстрый экспорт в другие форматы
Для экспорта конфигурации в нужный формат достаточно одной команды. Вот, например, как превратить вышеприведенный Dhall-файл в JSON:
dhall-to-json --pretty <<< './config0.dhall'По тому же принципу организован экспорт в YAML, XML, Bash. Да, это не ошибка: dhall-bash превращает инструкции на Dhall в Bash-скрипты, однако для этого поддерживается только ограниченное количество конструкций.
Акцент на безопасности
Dhall — программируемый язык, но при этом не тьюринг-полный. Авторы проекта говорят, что такое ограничение повышает безопасность кода и конфигурационных файлов, написанных на нем.
Некоторые инструменты для своих конфигураций используют существующие языки программирования. Например, webpack поддерживает для этого TypeScript (и не только), Django — Python, sbt — Scala и т. п. Однако обратная сторона такой гибкости и свободы — это возможные проблемы со вставками ненадежного кода, межсайтовым скриптингом (XSS), подделками запросов со стороны сервера (SSRF) и другими атаками. Dhall от этого защищен.
Dhall и Kubernetes
Ок, а что насчет применимости Dhall к генерации манифестов K8s?
Неудобство работы со множеством объектов в Kubernetes во многом обуcловлено особенностью дизайна YAML. Хотя YAML поддерживает минимальную шаблонизацию, прежде всего это формат для хранения конфигурации. Обойти его ограничения можно, например, с помощью Helm-шаблонов, но это не всегда просто и даже не всегда выполнимо (у нас была подробная статья на эту тему). Альтернатива — использовать другой, более гибкий язык для конфигурации, например Dhall (а некоторые другие примеры будут приведены ниже). Потому что это язык со встроенными шаблонами, которые в то же время не строго типизированы. Он, как отмечают создатели, предлагает простое описание конфигурации независимо от того, сколько абстракций создается.
Объекты Kubernetes можно генерировать с помощью выражений Dhall, а затем экспортировать их в YAML-формат утилитой dhall-to-yaml. В публичном GitHub-репозитории dhall-kubernetes содержатся так называемые bindings — типы и функции Dhall, предназначенные для работы с объектами Kubernetes. Вот, например, как выглядит Dhall-конфигурация Deployment’а:
-- examples/deploymentSimple.dhall
let kubernetes =
https://raw.githubusercontent.com/dhall-lang/dhall-kubernetes/master/package.dhall sha256:532e110f424ea8a9f960a13b2ca54779ddcac5d5aa531f86d82f41f8f18d7ef1
let deployment =
kubernetes.Deployment::{
, metadata = kubernetes.ObjectMeta::{ name = Some "nginx" }
, spec = Some kubernetes.DeploymentSpec::{
, selector = kubernetes.LabelSelector::{
, matchLabels = Some (toMap { name = "nginx" })
}
, replicas = Some +2
, template = kubernetes.PodTemplateSpec::{
, metadata = Some kubernetes.ObjectMeta::{ name = Some "nginx" }
, spec = Some kubernetes.PodSpec::{
, containers =
[ kubernetes.Container::{
, name = "nginx"
, image = Some "nginx:1.15.3"
, ports = Some
[ kubernetes.ContainerPort::{ containerPort = +80 } ]
}
]
}
}
}
}
in deploymentПри его экспорте в привычный YAML-формат с помощью dhall-to-yaml получится следующее:
## examples/out/deploymentSimple.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 2
selector:
matchLabels:
name: nginx
template:
metadata:
name: nginx
spec:
containers:
- image: nginx:1.15.3
name: nginx
ports:
- containerPort: 80Говоря о «модульности» Dhall, создатели языка рассматривают случай, когда нужно определить: а) некоторый тип MyService с настройками для разных deployment’ов, б) функции, которые можно применять к MyService, чтобы создавать объекты для K8s. Это удобно, потому что позволяет определять сервисы не только в контексте Kubernetes и переиспользовать абстракции для работы с другими типами конфигурационных файлов. При этом принцип DRY остается в силе: чтобы внести небольшое изменение в конфигурации нескольких объектов, чаще всего достаточно изменить функцию в одном Dhall-файле — вместо того, чтобы руками править все связанные YAML’ы.
Пример такой «модульности» Dhall — конфигурация контроллера Nginx Ingress, который настраивает TLS-сертификаты и маршруты для нескольких сервисов:
-- examples/ingress.dhall
let Prelude =
../Prelude.dhall sha256:10db3c919c25e9046833df897a8ffe2701dc390fa0893d958c3430524be5a43e
let map = Prelude.List.map
let kubernetes =
https://raw.githubusercontent.com/dhall-lang/dhall-kubernetes/master/package.dhall sha256:532e110f424ea8a9f960a13b2ca54779ddcac5d5aa531f86d82f41f8f18d7ef1
let Service = { name : Text, host : Text, version : Text }
let services = [ { name = "foo", host = "foo.example.com", version = "2.3" } ]
let makeTLS
: Service → kubernetes.IngressTLS.Type
= λ(service : Service) →
{ hosts = Some [ service.host ]
, secretName = Some "${service.name}-certificate"
}
let makeRule
: Service → kubernetes.IngressRule.Type
= λ(service : Service) →
{ host = Some service.host
, http = Some
{ paths =
[ { backend =
{ serviceName = service.name
, servicePort = kubernetes.IntOrString.Int +80
}
, path = None Text
}
]
}
}
let mkIngress
: List Service → kubernetes.Ingress.Type
= λ(inputServices : List Service) →
let annotations =
toMap
{ `kubernetes.io/ingress.class` = "nginx"
, `kubernetes.io/ingress.allow-http` = "false"
}
let defaultService =
{ name = "default"
, host = "default.example.com"
, version = " 1.0"
}
let ingressServices = inputServices # [ defaultService ]
let spec =
kubernetes.IngressSpec::{
, tls = Some
( map
Service
kubernetes.IngressTLS.Type
makeTLS
ingressServices
)
, rules = Some
( map
Service
kubernetes.IngressRule.Type
makeRule
ingressServices
)
}
in kubernetes.Ingress::{
, metadata = kubernetes.ObjectMeta::{
, name = Some "nginx"
, annotations = Some annotations
}
, spec = Some spec
}
in mkIngress servicesРезультат экспорта dhall-to-yaml:
## examples/out/ingress.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.allow-http: 'false'
kubernetes.io/ingress.class: nginx
name: nginx
spec:
rules:
- host: foo.example.com
http:
paths:
- backend:
serviceName: foo
servicePort: 80
- host: default.example.com
http:
paths:
- backend:
serviceName: default
servicePort: 80
tls:
- hosts:
- foo.example.com
secretName: foo-certificate
- hosts:
- default.example.com
secretName: default-certificateЗдесь определенная функция 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 более или менее быстро, нужен хотя бы базовый опыт работы с программируемыми языками.
Некоторые согласны с тем, что у существующих языков для создания конфигураций есть проблемы с гибкостью, но не согласны с решением, которое предлагает Dhall. «Привычным языкам не хватает полезных инженерных свойств, — говорит Andy Chu, программист и создатель Oil Shell, — но зато у них нет и побочных эффектов. И Dhall не избавлен от этих эффектов». Ему вторит сотрудник Earthly Adam Gordon Bell который считает, что «Dhall странный» — даже более странный, чем HCL, а ведь последний лучше известен в сообществе.
Резюме
Несмотря на свою относительную новизну, Dhall — это достаточно зрелый фреймворк, который развивается с учетом отзывов и пожеланий сообщества. У проекта 3300+ звезд на GitHub, уверенная база контрибьюторов и регулярные релизы. Dhall, по меньшей мере, достоин рассмотрения как один из вариантов для случаев, когда простых манифестов и их шаблонов перестает хватать.
Язык применяется в production рядом компаний; в частности, среди пользователей, которые используют Dhall для создания и управления манифестами Kubernetes, упоминаются KSF Media, Earnest Research и IOHK.
P.S.
Читайте также в нашем блоге:
«Обзор фреймворка cdk8s для программирования Kubernetes-манифестов»;
«Продвинутая Helm-шаблонизация: выжимаем максимум».
