云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!
本文将试着解释为什么大多数配置格式用起来都不太舒服,作者建议大家尝试使用一门真正的编程语言(例如,像 Python 这样的通用编程语言)来编写配置,通常这是一种可行的选择,且使用过程更感愉悦。
大多数现代配置格式都很糟糕
本节,我主要针对 JSON/YAML/TOML/ini 文件,这是我遇到过最常见的配置格式。
我们暂将这种配置称为常见配置(如果有更好的名字,欢迎在评论中留言,谢谢)。
大家可能遇到过如下情况:
- JSON 没有注释,设计如此
- 大量配置无法重用
例如,虽然 YAML 在理论上支持重用 / 引用配置(他们称之为锚),但有些软件(如 Github Actions )却并不支持。通常,开发者无法重用配置的一部分,必须复制粘贴。
- .gitconfig 使用一个自定义语法来合并这些配置
- 不能包含任何逻辑
很多人认为这是一种积极的做法,但我认为,如果不能定义临时变量、辅助函数、替换字符串或连接列表,那就有点差劲。变通方法(如果有的话)通常也不好用,因为它们额外增加了认知开销。于是,出现了一批重新发明的编程语言:
- 变量和字符串插值:Ansible 使用 Jinja 模板(!) 进行变量操作。
- Github Actions 为此使用了自定义语法
此外,他们有自己的一套函数来处理变量。你得为此学习一门从来都未曾想过要学习的新语言。
- 范围
例如,在 Github 操作中有几个针对于 env 指令的自定义作用域。 - 控制流
- 循环:构建矩阵和“排除”总是让人头疼不已
if 语句:例如,CircleCI 中的 when
- 无法被校验。可以校验配置语法本身(例如,检查 JSON 串的正确性),但无法做语义检查。这是因为在配置文件中没有逻辑。通常情况下,你必须编写一个辅助程序来检查配置,并在传递给程序之前调用。很少有程序会遇到这个问题,通常,使用简单的类型系统就可以发现程序中的细小错误。
- YAML 的隐式转换和可移植性问题非常突出。这一点已经饱受非议,所以在此只提供一个相关链接,供感兴趣的读者自行了解:“ YAML:可能没那么好”
总结:我们在花时间学习没什么用处的语法,而不是在富有成效地完成工作。
解决方法
当遇到这些问题时会出现什么情况呢?通常最终会使用一种“真正的”(即通用的、图灵完备的)编程语言来解决问题:
- 编写一个过滤自定义注释语法的程序;
- 编写一个合并配置或使用模板引擎的程序;
- 编写一个“evaluate”配置的程序,在此过程中,常常需要为一门简单的函数式语言重新实现一个解释器;
- 编写一个校验配置的程序。
在大多数情况下,它就是类型检查的样板文件。你不仅要处理已解决的问题,而且得到的错误消息质量也不高,所有这些事情都会分散你在主要目标上的注意力。
使用一门真正的编程语言
其思想是用目标编程语言编写配置。这里我将使用 Python,但是,这一思想也适用于其他语言,只要足够动态即可(比如 Javascript、Ruby 等等)。这样,只需 import 或 evaluate 配置文件就可完成。
一个小例子:
config.py
from typing import NamedTuple
class Person(NamedTuple):
name: str
age: int
PEOPLE = [
Person('Ann' , 22),
Person('Roger', 15),
Person('Judy' , 49),
]
使用这个配置(如果你想知道为什么我使用 exec 而不是 import,请看看这个回复):
from pathlib import Path
config = {}
exec(Path('config.py').read_text(), config)
people = config['PEOPLE']
print(people)
[Person(name='Ann', age=22), Person(name='Roger', age=15), Person(name='Judy', age=49)]
我觉得它很简洁。让我们看看如何解决上文所述问题:
- 注释:很明显,不需赘述
- 包含:很简单,使用 import
你甚至可以 import 正在配置的包,可以针对配置定义一个 DSL,它将在配置文件中进行导入和使用。
逻辑
你可以使用语言的语法和库。例如,单独使用像 pathlib 之类的可以节省大量重复配置。
当然,随意乱用可能会让人难以理解。就我个人而言,我宁愿接受语言被滥用,也不愿受限制。
校验
你可以将逻辑校验保留在配置中,以便在加载时进行检查。成熟的静态分析工具(如 JS flow、eslint、pylint、mypy)对此可以有所帮助。
缺点
互操作性
如果程序是用 Python 编写的,那没什么问题。但如果不是,或者稍后将以另一种语言(比如 C++ 之类的编译语言)重写它,该怎么办呢?
将来,软件是否无需解释器即可运行?现代的 FFI 很是繁琐,链接配置将相当棘手。
我们特别以 Python 为例,大多数现代 OS 发行版中都有它。那么,你可以按以下方式来做:
1.使 Python 配置可执行
2.在 main() 函数中构建配置,转换为 JSON 串并输出到 stdout
由于 Python 是动态的,所以无需样板文件即可执行此步骤。
3.在代码中执行 Python 配置(比如,使用 popen()),读取原生的 JSON 串并予以处理。仍然需要手动在代码中将配置反序列化,但这至少不像只使用 JSON 并手动编辑它那么糟。
通用编程语言很难推理
这多少有点主观。就我个人而言,我更有可能被一个过于冗长的普通文本配置搞得不知所措,我一直都更喜欢简洁的 DSL。其中一个重要因素是代码风格:我确信你可以使配置文件在几乎任何编程语言中都具有可读性,甚至根本不熟悉该语言的人也能够看得懂,最大的问题可能是安全性和终止检查。
安全性
例如,如果配置可以执行任意代码,那么它可能会窃取密码、格式化硬盘等。
如果配置是由你不信任的第三方提供的,那么,我认为普通文本配置更安全。然而,通常并非如此,一般都是用户自己控制自己的配置。
此外,也可以通过沙箱解决这一问题,是否值得这样做取决于项目的性质,但是如果你使用像 CI executor 之类的东西,无论如何都需要它。
另外要注意,使用普通文本的配置格式不一定能躲过这些麻烦。参见“ YAML:一般并不安全”。
终止检查
即使不关心安全性,也不希望配置会挂起程序。我个人从来没有遇到过这样的问题,但这里有一些潜在的解决方法可供参考:
- 为加载配置指定显式的超时时间
- 有些语言能够有所帮助,例如, Bazel Skylark
有人知道在通用语言中检查终止的保守的静态分析工具的例子吗?注意,使用普通文本配置并不意味着它不会无限循环,参阅 "Accidentally Turing complete" .
配置会花很多时间去 evaluate,虽然技术上需要在有限的时间内完成,请参阅 "Why Dhall advertises the absence of Turing-completeness" 。虽然 Ackermann 函数是一个人为设计的例子,但它表明如果你真的关心恶意输入,那么无论如何都要做沙箱处理。
为什么是 Python?
我发现出于以下原因,大家都特别喜欢用 Python 来编写配置文件:
- 几乎所有的现代操作系统中都有 Python
- 大家认为 Python 语法很简单(不是件坏事),所以 Python 配置很有可能不会比普通配置更难理解
- 数据类、函数和生成器构成了精简的 DSL 的基础
- 类型标注同时用作文档和校验
其实,你可以在大多数现代编程语言中获得类似的愉快体验(只要它们足够动态)。
还有谁在做这件事?
一些项目允许用代码作为配置:
- Webpack ,Web 模块打包器,使用 Javascript 作为配置
- setuptools ,安装 Python 包的标准方法
允许同时使用 setup.cfg 和 setup.py 文件。这样的话,如果你不能以普通文本配置完成你的需求,那么可以在 setup.py 中进行调整,从而使你可以在声明式和灵活性之间取得平衡。
- Jupiter ,交互式计算工具
使用一个 python 文件配置输出。 - Emacs :大家都知道使用 Elisp 进行它的配置
虽然我一点也不喜欢 Elisp,但它确实使 Emacs 非常灵活,可以实现你想要的任何配置。另一方面,如果你曾经读过其他人的 Emacs 设置,那么你可以发现,当你允许使用通用语言进行配置时,有些事情可能很难操控。 - Surfingkeys 浏览器扩展:使用 Javascript DSL 进行配置
- Gradle 支持以 Groovy 和 Kotlin DSL 来编写构建文件
- Awesome Window Manager 使用 Lua 进行配置
- Guix 包管理器:使用 Guile Scheme 进行配置
有些语言是专门为配置而设计的:
- Bazel Skylark 使用 Python 的一个子集来描述构建规则
虽然为了确保终止检查和确定性而特意对 Bazel 进行了限制,但是配置 Bazel 比我使用过的任何其他构建系统都要愉快得多。
- Meson 构建系统:借鉴 Python 的语法
- Nix :专门为 Nix 包管理器设计的语言
虽然弄一门全新的语言让人感觉有点大材小用,但是仍然好过用普通文本来进行配置。
- Dhall :专门为配置文件设计的语言
Dhall 宣称自己是“JSON + 函数 + 类型 + 导入”。的确,它看起来很棒,解决了我上文列出的大部分问题。
- Jsonnet :JSON + 变量 + 控制流
它们之间的具体区别,请参阅其他配置语言间的比较
这种语言的缺点是还没有被广泛使用。如果你没有绑定目标语言,那么需要二次解析 JSON。
但是,至少它能使你可以愉快地编写配置。
然而,如果你的程序是用 Javascript 编写的,并且不与其他语言交互,那么为什么不直接用 Javascript 编写配置呢?
如果一个也不选要怎么办?
在使用普通文本配置的时候,我找到了一些减少那些问题的方法:
尽量少写配置文件
这通常适用于 CI 流水线配置(例如 Gitlab、Circle、Github Actions)或 Dockerfiles。通常情况下,这样的配置使用了大量的 shell 命令,如果不逐行复制,就不可能在本地运行。
是的,的确也有调试的方法,但是它们的反馈周期非常慢。
- 使用更适合设置本地虚拟环境的工具,如 tox-dev/tox
- 更多地采用 helper shell 脚本,并从你的流水线中调用它们
这多少有点令人沮丧,因为它引入了间接而分散的代码。但是,同时它也是一个优势,你可以剥离(例如 shellcheck)你的流水线脚本,使它更容易在本地运行。有时,如果你的流水线很短,你可以视情况做出自己的判断。让 CI 只负责为你设置 VM/ 容器、缓存依赖项和发布构件。
生成而不是手动编写
这样做的缺点是,相比于手工编辑而言,生成的配置可能会更分散。
你可以添加警告注释,提醒该配置是自动生成的,并附上生成器的链接,同时将配置文件设置为只读,以防止有人手动编辑。
此外,如果你正在实行 CI,可以将一致性检查作为流水线本身的一部分。
参考资料
- (命令行)标记非常适用于配置
总体上,我同意这一观点,但是仍然有些情况是不适用于标记的。
它也容易泄露机密(密钥、令牌、密码)——无论是在你的 shell 历史记录中还是通过 ps 都可以看到。
- Xmonad :配置文件是可执行文件
一个有趣的方法,但不一定总是可行的,例如,你可能没有安装编译器。 - Mage :以 Go 编写用于 makefile 的工具
- Dhall wiki:可编程的配置文件
- 扩展语言的演变:Lua 的历史——显然 Lua 已经开始成为配置语言
- Cue :定义、生成和验证数据的语言
我在网站上找了很久才找到一个代码例子,就在这里。
- 配置复杂性时钟:一个硬编码的例子
最后的问题
之于现在为什么 YAML 成为一个主流选择,我还没有答案。我相信,Ansible/CircleCI 或者 Github Actions 都出自于非常优秀的工程师之手,他们应该考虑过使用 YAML 的利弊。
欢迎大家在评论区留言,分享你在做配置时经受过的痛苦,以及是如何解决它的。
【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/zhibo立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK