如何能检测 Nginx 实际配置变更和配置变更备注的等价性?

2021-04-20 22:07:41 +08:00
 zhoudaiyu

我们的 nginx 变更平台当前阶段最多通过 ansible 把 nginx.conf 拷贝到目标机器的临时文件夹上,然后用 nginx -t 验证一下配置,这样可以解决配置语法的问题。但是如果比如变更备注写的减少某个 upstream 的参与负载机器,结果有个兄弟不小心把配置文件该 upstream 机器全都注释掉了,就变成了 0 台机器了。但是这样可以通过 nginx 的语法检查。类似的这种例子还很多,比如 server_name 域名少打一位等等。我们现在 nginx 配置变更就相当于直接修改 http 块的配置,整个 http 里面的内容都直接编辑,然后通过模板渲染一些固定参数后推送,并没有把 nginx 的所有配置表单化,而且变更备注也没有做成表单化,这样带来的问题是,没法验证实际变更和备注里面的逻辑的等价性。但是把 nginx 配置完全表单化难度也不小,因为 nginx 配置文件里面也可以写 lua 脚本什么的,变更备注表单话也是比较复杂的,因为能变更的种类真的太多太多。但是如果不表单化想检查逻辑可能就要用 NLP 等技术去解析语义了,有点弄复杂了。大家这块有啥好的方法没?

2256 次点击
所在节点    NGINX
21 条回复
dzdh
2021-04-21 00:10:54 +08:00
etcd + confd ?
wd
2021-04-21 01:35:34 +08:00
监控 health check 啊?
neoblackcap
2021-04-21 02:06:01 +08:00
这需求完全用不到 NLP,不就是配置文件解析。你大可将 nginx 源代码里面解析配置文件的哪部分代码拿出。然后每次解析一次配置文件。然后对比两次的结果,以及进行一些校验。
defunct9
2021-04-21 06:56:23 +08:00
上 k8s 啊,ingress 只让他改 location
zhoudaiyu
2021-04-21 07:01:50 +08:00
@dzdh 我们是用的 ansible,因为还涉及到一些 nginx 的其他运维操作
@wd 这个就有点晚了,相当于已经发生故障再通过监控告警去解决了
@neoblackcap 您说的这个对,但是现在想理解变更配置的缘由,也就是说得把变更原因这块也解析出来,再看和变更的配置能不能 match
@defunct9 我们木有上 ingress 哇,所以...
wd
2021-04-21 07:19:50 +08:00
你可以在发布之前把监控的检查都跑一遍再上线。又不是一定要等故障发生。监控的目的是把你关心的内容抽象出来。
zhoudaiyu
2021-04-21 07:20:49 +08:00
@wd 鄙人不才,我主要是靠日志监控😂
netnr
2021-04-21 08:38:48 +08:00
个人有个简单的想法
提取你们现有服务关键字(内网服务端口 域名 静态路径等),然后正则匹配 nginx 配置文件是否包含了所有的关键字
cominghome
2021-04-21 08:47:24 +08:00
“实际变更和备注里面的逻辑的等价性”,能做到这个水平还搞啥运维啊

不要什么都想靠技术解决,我感觉这事很简单吧,引入变更流程,每次变动 diff 一下新旧配置,再找个人复核一下就完事
zliea
2021-04-21 08:55:34 +08:00
我的想法是为什么不用代码生成配置文件。
hanxiV2EX
2021-04-21 09:20:04 +08:00
自己用 json 或者 yml 定义这些配置,然后生产 nginx 配置。
rrfeng
2021-04-21 09:26:18 +08:00
那应该直接检测 Nginx 进程内存里的配置是否等价于预期。
37Y37
2021-04-21 09:34:15 +08:00
配置统一管理,修改后对比 https://blog.ops-coffee.cn/s/qg42uqj9rnswqdmd41cyug
littleFive
2021-04-21 09:43:09 +08:00
不如在配置文件夹里面建一个 git 仓库,用 git 管理起来
killva4624
2021-04-21 09:50:02 +08:00
添一个测试环境,配置正式推送到线上环境前先上测试环境跑一遍必要的 HTTP 接口测试。
matrix67
2021-04-21 09:54:00 +08:00
> 但是如果比如变更备注写的减少某个 upstream 的参与负载机器,结果有个兄弟不小心把配置文件该 upstream 机器全都注释掉了,就变成了 0 台机器了。

> 但是这样可以通过 nginx 的语法检查。类似的这种例子还很多,比如 server_name 域名少打一位等等。

这个是提配置没有 review 啊,提配置也要人 double check 的啊! 合入配置仓库要有 diff view,要有人 merge 的
matrix67
2021-04-21 09:57:12 +08:00
还有楼主写这么大一团文字不分段,看的人头疼,你们配置要是这么合那根本没法 diff 。
dallaslu
2021-04-21 11:00:38 +08:00
用过 1 楼 @dzdh 提到的 etcd + confd 方案。如果为了避免 upstream 无节点、打错 server_name,可以把这一部分做成表单;然后配置文件模块化,依然不影响修改 http 块、写 lua 脚本。

如果不管理起来,永远都是一团乱麻。git 版本控制,配置变更加入审核环节,遇监控报警自动退回上一版本
crclz
2021-04-21 11:21:58 +08:00
审查+测试
defunct9
2021-04-21 11:29:33 +08:00
@zhoudaiyu 没有就上啊。不上就单独给这些人写个 jinjia location temple,只让他们改 location,ansible 单独开个 playbook 只让改 location 不就完了。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/772009

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX