4

首先，这是在 Kubernetes 内部运行的单一存储库应用程序的上下文中。

在 GitOps 中，我的理解是一切都是声明性的，并且写在 YAML 等配置文件中。这允许在 git 中完整的更改历史。分支代表环境。例如：

  • BRANCH develop 可以是已部署的 QA 或登台环境
  • BRANCH 功能/foo-bar 可能是用于评估的已部署功能分支
  • TAG v1.2.0 可能是在生产中运行的最新版本这对我来说很有意义，任何和所有分支都可以部署为应用程序的运行版本。

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

这是真的？我应该有一个应用程序仓库和一个应用程序配置仓库吗？例如

  • 应用程序回购：foo-organisation/bar-application
  • 配置回购：foo-organisation/bar-application-config

不同环境的 config 分支模型位于该存储库中的哪个位置？为什么以及有什么优势？

否则它应该只存在于应用程序存储库的目录中吗？

4

1 回答 1

8

除了关于你的环境的所有内容都应该在 git repo 中表示之外，没有真正的硬性规则（例如，停止将配置存储在 Jenkins 环境变量 Steve 中！）。配置所在的位置更多的是实现细节。

如果您的应用程序作为单一存储库进行管理，那么为什么不使用相同的设置进行部署呢？通常最好适应您现有的发布流程，而不是创建新的东西。

一个问题是应用程序的单个版本通常需要支持多个部署，并且部署配置通常会在应用程序构建和发布后发生变化。所以需要有 1 个“应用程序”到多个“配置”关系。无论是通过文件、目录、分支还是 repos 来实现。只要它们被版本化/发布，它们都可以工作。

另一个发布注意事项是应用程序构建。对于小型部署更新，您不想构建和发布完整的新应用程序映像。最好只应用配置并重用现有的工件。这通常是单独部署/配置存储库的驱动程序，因此关注点是完全分离的。

安全可以发挥作用。您可能在部署配置中拥有所有开发人员都不需要访问的系统信息，或者您甚至不希望有机会将其制成容器映像。这也推动了单独回购的使用。

基础设施的规模是另一个问题。如果我管理多个应用程序，通用部署配置将不会存储在单个应用程序存储库中。

于 2020-07-31T03:38:51.670 回答