GitOps -在相同的回购或分离回购？

Question

首先，这是在Kubernetes内部运行的单回购应用程序的上下文中。

在GitOps中，我的理解是，所有东西都是声明性的，并且写在诸如YAML之类的配置文件中。这允许在git中进行完整的更改历史记录。分支代表环境。例如：

• 分支开发可以是已部署的QA或暂存的
• 特性/foo-bar可以是用于评估
• 标记v1.2.0的部署特性分支，它可能是在生产中运行的最新版本--这对我来说是有意义的，任何分支都可以作为应用程序的运行版本部署。

我记得我读过..。某个地方..。配置应该在主存储库之外，在另一个“配置存储库”中。从内存中可以看出，应用程序不应该知道特定的配置.只有如何使用配置？

这是真的吗？我应该有应用程序回购和应用程序配置回购吗？例如：

应用程序回购：foo-organisation/bar-application

• config

• ：foo-organisation/bar-application-config

用于不同环境的配置分支模型在存储库中的位置？为什么，有什么好处？

否则，它应该只存在于应用程序回购的目录中吗？

Answer 1

除了您的环境的所有内容都应该用git表示(例如，停止在Jenkins、env变量Steve!)中存储配置之外，没有其他真正的硬规则。配置所处的位置更多的是实现细节。

如果您的应用程序被管理为一个单回购，那么为什么不使用相同的设置部署呢？通常情况下，最好与现有的发布过程相适应，而不是创建新的版本。

一个问题是，该应用程序的单个版本通常需要支持多个部署，并且在应用程序构建和发布之后，部署配置经常会发生变化。因此，许多“配置”关系都需要一个1的“应用程序”。不管是用文件、目录、分支还是repos实现的。只要它们是版本/发布的，它们都可以工作。

另一个发布考虑是应用程序构建。对于小型部署更新，您不希望构建和发布完整的新应用程序映像。最好只是应用配置并重用现有的人工制品。这通常是单独部署/配置回购的驱动程序，所以关注点是完全分开的。

保安能起一定作用。您可能在部署配置中拥有所有开发人员都不需要访问的系统信息，或者您甚至不希望有机会将其转换为容器映像。这也驱动了单独的repos的使用。

基础设施的规模也是另一个原因。如果我管理多个应用程序，一般的部署配置将不会存储在一个应用程序回购。

Answer 2

我坚信配置应该与代码一起存在和版本化，主要是因为更改它会影响系统的行为，因此必须遵循SDLC，以确保更改不会破坏任何其他内容。

让我列举一些想法：

• Credentials或不属于应用程序配置，它们应该被安全地管理，它们必须被加密，我建议为它们使用哈希莫普库之类的东西，并在runtime.
• Platform资源上获得它们，比如数据库表或卡夫卡主题，它们应该是应用程序的一部分，它们很少改变，当它们发生变化时，我更愿意遵循SDLC，以确保它们不会像CPU那样破坏app.
• Infrastructure资源，内存应该是应用程序发布的一部分，它们可能会对系统的行为产生很大的影响，您不希望在较高的environments.
• Endpoints中对它们进行实验，以便使用DNS解决其他服务，指向不同的位置应该是一个版本化的更改，并且应该进行测试以保持环境均等

。

如果您将配置保存在与代码相同的存储库中，那么您将遵循已知的流程来处理可能造成影响的任何事情，否则会打开人为错误、错误配置、未测试的更改到达PROD的可能性，以及更多的失败场景。