管理本地和kubernetes环境中的应用配置这个想法源于GitOps范式。我将向你展示一个应用程序和一个工程师如何与应

这个想法源于GitOps范式。我将向你展示一个应用程序和一个工程师如何与应用程序配置进行互动。我已经看到这种方法在一些地方被使用，它是有意义的，因为有以下的好处。

我们现在都知道，应用程序的配置通常存在于应用程序资源库中。它往往是一个.env 文件或其他形式。每个环境也可以有多个副本，所以你最终会有很多文件散落在各地。现在让我们缩短一下时间，看看为什么我认为摆脱这种做法是有益的。在这个例子中，我将使用一个Golang应用程序。

将应用程序的配置保存在一个集中的资源库中，有助于简化管理和维护。在多个环境中，经常有许多重复的配置键值对。如果资源库不是集中式的，那将是非常耗时和错误的修剪操作。
遵循基础设施层面上的关注点分离原则。
应用程序成为无状态的，没有配置文件的。
不再有散落在应用仓库中的配置文件。
这是一个对GitOps友好的方法，由于明显的原因，应用程序的配置是用Git管理的。
CI/CD管道不需要管理应用程序的配置，因为当一个应用程序启动时，它将自己处理一切。
Docker镜像中不再有硬编码的配置值作为环境文件或值。
如果你需要引入更多的环境或新的键值对，可以轻松扩展。
每个环境的所有应用配置的结构/模式完全相同。

有两个存储库。

它在 "本地 "和 "其他 "环境中的工作方式不同。本地 "是工程师在他们的PC上运行应用程序的地方，而 "其他 "是Kubernetes运行你的应用程序的地方（qa、staging、沙盒、prod...）。两者都有 "绿色 "和 "红色 "部分，如下所述。

绿色--工程师使用本地配置库克隆，以JSON格式添加/更新/删除应用程序配置，并将更改推送到GitHub。如果他们想获取最新的变化，他们只需拉动它。你可以想象，我们不会经常使用这个，因为我们并不总是摆弄配置。
红色--当工程师运行一个应用程序时，它会从本地配置库中读取JSON配置文件，以映射到一个结构。

结合绿色和红色，这只有一种工作方式，非常简单。当应用程序首次运行时，它会使用GitHub客户端与远程配置库对话，提取配置映射到结构中。

你可以使用这个仓库来遵循GitOps范式，将所有服务和基础设施配置保存在其中，如下所示。

├── argocd

这是一个完全解耦的例子。然而，如果你想在你的服务中保持最小的类型初始化，你可以将你的代码耦合起来，但我建议不要这样做。

├── config

package main

如果你真的耦合了你的代码，你的main.go 文件会是这样的。

package main

package config

注意GitHub API的速率限制。

package github

你将需要这些环境变量或使用你喜欢的名称和值。

SERVICE_ENV: A single environment. local/test/sbox/prod/....

$ env | grep GITHUB