上线时需要将迭代期内的各种配置改动同步到生产环境,有没有好用的配置备忘录的工具?

2023-07-05 10:58:07 +08:00
 eephee

比如代码从开发环境提交到 staging 环境,那么对应的配置(比如 服务配置、环境变量、数据库改动、创建 s3 bucket...)也需要上到对应的环境,如果同时有多个环境,那么配置的管理就比较麻烦,很容易遗漏,有什么好用的工具来做这个事情吗?

关于数据库改动,有 yearning 或者 bytebase 这样的工具,但是这俩工具只针对数据库的场景

3411 次点击
所在节点    DevOps
33 条回复
chendy
2023-07-05 11:16:11 +08:00
在项目里专门建个路径,里面放一堆 txt ( md 也行,但是考虑到有些大哥不知道 md 是啥,还是 txt 稳妥)
里面详细描述发版过程(比如说,先备份数据库到哪里哪里,然后修改表定义如何如何
虽然土,但是还是很有效的,主要对人员水平要求相对低,对着干就行
还适合各种奇形怪状的想自动化但是成本过于高的项目们
LeegoYih
2023-07-05 11:20:53 +08:00
每个版本迭代都会写技术方案文档(比如语雀、金山文档),除了技术方案本身还会把需要执行的脚本、添加的配置、申请的资源、涉及的服务等列出来做一个 TODO LIST ,开发期间有变动就补充,及时通知相关人员,发布前完成一个打一个勾。
工作这么多年没有发生过漏配置、SQL 漏执行类似低级错误。

推动团队流程规范最重要,工具看团队哪个方便用哪个。
dobelee
2023-07-05 11:21:16 +08:00
每个需求方案设计时就建一个 todo list 文档。
sunxiaping521
2023-07-05 12:16:01 +08:00
Jenkins + ArgoCD ,不过 Jenkins 只是 CI 工具,可以替换成任意的 CI 工具,ArgoCD 是持续集成工具,你可以了解一下。
flyqie
2023-07-05 13:02:40 +08:00
@chendy #1

真有大哥到现在都不知道 md 是啥的吗。。有点震惊。

txt 样式这块非常不好搞啊。。

比如表格,加粗,段落,字体大小,代码块,列表什么的。。
WispZhan
2023-07-05 13:04:30 +08:00
先手动整理流程,建立规范。 然后尝试用自动化方案,减少重复。
1. 整理迭代内容,输出 TODO-List
2. 明确迭代规范,将内容流程化,保证换个人也能正常事实。解放自己
3. 调研配置、DB 的 Migration ,比如数据库的 Flyway 或者 Liquibase 。
4. 集成到 CI/CD ,解放团队。
WispZhan
2023-07-05 13:05:27 +08:00
写脚本,写工具。 没有工具就制造工具。DRY
eephee
2023-07-05 13:52:13 +08:00
看了下好像大家普遍会用文档的形式来记录,emmm 为啥我总感觉文档的形式记录不太直观。

我目前是尝试使用 JIRA 来搞,但是 JIRA 里面一个事项的状态转换是有流程顺序的,对于环境比较多而且并行的情况下(比如两家私有部署客户的配置更改)还是没法适用。

k8s 配置的话,我们测试环境已经在尝试使用 helm 那套了,但是生产环境一开始没有用 helm 。如果需要使用 helm 的话,那些负载得重新创建,一直不太敢下手。。。
arischow
2023-07-05 14:43:44 +08:00
写成 release plan / rollback plan
skyrim61
2023-07-05 14:46:39 +08:00
都是记事本记录, 等时间久了就忘记, 然后再写一个记事本,然后故障还是会发生
eephee
2023-07-05 15:20:37 +08:00
@arischow 请教下有什么好用的工具来做这个事情嘛?还是也是写成文档呢?感觉这个文档的格式约定也需要好好斟酌一下
proxychains
2023-07-05 15:28:48 +08:00
README 呗. changlog 啥的也加上, 跟着项目迭代走
chendy
2023-07-05 16:07:55 +08:00
@flyqie 有,而且很多…
这种文档不需要啥格式,就是把所有需要的操作罗列下去就行
最多就是空格换行做好,方便用的时候复制粘贴
sunxiaping521
2023-07-05 16:28:06 +08:00
@eephee 如果我没记错的话,JIRA 已经死了吧
flyqie
2023-07-05 16:30:31 +08:00
@proxychains #12

readme 可以理解,changelog 不太理解。。

changelog 可以通过 git commit log 替代吧,单独抽个 changelog 出来会不会出现更新不当的问题?
nothingistrue
2023-07-05 16:42:16 +08:00
配置也需要版本化。DevOps 要求的可不止代码版本化,配置、构建脚本都是要做版本化的。
sunxiaping521
2023-07-05 17:22:28 +08:00
@nothingistrue 那不就是 ArgoCD 吗?太好用了~
arischow
2023-07-05 18:46:43 +08:00
@eephee 重新看了一下你的描述,你们的配置应该是没有人代码管理对吗?(例如用 Terraform / Helm / Jsonnet )

我们对于没有上云的项目(没有办法用到我前面所述的这些工具)现在的做法是需要写 release plan / rollback plan ,如果你们公司有订阅 Confluence / Jira ,用来写文档作为知识共享是再方便不过。Release plan / rollback plan 也应该让其他同事 review ,具体的文档格式当然可以约定,我认为一个合格的 plan 应该是交由哪位同事做,只要看着文档来操作就可以完成。
eephee
2023-07-05 19:18:35 +08:00
@arischow 确实我们目前没有很贯彻 configuration as code 那一套,目前 helm charts 也是放在一个单独的仓库里面的,还没有放到每个服务的仓库里面去。

看下来其实最好的做法就是尽可能地将所有的配置放到仓库里面:比如创建 s3 bucket 也可以搞一个脚本放到版本控制里面,然后一切交给版本管理的流程去做。

但是其实还是有一些东西要人为操作的:比如某些比较敏感的环境变量(比如一些 password ),还是需要人去配置的,这部分东东没法放到仓库中。
eephee
2023-07-05 19:29:05 +08:00
@sunxiaping521 请教一下,使用 argocd 时,每当有新提交,就需要构建最新的镜像,并且把服务的镜像也更新。那这样的话,是不是每一次服务代码更新,都需要把 yaml 文件改一下呢?那这样的话是不是充斥了很多改 image tag 的提交呢?

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

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

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

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

© 2021 V2EX