我应该如何存储环境变量？

<playbook>.yml                   # Various playbooks for deployment
roles/windows                    # Ansible role for Ubuntu
roles/ubuntu                     # Ansible role for Ubuntu
config/hosts/<name>.yml          # Ansible inventory
config/hosts/vars/<name>.json    # Environment specific variables 

#1 楼

我已经以可扩展的方式运行了两次环境变量，但都没有完美的结果，因为正如我所发现的那样，正确处理是一件非常棘手的事情。我将在下面总结我的两种经验：

公共因素


环境变量与原始源代码存储在单独的存储库中（它们一起调制，但仍基于单独的存储库。
工件和变量是独立的“构建”过程。
环境变量没有单独的释放过程。如果要更改环境变量，则需要经过相同的更改审核委员会和通常的操作。

使用领事KV对

环境变量是从工件库中加载的（永远不要原始git repo）并加载到命名空间的KV对树中，例如

/env/dev1/my/application/v1.1.1

，其中先前的dev1是环境的名称，my / application是应用程序的名称空间，而v1.1.1是要使用的环境变量的版本。对于开发人员来说，所有这些都是不可见的。在运行时，平台会检查环境是否在当前领事群集中存在（如果没有问题且出错了），然后它会检查应用程序名称空间的子树（这样，在一个应用程序中就不会有交叉污染的情况）引用另一个应用变量），然后从连接到可部署工件的标签获取配置的版本号。更新此标签是这里的关键，因为这意味着如果我们丢失了两个生产数据中心，则可以通过简单地从可部署工件中读取元数据并将所有环境变量加载到KV存储中来再次站起来。

这种方法的问题
开发人员总是，而且我每次都想找到一种方法来将配置更改放到对应用程序的运行方式有重大影响的环境中。因为最终使批准配置更改比更改代码更容易获得批准。

存储带有嵌入变量的“部署”工件

这紧密地结合了工件的确切版本到配置的版本。如果更改了配置，则必须重建此部署工件。

部署工件本身实质上是一个yaml文件，其中包含可发布二进制文件的URL以及附加到该文件的所有配置。

该平台包含用于读取变量的组件，然后在启动时将其放入应用程序的进程树中。

到目前为止，由于存在人工制品，我们已经取得了很多成功可以追溯历史，并且我们可以举起任何审查委员会，并说：“这是我们唯一关心的工件，我们不需要查看任何其他更改，只需更改此东西”（即部署应用程序，包括环境变量等。

这使得开发人员尝试在其应用程序中构建逻辑以使其能够基于变量更改其行为，从而使他们可以轻松地进行更改而又不会滑动而变得有点困难经过适当的测试周期。

奖励积分

考虑应用程序的秘密。到目前为止，我们对此的解决方案是提供一个公共RSA密钥，开发团队可以使用它来加密扩展的Java密钥存储库（几乎每种语言在某个地方都有可以读取Java密钥存储库的库），然后将其视为第三种工件并被拉到服务器上，用我们的平台私钥解密，并在运行时提供给应用程序。

秘密管理本身就是蠕虫病毒。但这可能值得考虑。

#2 楼

如果您的环境是针对每个客户的，那么我建议您在特定情况下为每个客户建立一个存储库。 （通常是每个环境的存储库。）此存储库将具有标准目录结构，用于环境变量，ansable变量和清单，高度加密的机密（帐户访问令牌，私钥等）。您可以将代码git子模块到那些存储库中。我可能会在多个存储库中执行此操作。一个用于烦人的角色和模块，一个用于维护和部署脚本，一个用于环境中运行的每个主要应用程序。

现在，您可以选择实际地分叉代码或将子模块固定在特定的标签上以进行发布，确保除非经过测试和发布，否则管理客户环境的代码不会更改。

如果您使用工件存储库，请确保对工件进行了正确的版本控制，并在环境变量中指定了这些版本

自动化非常重要，因为环境变量不应由人在可能的情况下更新，而应由脚本生成。确保每个客户库存中几乎没有手动更新，并且开发人员仅更新代码存储库。如果他们想更改配置，则应对生成脚本之一进行更改，然后运行生成脚本来生成变量，并将差异提交到客户存储库中。为此过程需要设置持续集成。在某些情况下，没有此存储库将无法维护。