V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
eephee
V2EX  ›  DevOps

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

  •  
  •   eephee · 2023-07-05 10:58:07 +08:00 · 3383 次点击
    这是一个创建于 487 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

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

    changelog 可以通过 git commit log 替代吧,单独抽个 changelog 出来会不会出现更新不当的问题?
    nothingistrue
        16
    nothingistrue  
       2023-07-05 16:42:16 +08:00
    配置也需要版本化。DevOps 要求的可不止代码版本化,配置、构建脚本都是要做版本化的。
    sunxiaping521
        17
    sunxiaping521  
       2023-07-05 17:22:28 +08:00
    @nothingistrue 那不就是 ArgoCD 吗?太好用了~
    arischow
        18
    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
        19
    eephee  
    OP
       2023-07-05 19:18:35 +08:00
    @arischow 确实我们目前没有很贯彻 configuration as code 那一套,目前 helm charts 也是放在一个单独的仓库里面的,还没有放到每个服务的仓库里面去。

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

    但是其实还是有一些东西要人为操作的:比如某些比较敏感的环境变量(比如一些 password ),还是需要人去配置的,这部分东东没法放到仓库中。
    eephee
        20
    eephee  
    OP
       2023-07-05 19:29:05 +08:00
    @sunxiaping521 请教一下,使用 argocd 时,每当有新提交,就需要构建最新的镜像,并且把服务的镜像也更新。那这样的话,是不是每一次服务代码更新,都需要把 yaml 文件改一下呢?那这样的话是不是充斥了很多改 image tag 的提交呢?
    arischow
        21
    arischow  
       2023-07-05 19:32:22 +08:00   ❤️ 1
    @eephee 关于密码管理的实践有很多,我也只是略懂皮毛,我们现在用的是 AWS Secrets Manager ,其他云商应该也有对标产品。

    如果想用代码管理也可以看看: https://github.com/getsops/sops
    zhuzhibin
        22
    zhuzhibin  
       2023-07-05 22:41:44 +08:00 via iPhone
    我们不论是项目还是需求都会编写上线清单,上线前按照上线清单以及上线计划执行
    AngryPanda
        23
    AngryPanda  
       2023-07-06 08:47:01 +08:00 via iPhone
    @sunxiaping521 argo cd 应该是持续交付工具(根据官网),cd = continuous delivery
    sunxiaping521
        24
    sunxiaping521  
       2023-07-06 08:47:40 +08:00
    @eephee ArgoCD 是持续部署工具吧;逻辑其实很简单,ArgoCD 支持 kustomize 、基本的 yaml 方式以及 Helm 等方法,并且其实就是在 Git 仓库中维护了一个项目而已;当你用 CI 工具(持续集成工具,如:Jenkins ) 等将镜像构建并推送到 Docker 仓库(如:Harbor 仓库),然后更新 Git 仓库中的镜像版本即可,ArgoCD 默认会 3 分钟自动同步 Git 仓库中的配置到环境中;当然,你也可以手动同步;或者配置 Argo 和 Git 仓库的钩子,实现自动的持续部署。
    sunxiaping521
        25
    sunxiaping521  
       2023-07-06 08:48:16 +08:00
    sunxiaping521
        26
    sunxiaping521  
       2023-07-06 09:01:44 +08:00
    @eephee @AngryPanda 我没办法发流程图的图片,aHR0cHM6Ly9pLmltZ3VyLmNvbS9xb0hiZDBsLnBuZw== 这个是 base64 编码,你解码,就能看到对应的图片地址了。
    8355
        27
    8355  
       2023-07-06 09:11:47 +08:00
    我不是很理解这个东西需要什么特别的工具吗。。
    难道不是你要习惯性的检查一下即将要上线的代码或者文档起码看一下 commit 的记录 应该也能想到需要加个配置吧。。。
    eephee
        28
    eephee  
    OP
       2023-07-06 09:51:00 +08:00 via iPhone
    @sunxiaping521
    > 然后更新 Git 仓库中的镜像版本即可

    这样的话那个 git 仓库里面是不是充斥了大量的改 docker image tag 得提交?主要是这点我不太喜欢
    eephee
        29
    eephee  
    OP
       2023-07-06 09:51:47 +08:00 via iPhone
    @8355 仓库太多了,我没有参与核心业务开发,所以看不过来🥺
    sunxiaping521
        30
    sunxiaping521  
       2023-07-06 09:55:20 +08:00
    @eephee 随你~
    eephee
        31
    eephee  
    OP
       2023-07-26 15:26:04 +08:00
    @sunxiaping521 请教一下你们也是微服务吗?能不能分享一下你们的那个存储 charts 的 git 仓库的结构呢?
    eephee
        32
    eephee  
    OP
       2023-08-07 22:40:46 +08:00
    最终走了

    * helm/helmfile/helm-secrets/sops
    * gitlab-ci/yq

    的路线,只不过是用 `helmfile template` 生成 k8s manifest 最后 `kubectl apply` 的
    eephee
        33
    eephee  
    OP
       2023-08-26 14:19:38 +08:00
    最终还是弃用了 helmfile ,直接将 charts 包放在中各个仓库下面,结合 gitlab-ci ,目前用下来感觉很不错,打算长期这样使用
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2816 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 13:02 · PVG 21:02 · LAX 05:02 · JFK 08:02
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.