除了Git，甚至可以替代Git，为什么您应该考虑将配置文件存储在容器注册表中？
译自 Advantages of storing configuration in container registries rather than git，作者 Brian Grant。
将配置文件和包存储在 Git 中非常常见。有时它们与源代码一起提交，有时与其他配置包一起存储，有时则位于它们自己的存储库中。
将部署配置与源代码一起存储最初看起来很方便，但在部署时会导致许多挑战，例如源代码和配置的权限耦合和 Git 触发器、跨环境的冲突分支和推广策略、多组件部署的协调等等。当将配置单独存储时，在 Git 中执行配置编辑的繁琐工作变得更加明显：克隆、分支、编辑、添加、提交、推送、创建变更请求、审查、合并、标记。
无论哪种方式，为了部署一组配置文件（例如使用 Helm），有时会将其复制到对象存储、工件注册表或容器注册表，通常来自 CI 过程，但在某些情况下也可能自动构建或镜像。此类存储库满足生产部署系统的可扩展性、性能、可靠性、网络访问、安全性和数据驻留要求，并且对于某些场景（例如边缘部署）特别有用。图像也可以缓存、复制和对等分布。
通过容器注册表部署配置
如果我们要将配置推送到此类存储库，为什么不一开始就将其存储在那里呢？镜像可以模拟草稿（更改）和修订，并且可以像 Git 提交一样进行版本控制和引用，既有不可变的内容摘要，也有用户定义的标签。
使用容器注册表进行通用工件存储存在一种更广泛的趋势。毕竟，容器镜像本质上是一组文件的捆绑包。（能够将镜像作为卷挂载到 Kubernetes 中运行的容器中本来是很好的，但这又是另一个问题。）许多工具都已支持OCI注册表，包括Helm、Config Sync、Flux、timoni、Crossplane和Tekton。
原因之一是它们的普遍性。部署到容器运行时的团队已经需要访问存储库。此外，注册表 API 和身份验证方法比对象存储或 Git 提供商更标准化。这使得它们更容易集成。因为镜像比包含配置包的典型 Git 存储库更细粒度、更集中的文件捆绑包，并且它们可以使用有关其内容的信息进行注释，所以容器注册表中的配置包比位于 Git 存储库子目录中的配置包更容易发现、列出和过滤。
容器注册表还支持许多管理和治理功能，这些功能对可部署资产（如配置包）非常有益。例如：
此外，将来，一旦我们自动化了大多数配置生成和更改，配置就会成为生成的工件。在这种情况下，Git 会失去大部分价值，因为用户不会直接与它交互。这也适用于渲染清单模式。
鉴于容器镜像有很多优势，希望将来会有更多用户将其作为配置文件和软件包的权威来源，并有更多工具支持它。
也就是说，一旦我们自动化了大部分配置更改，我们就应该从根本上重新思考配置工具链，以及我们是否真的想把自己逼到这个角落里。例如，将配置推送到更高可用性的存储系统根本不会改进变更控制流程。
您是否将配置模块、模板或软件包视为其他可部署构建工件，还是直接从其真实来源应用它们？您在GitOps 控制器中是否遇到直接从您的 git 提供商拉取配置的挑战？您是否发现难以跟踪所有包含可部署配置的 git 仓库？您是否发现难以保持这些仓库的最新状态？您尝试过将配置存储在容器镜像中吗？它比其他方法更好吗？这看起来仍然显得不必要地麻烦吗？
欢迎在此回复，或通过LinkedIn或X/Twitter给我发消息，我计划将此内容交叉发布。
如果您觉得这篇文章有趣，您可能还会对我的基础设施即代码和声明式配置系列中的其他文章感兴趣。