项目的目录结构与Dockerfile，Jekinsfile，Kubernetes部署yaml，pip requirements.txt和testing脚本？
下面的目录结构是否可以工作？
目标是让Jenkins触发GitHub提交并运行构build和testing容器的多分支pipe道。 （我拥有包括Jenkins在内的所有Kubernetes）
/project .git README.md Jenkinsfile /docker_image_1 Dockerfile app1.py requirements.txt /unit_tests unit_test1.py unit_test2.py /docker_image_2 Dockerfile app2.py requirements.txt /unit_tests unit_test1.py unit_test2.py /k8s /dev deployment.yaml /production deployment.yaml /component_tests component_tests.py - 是否在正确的位置有deployment.yamls的k8s文件夹？
- testing文件夹是否位于好的位置？ “component_tests”中的testing最好是进行更多涉及多个容器的端到端集成testing
- 我看到很多repos有Jenkins文件和Dockerfile在同一目录级别。 那有什么优点和缺点？
这是真的留给你的偏好很多。 在我们的项目中，我们倾向于将服务拆分成独立的存储库而不是子文件夹，但是我们也遇到了一个以相似的方式pipe理一堆Scala微服务的案例（尽pipedocker是用docker的sbt插件构build的）
我会给你一个很大的build议，就是从长远来看，pipe理你的kubernetes这样的performance可能会在后面变成严重的痛苦。 我经历了这个，我的build议是从第一天开始使用helm图。
我假设你的“component_tests”是端到端的testing。 其他的命名我没有看到这个问题。 对于我们testing跨多个回购的解决scheme的情况，我们也把它们放在单独的回购中。
目前这个问题没有很好的答案。
Kubernetes提供了一个用于部署的标准API，但作为一项技术，它依赖额外的第三方工具来pipe理ALM工作stream的构build部分。 有很多选项可用于将源代码转换为在Kubernetes上运行的容器。 每个组件对于源代码的组织方式以及如何从Jenkins等CI / CD服务器调用部署都有其自身的后果。
我提供以下选项供您考虑，粗略分类。 代表我目前的评估列表。
“平台即服务”工具
工具pipe理您的代码的整个ALM生命周期。 强大但更复杂，更有见地
- Deis工作stream程
- Openshift
- Fabric8（参见Openshift.io）
构build和部署工具
对于开发过程中常见的代码/testing/代码/重新testing工作stream程有用的工具。 也可以从Jenkins调用来抽象你的构build过程。
- 草案
- 锻造
- Kcompose
- Fabric8 Maven插件（Java）
- Psykube
YAML模板工具
kubernetes YAML从来没有被devise为人类使用。 几个启发，使这个过程更简单，更标准化。
- 舵
- Ksonnet
部署监视工具
这些工具有他们希望find位于你的源代码库中的Kubernetes清单文件（或舵图）的约定。
- 龙骨
- KUBE -应用
- Kubediff
- 园艺师
- 套件
支持k8s的CI / CD工具
- 三angular帆
- Gitlab
- jenkins+ Kubernetes CI插件
- jenkins+ Kubernetes插件