放置Kubernetes和Dockerfile的位置

Question

我们有几个选项可以正确管理kubernetes的delcaration文件和dockerfiles。服务开发可能被认为是完全独立的，目前没有任何跨服务通信。

1. 设置单独的存储库，其中将包含所有k8和docker任务以及构建/部署脚本。
2. 为k8s声明设置单独的存储库，并将docker文件保留在适当服务的存储库中。
3. 所有k8s声明和docker文件放置在服务代码附近（代码与仓库相同）

哪种方法更好并且提供更大的灵活性？我们有2种服务，不久之后，具有复杂内部网络配置的服务柜台将增加到8种，而第3种选择一点也不好。

第二个选项更好，但是我不确定k8s独立回购是否是一个好的选择。虽然本地docker映像也可能给本地开发带来一些困难，因为开发人员团队与其他服务交互并启动所有服务并不需要全部。

第一个选项看起来不错，因为它提供了完全的责任奉献精神，并且只能解决devops任务，但是将来当团队需要启动整个k8s集群时，可能会导致一些问题。但是，即使在这种情况下，也可能会针对minikube提取并执行此仓库。

但是，这些选择都不对我有什么好处。我想念什么吗？

Answer 1

我建议＃3。到目前为止，我与之合作的所有公司都保持这种方式。

从Kubernetes原生的角度来看

一些 Kubernetes本机devtools，例如DevSpace （https://github.com/covexo/devspace）和Draft （https://github.com/Azure/draft）建议放置Dockerfile和Kubernetes资源定义（或Helm图表）文件）到包含代码的存储库中。

从 DevOps观点

使用＃3，开发人员将能够更好地重现生产环境以修复错误，并且通常将CI / CD工具设置为与基础结构即代码一起使用，例如与该代码相同的仓库中包含的定义。

有例外，例如GitLab的Auto DevOps CI / CD工具。它非常适合与Kubernetes一起使用并与外部图表一起使用。但是，之所以这样做，是因为他们想要简化通往Kubernetes的CI / CD管道的设置，并希望从底层的Helm图表中抽象出来。但是，它们还允许您自己定义Helm图表，并暗示该图表与代码位于同一存储库中。

从版本控制角度

＃3是有利的，因为您可以确保在绑定代码和“基础结构”定义时始终可以运行可重复的构建。假设您想回到过去并使用旧版本的代码，那么您将使用哪个版本的非相关其他回购协议？将所有内容都存储在一个存储库中，将使您能够签出任何修订或分支，并始终确保可以构建和实例化代码。

示例：您更改了依赖性管理工具，并且需要运行另一个命令来安装依赖性。此更改将使您相应地更改Dockerfile。将代码+ k8s + Dockerfile结合在一起，可以确保您仍然可以实例化使用旧的依赖管理工具的旧版本。

Answer 2

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

此外，如果您具有CI集成，则还想在每次更改Dockerfile后触发管道，这在与代码位于同一位置时会容易得多。

然后，您还将所有Kubernetes / Helm文件保存在不同的（单个）存储库中，这样您就可以管理它们，并在需要时将其组合以用于不同的微服务（如果您具有更复杂的部署）。在此处的CI中，您只想整理图表/文件。

Answer 3

我认为将Dockerfile及其部署文件（k8s YAML）全部放在其服务的同一存储库中更为有意义，这使得构建和部署服务变得容易，因为CI / CD工具可能会带来全新的发展代码，构建映像，然后部署。您也可以按照Helm的方式退出服务存储库中的所有部署文件，它们可以放在一个Helm图表中。 Helm路径使您可以轻松查看整个应用程序。如果您不想在开发人员计算机上运行所有服务，则应使用Telepresence。