如何在组织范围内处理特定于环境的应用程序配置?

Stu*_*nge 12 deployment configuration

问题

您的组织有许多单独的应用程序,其中一些应用程序相互交互(形成"系统").您需要将这些应用程序部署到单独的环境中,以便于分阶段测试(例如,DEV,QA,UAT,PROD).在每个环境中,给定的应用程序需要稍微不同地配置(例如,每个环境都有一个单独的数据库).您希望通过某种自动化机制来处理此重新配置,以便您的发布管理器不必在每次部署到不同环境时手动配置每个应用程序.

期望的功能

我想设计一个具有以下属性的组织范围的配置解决方案(理想情况下):

  • 支持"一键"部署(仅需要指定环境,并且在部署期间/之后不需要手动重新配置).
  • 应该有一个"记录系统",其中指定了共享的依赖于环境的属性(例如,许多应用程序共享的数据库连接字符串).
  • 支持重新配置已部署的应用程序(在特定于环境的属性需要更改的情况下),理想情况下无需重新部署应用程序.
  • 允许应用程序在同一台机器上运行,但在不同的环境中运行(同时运行PROD实例和DEV实例).

可能的解决方案

我看到了解决方案可以采用的两个基本方向:

  1. 使所有应用程序"环境感知".您可以将命令行中的环境名称(DEV,QA等)传递给应用程序,然后该应用程序"足够智能",足以在运行时计算出特定于环境的配置值.该应用程序可以从应用程序部署的平面文件或中央配置服务中获取值.
  2. 应用程序不是"智能",因为它们位于#1中,只是通过应用程序部署的配置文件中的属性名称获取配置.安装程序/脚本在部署时将这些属性的值注入配置文件中.该安装脚本采用环境名称并从中央配置服务获取所有相关配置值.

您如何实现解决这些问题并支持这些所需功能的配置解决方案?我是否有两种可能的解决方案?您对这些解决方案有偏好吗?另外,请随时告诉我,我正在考虑这个问题.任何反馈将不胜感激.

eru*_*orm 2

我们都遇到过这类事情,尤其是在大型组织中。我认为最重要的是首先管理自己的期望,并询问是否真的有必要告诉给定机器上的每个系统和子系统“更改为 DEV 模式”或“更改为 PROD 模式”。我个人的建议如下:

  1. 让各个盒子负责不同的阶段 - 即“这是一个 DEV 盒子”和“这是一个 PROD 盒子”。

  2. 在一个位置收集尽可能多的不同盒子的配置,即使它需要软链接或脚本来收集信息然后打印出来。

    答:这样,您可以轻松地在两个地方“转储此设备的配置”并查看有何不同,例如在新部署之后。

    B. 您还可以将配置更改与软件更改分开,至少在某种程度上,这是根除发布时发生的错误的好方法。

  3. 然后让所有内容的配置都基于未内置或硬编码的某物/某处 - 只需确保在该位置收集并记录它即可。机制是什么几乎并不重要,这是一件好事,因为有些系统只是不想被迫使用某些机制或其他机制。

抱歉,如果这个答案太笼统 - 这个问题非常笼统。我之前曾在几个大型基于软件的组织工作过,这似乎是最好的方法。使用独立服务器作为“一个部署单元”是最现实的场景(尽管有时价格昂贵),因为应用程序会相互影响,而且无论您多么小心,当您移动任何给定的齿轮或齿轮时,都会破坏整个系统的稳定性。

替代方案很快就会变得非常复杂。您需要开始重写您可以控制的应用程序,以便让它们接受“DEV”开关,而您最终会为您无法控制的应用程序添加层层组装。通常,您无法控制的那些至少将其属性基于系统范围级别上定义的某些内容,除非它们“呼叫母舰以获取指示”。

将人们重定向到远程位置并让他们“使用 DEV”与“使用 PROD”比“使这台机器像 DEV 一样运行”与“使这台机器像 PROD 一样运行”更容易。如果你把事情搞混了,比如让 DEV 任务与 PROD 任务在同一个机器上一起运行,那么这无论如何都不是一个现实的场景:我保证最终你将向 ​​PROD 上的某人授予非法的仅限 DEV 的访问权限,并且您将有一个 DEV 任务清除 PROD 数据库。

希望这可以帮助。如果您想讨论更多涉及的具体细节,请告诉我。