我推荐3个。到目前为止,我合作过的所有公司都要这样。

从伯尔纳本地人的角度看

一些 Kubernetes本地开发工具,比如DevSpace ( https://github.com/covexo/devspace ) 和草稿 https://github.com/Azure/draft

从 DevOps透视图

使用#3,开发人员将能够更好地再现生产环境以修复错误,并且CI/CD工具通常设置为与基础设施一起工作,就像代码一样包含在同一个repo中的代码一样。

例外情况 ,例如GitLab的Auto-DevOps CI/CD工具。它非常适合与Kubernetes一起工作,并与外部图表一起工作。然而,他们这样做是因为他们想简化到Kubernetes的CI/CD管道的设置,并希望从底层的Helm图表中抽象出来。但是,它们也允许您自己定义一个Helm图表,并暗示它与代码位于同一个存储库中。

从 版本控制透视图

#3是有利的,因为您可以确保在绑定代码和“基础设施”定义时始终可以运行可重复的构建。假设您希望回到过去,使用旧版本的代码,您会使用哪个版本的非相关其他回购?将所有内容都放在一个repo中,将允许您签出任何修订或分支,并始终确保您可以构建和实例化代码。

在我看来,第二个选项是最有意义的一个,当您更改存储库的代码时,您可能需要更改Dockerfile,这样您就可以通过一次推送来触发CI管道。在CI上,您还需要构建容器。Dockerfile也是一种资源,您通常希望DevOps和Dev团队能够访问并经常一起处理它们。

另外,如果您有CI集成,您希望在Dockerfile每次更改后触发管道,当它与代码位于同一位置时,这将非常容易。

然后,您还将所有Kubernetes/Helm文件放在不同的(单个)存储库中,这样您就可以对它们进行管理,并在需要时为不同的微服务组合它们(如果您有更复杂的部署)。在这里的CI中,您只需要对图表/文件进行linting处理。

Telepresence