集群定制构建(cluster-specific build)流程的改善提议

[timfeirg]

比方说 node 系前端应用, 往往需要在不同集群用定制的构建流程. 而大家又喜欢用 lain deploy --build 这个命令来进行上线, 这就导致一个大问题: lain deploy --build 并不会重复构建应用, 那么如果不同的集群都在用同一个 registry, 那就会将 A 集群专用的镜像, 部署到 B 集群, 然后应用就乱了套.

这是个很古老的问题了, 先前一直企图用文档的方式教大家如何处理, 如何采用最佳实践, 比如:

• https://lain-cli.readthedocs.io/en/latest/errors.html#b-a
• https://lain-cli.readthedocs.io/en/latest/best-practices.html#values-cluster-yaml-appname

无奈文档的效果并不佳, 既然文档的效果不好, 那就要想办法用技术的方式解决. 因此在这里做一些设想.

如有定制构建, 必须超载 appname

lain build 不再允许在不超载 appname 的情况下, 进行集群定制构建覆盖镜像的操作.

比方说, 我为一个 lain app 添加了 values-prod.yaml, 书写了定制构建, 然后运行 lain build. 这时候, lain 会对 values 进行检查, 注意到了我虽然在 values-prod.yaml 里书写了 build, 却并未超载 appname, 于是 lain 直接报错, 并提醒如何修复.

让镜像携带更多元信息, 并在上线的时候进行校验

比方说, docker image 其实是支持用 labels 添加各种信息的. 我们可以将构建时所面对的集群写入 labels. 将来上线的时候, 如果检测到当前集群有定制构建, 而面对的镜像, 却没有相匹配的 labels, 那么就中断部署, 报错提示.

这是我个人更爱的方案, 没那么规训的同时, 又完全能避免犯错, 行为上比强制要求超载 appname 要更贴心. 但无奈, 并不是每一家 PaaS 都提供容器镜像的 labels 查询接口, 比如 Aliyun CR 就没有.

当然了, 也不一定非要用 labels 来存放集群信息, 像是 image repo, tag, 其实都可以. 但这些都是破坏性的修改, 目前不考虑.

[hongqn]

针对第二个设想提一个 lain1 中的设计，看看是否有参考性

lain build 时，除了构建出 release image 之外，还会构建出一个 meta image，这是一个仅有配置文件（lain.yaml）的空白镜像。lain 系统在操作 release image 前会先拉取该 meta 镜像并解开来读取配置。

[timfeirg]

为啥定制构建了就一定要做镜像空间隔离? 这么做虽然避免了"把镜像部署串了"的问题, 但也给开发者带来不少心智负担. 最重要的, 这个设计有些许反直觉 (我没做啥特别的事情哇, 为啥莫名其妙要求我超载 appname?)

将会撤销当时加入的设计, 然后用以下检查代替:

• 每次运行 lain deploy --build 的时候, 检查是否已经部署了相同版本. 如果为 true, 则阻止部署, 讲明原因
• 每次部署完成以后, 检查容器有没有重建(check age), 如果容器没变化, 给一条 warning, 提示用户可能要重启