GitOps - 在同一个仓库或单独的仓库中配置？

Question

首先，这是在 Kubernetes 内部运行的单一存储库应用程序的上下文中。
在 GitOps 中，我的理解是一切都是声明性的，并且写在 YAML 等配置文件中。这允许在 git 中完整的更改历史。分支代表环境。例如:

BRANCH develop 可以是已部署的 QA 或暂存环境

BRANCH 功能/foo-bar 可能是用于评估的已部署功能分支

TAG v1.2.0 可能是生产中运行的最新版本
这对我来说很有意义，任何和所有分支都可以部署为应用程序的运行版本。

问题
我记得读过……某处……配置应该位于主存储库之外，在另一个“配置存储库”中。从内存的想法是一个应用程序不应该知道一个特定的配置......只知道如何使用一个配置？
这是真的？我应该有一个应用程序仓库和一个应用程序配置仓库吗？例如

应用程序仓库:foo-organisation/bar-application

配置仓库:foo-organisation/bar-application-config

不同环境的 config 分支模型位于该存储库中的哪个位置？为什么以及有什么优势？
否则它应该只存在于应用程序存储库的目录中吗？

Answer 1

除了关于你的环境的所有内容都应该在 git repo 中表示之外，没有真正的硬性规则(例如，停止在 Jenkins env 变量 Steve 中存储配置!)。配置所在的位置更多的是实现细节。
如果您的应用程序作为单一存储库进行管理，那么为什么不使用相同的设置进行部署呢？通常最好适应您现有的发布流程，而不是创建新的东西。
一个问题是应用程序的单个版本通常需要支持多个部署，并且部署配置通常会在应用程序构建和发布后发生变化。所以需要有 1 个“应用程序”到多个“配置”关系。无论是通过文件、目录、分支还是 repos 来实现。只要它们被版本化/发布，它们都可以工作。
另一个发布注意事项是应用程序构建。对于小型部署更新，您不想构建和发布完整的新应用程序镜像。最好只应用配置并重用现有的工件。这通常是单独部署/配置存储库的驱动程序，因此关注点是完全分离的。
安全可以发挥作用。您可能在部署配置中拥有所有开发人员都不需要访问的系统信息，或者您甚至不希望有机会将其制成容器镜像。这也 push 了单独 repo 的使用。
基础设施的规模是另一个问题。如果我管理多个应用程序，通用部署配置将不会存储在单个应用程序存储库中。