我正在开发一个基于Kubernetes的修补程序CI系统，每个构建作为一个Job启动。我像Drone CI一样运行这些，因为构建中的每个步骤都是一个单独的容器。在我的k8s CI案例中，我将每个步骤作为Job pod中的容器运行。这是我之后的行为：
我目前正在为共享构建空间使用带有emptyDir Volume的单个Job pod。我这样做是为了让我们不必等待一个卷在节点/ Pod之间进行混乱。这似乎也是确保在构建出口处自动清理事物的好方法。
问题在于，如果我使用上述所有步骤启动多容器作业，它们会同时执行。这意味着＆＃39;运行测试＆＃39;步骤可以在'git＆＃39;之前开火。步骤
我已经考虑过在每个容器中提出某种逻辑来睡觉，直到某个解锁/我完成了！＆＃34;文件出现在共享卷中，表示依赖步骤已完成，但这似乎很复杂，足以在继续之前询问备选方案。
我可以通过协调工作看到让步和使用多个职位，但后来我进入了Volume Claim领域（这比emptyDir要复杂得多）。
总结一下这个问题：
我目前的做法是否值得追求，如果是，如何对作业的容器进行排序？我希望能够提出适用于AWS / GCE 和裸机部署的内容。
我对触摸PVC犹豫不决，因为管理和清理工作不是我希望我的系统负责的事情。当emptyDir工作得很好时，我也不想要网络存储。
编辑：请不要建议使用其他现有的CI系统，因为这没有用。我这样做是为了我自己的满足和实验。这个修补匠CI系统不可能只是我的玩具。
答案 0 :(得分：0)
如果您希望所有构建步骤都在容器中运行，GitLab CI或Concourse CI可能更适合您。我没有使用fabric8.io的经验，但Frank.Germain表示它也可以使用。
一旦你开始变得足够复杂，你需要在容器之间发信号来订购构建步骤，那么使用预先滚动的东西会变得更有效率。
作为一个选项，您可以使用静态卷（即host path作为工件缓存，并从当前容器依次触发下一个容器，在各阶段之间安装相同的卷。然后您可以添加构建的开始或结束的一步，以便在管道运行后“清理”。
要明确： 我不认为滚动自己的CI是处理此问题的最有效方法，因为已经存在的系统将完全符合您的要求寻找