如何能检测 Nginx 实际配置变更和配置变更备注的等价性？
zhoudaiyu · 2021-04-20 22:07:41 +08:00 via iPhone · 2254 次点击这是一个创建于 1300 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们的 nginx 变更平台当前阶段最多通过 ansible 把 nginx.conf 拷贝到目标机器的临时文件夹上，然后用 nginx -t 验证一下配置，这样可以解决配置语法的问题。但是如果比如变更备注写的减少某个 upstream 的参与负载机器，结果有个兄弟不小心把配置文件该 upstream 机器全都注释掉了，就变成了 0 台机器了。但是这样可以通过 nginx 的语法检查。类似的这种例子还很多，比如 server_name 域名少打一位等等。我们现在 nginx 配置变更就相当于直接修改 http 块的配置，整个 http 里面的内容都直接编辑，然后通过模板渲染一些固定参数后推送，并没有把 nginx 的所有配置表单化，而且变更备注也没有做成表单化，这样带来的问题是，没法验证实际变更和备注里面的逻辑的等价性。但是把 nginx 配置完全表单化难度也不小，因为 nginx 配置文件里面也可以写 lua 脚本什么的，变更备注表单话也是比较复杂的，因为能变更的种类真的太多太多。但是如果不表单化想检查逻辑可能就要用 NLP 等技术去解析语义了，有点弄复杂了。大家这块有啥好的方法没？
 |
1
dzdh 2021-04-21 00:10:54 +08:00  1
etcd + confd ?
|
 |
2
wd 2021-04-21 01:35:34 +08:00 via iPhone
监控 health check 啊？
|
 |
3
neoblackcap 2021-04-21 02:06:01 +08:00 1
这需求完全用不到 NLP，不就是配置文件解析。你大可将 nginx 源代码里面解析配置文件的哪部分代码拿出。然后每次解析一次配置文件。然后对比两次的结果，以及进行一些校验。
|
 |
4
defunct9 2021-04-21 06:56:23 +08:00 via iPhone
上 k8s 啊，ingress 只让他改 location
|
 |
5
zhoudaiyu OP @dzdh 我们是用的 ansible，因为还涉及到一些 nginx 的其他运维操作
@wd 这个就有点晚了，相当于已经发生故障再通过监控告警去解决了 @neoblackcap 您说的这个对，但是现在想理解变更配置的缘由，也就是说得把变更原因这块也解析出来，再看和变更的配置能不能 match @defunct9 我们木有上 ingress 哇，所以... |
|
6
wd 2021-04-21 07:19:50 +08:00 via iPhone
你可以在发布之前把监控的检查都跑一遍再上线。又不是一定要等故障发生。监控的目的是把你关心的内容抽象出来。
|
 |
8
netnr 2021-04-21 08:38:48 +08:00 via Android
个人有个简单的想法
提取你们现有服务关键字(内网服务端口 域名 静态路径等)，然后正则匹配 nginx 配置文件是否包含了所有的关键字 |
 |
9
cominghome 2021-04-21 08:47:24 +08:00
“实际变更和备注里面的逻辑的等价性”，能做到这个水平还搞啥运维啊
不要什么都想靠技术解决，我感觉这事很简单吧，引入变更流程，每次变动 diff 一下新旧配置，再找个人复核一下就完事 |
 |
10
zliea 2021-04-21 08:55:34 +08:00
我的想法是为什么不用代码生成配置文件。
|
 |
11
hanxiV2EX 2021-04-21 09:20:04 +08:00 via Android
自己用 json 或者 yml 定义这些配置，然后生产 nginx 配置。
|
 |
12
rrfeng 2021-04-21 09:26:18 +08:00 via Android
那应该直接检测 Nginx 进程内存里的配置是否等价于预期。
|
 |
13
37Y37 2021-04-21 09:34:15 +08:00
配置统一管理，修改后对比 https://blog.ops-coffee.cn/s/qg42uqj9rnswqdmd41cyug
|
 |
14
littleFive 2021-04-21 09:43:09 +08:00
不如在配置文件夹里面建一个 git 仓库，用 git 管理起来
|
 |
15
killva4624 2021-04-21 09:50:02 +08:00
添一个测试环境，配置正式推送到线上环境前先上测试环境跑一遍必要的 HTTP 接口测试。
|
 |
16
matrix67 2021-04-21 09:54:00 +08:00
> 但是如果比如变更备注写的减少某个 upstream 的参与负载机器，结果有个兄弟不小心把配置文件该 upstream 机器全都注释掉了，就变成了 0 台机器了。
> 但是这样可以通过 nginx 的语法检查。类似的这种例子还很多，比如 server_name 域名少打一位等等。 这个是提配置没有 review 啊，提配置也要人 double check 的啊！ 合入配置仓库要有 diff view，要有人 merge 的 |
|
17
matrix67 2021-04-21 09:57:12 +08:00 1
还有楼主写这么大一团文字不分段，看的人头疼，你们配置要是这么合那根本没法 diff 。
|
 |
18
dallaslu 2021-04-21 11:00:38 +08:00
用过 1 楼 @dzdh 提到的 etcd + confd 方案。如果为了避免 upstream 无节点、打错 server_name，可以把这一部分做成表单；然后配置文件模块化，依然不影响修改 http 块、写 lua 脚本。
如果不管理起来，永远都是一团乱麻。git 版本控制，配置变更加入审核环节，遇监控报警自动退回上一版本 |
 |
19
crclz 2021-04-21 11:21:58 +08:00
审查+测试
|
|
20
defunct9 2021-04-21 11:29:33 +08:00
@zhoudaiyu 没有就上啊。不上就单独给这些人写个 jinjia location temple，只让他们改 location，ansible 单独开个 playbook 只让改 location 不就完了。
|
 |
21
realpg 2021-04-21 12:34:22 +08:00
这个很简单嘛。。。
两个人独立修改配置文件，并提交到仲裁系统 然后仲裁系统去掉一切排版的空格 tab，然后俩人的配置完全一样就通过 不一样就发回去让两个人重新写…… |
Select Language