分母

最后决定统一使用 on-premise 了

最终还是弃用了 helmfile ，直接将 charts 包放在中各个仓库下面，结合 gitlab-ci ，目前用下来感觉很不错，打算长期这样使用

感谢 OP ，学到个成语 如臂使指 哈哈

恭喜 op
顺便能问下 op 薪资范围吗

最终走了

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

的路线，只不过是用 `helmfile template` 生成 k8s manifest 最后 `kubectl apply` 的

那看起来，自己搭建服务，对自己而言是 self-hosted ；而在公司的角度来说，给客户私有化部署就是 on-promise 。

看下来有点这样的意思

上海，30

分母

@sunxiaping521 请教一下你们也是微服务吗？能不能分享一下你们的那个存储 charts 的 git 仓库的结构呢？

@8355 仓库太多了，我没有参与核心业务开发，所以看不过来🥺

@sunxiaping521
> 然后更新 Git 仓库中的镜像版本即可

这样的话那个 git 仓库里面是不是充斥了大量的改 docker image tag 得提交？主要是这点我不太喜欢

@sunxiaping521 请教一下，使用 argocd 时，每当有新提交，就需要构建最新的镜像，并且把服务的镜像也更新。那这样的话，是不是每一次服务代码更新，都需要把 yaml 文件改一下呢？那这样的话是不是充斥了很多改 image tag 的提交呢？

@arischow 确实我们目前没有很贯彻 configuration as code 那一套，目前 helm charts 也是放在一个单独的仓库里面的，还没有放到每个服务的仓库里面去。

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

但是其实还是有一些东西要人为操作的：比如某些比较敏感的环境变量（比如一些 password ），还是需要人去配置的，这部分东东没法放到仓库中。

@arischow 请教下有什么好用的工具来做这个事情嘛？还是也是写成文档呢？感觉这个文档的格式约定也需要好好斟酌一下

看了下好像大家普遍会用文档的形式来记录，emmm 为啥我总感觉文档的形式记录不太直观。

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

k8s 配置的话，我们测试环境已经在尝试使用 helm 那套了，但是生产环境一开始没有用 helm 。如果需要使用 helm 的话，那些负载得重新创建，一直不太敢下手。。。

@ClericPy 为什么呢

感谢大佬们，我大概明白了，k8S 对这个情况的处理还是挺细的

@iyear
确实，是 resources 是 containerSpec 下面的东西，我没注意到这一点 :thumb_up: