管理 Helm Chart CI 中缺失依赖项的常见做法
假设一个 product 图表包含两个子图表，app 和 config，app 取决于 config，例如，部署依赖于configmap挂载卷。真正的场景可能是共享相同 config 的多个 app 图表，但为了简单起见，这里只有一个。
目标
产品图表设计需要支持多个版本在同一命名空间中共存，并且彼此隔离。- 仅需要
appci成功，这里成功仅表示app图表可以成功部署到k8s，无需进行功能测试。
问题
为了实现目标1，我认为自然的方法是模板在 config 名称前添加 {{ .Release.Name }}< /代码>。 但是在 ci 中，依赖项 {{ .Release.Name }}-config 丢失，因此显然 ci 会失败。因此违反了目标 2。
可能的解决方案
- 在
appci 之前（或期间）部署config，但这会给 ci 带来额外的工作量和资源占用。 - 在
app图表中添加if else逻辑来判断当前是否在ci中，如果为true，则不渲染那些config部分。但只为 ci 引入图表逻辑似乎很愚蠢。
那么这是 k8s helm Charts 开发中的常见问题吗？最佳实践是什么？是否有现有的 k8s 机制可以在 ci 部署期间轻松模拟对象？
Imagin one product chart contains two sub charts, app and config, app depends on config, for example, a deployment depend on configmap mounting volume. The real senario could be multiple app charts sharing same config, but only one here for simplicity.
Goal
productchart design need support coexistance of multiple releases in same namespace, isolated with each other.- Need
appci success alone, here success only means theappchart can be successfully deployed to k8s, no need function tests.
Problem
To accomplish goal 1, I think the natual way is template prefixing config name with {{ .Release.Name }}.
But when in ci, the dependency {{ .Release.Name }}-config is missing, so apparently ci would fail. So violates goal 2.
Possible solutions
- Deploy
configbefore(or during)appci, but this causes extra effort and resource usage to ci. - Add
if elselogic inappchart to determine whether currently is in ci, if true, not render thoseconfigparts. but introduce a chart logic only for ci seems foolish.
So is this common problem in k8s helm charts development, and what's the best practice? Is there any existing k8s mechanism to easily mock a object during ci deployment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论