为什么你的Playbook难以维护？

我最近在整理服务器配置时，又被自己写的Playbook给整崩溃了。明明半年前还能正常运行，现在却报了一堆莫名其妙的错误。这让我不得不思考，为什么我们的Playbook总是这么难维护？

记得刚开始用Ansible时，我觉得这玩意儿简直太棒了！把所有操作都写在一个文件里，想怎么部署就怎么部署。结果三个月后，当我需要修改某个配置时，发现这个文件已经长到800多行，连我自己都看不懂当初为什么要这么写。

最要命的是，当时为了赶进度，直接把数据库密码写在了Playbook里。现在要换密码，我得在所有文件里搜索这个字符串，生怕漏掉一个地方。

上周我同事接手我的项目，他问我：”这个nginx_port变量到底在哪里定义的？”我翻遍了整个项目，发现这个变量在三个地方都有定义：group_vars、role defaults，还有个地方是在命令行参数里覆盖的。天知道最终生效的是哪个值！

这种混乱的变量管理，让每次部署都像是在拆炸弹，永远不知道这次会成功还是会爆炸。

我见过最离谱的Playbook，一个文件里同时部署数据库、Web服务器、缓存服务，还夹杂着各种条件判断。这就好比把厨房、卧室、卫生间都塞进一个房间，表面上很方便，实际上住起来要命。

更可怕的是，当我们需要复用某个功能时，只能复制粘贴大段代码。然后某天发现一个bug，就得在所有粘贴过的地方一个个修复。

你有没有遇到过这种情况：明明只是修改了一个小配置，结果整个服务都起不来了？这是因为我们在写任务时，经常忘记加状态判断。

比如重启服务这种操作，如果没有正确的handler机制，可能会导致服务被反复重启。我上次就因为这个，把生产环境的数据库搞挂了十分钟，那十分钟简直是我职业生涯最漫长的十分钟。

还有一个常见问题：我们总喜欢在Playbook里写死路径。结果换了台服务器，就因为目录结构不同，整个部署脚本都失效了。

说真的，你们有给自己的Playbook写过像样的文档吗？反正我之前是没有。直到新同事问我：”这个playbook是要按什么顺序执行？”我才发现，连我自己都记不清了。

现在我的Playbook里到处都是这样的注释：”这里不知道为什么这么写，但改了会挂”、”这个参数的意义不明，但去掉就报错”。这哪是自动化脚本，分明是考古现场。

说到底，Playbook难以维护的根源在于，我们总是把它当成一次性脚本，而不是一个需要长期维护的软件项目。下次写Playbook时，不妨问问自己：三个月后的我，还能看懂这玩意儿吗？

评论