管理多个环境的配置通常是许多软件交付系统的祸根。 大多数组织通过针对不同环境使用静态属性文件（例如，local.properties，dev.properties，test.properties，stage.properties和prod.properties）来管理属性。 我已经设计了许多软件交付系统，这些方法可以使我自己适应并在“ 以人为本的自动化 ：通过自动化加快部署 ”中倡导这种方法。 这是我所见过的最简单的方法之一，但是，如果您需要管理一个具有数百个甚至数千个针对多个应用程序和数百个实例的单个属性的软件交付系统，它将无法扩展并最终变得难以管理。 大多数故障是由于某个人在单个软件系统的数百个不同属性文件中输入了错误的值而导致的。
但是，情况并非没有希望。 通过有效地使用自动化，动态配置和云基础架构，您的软件交付系统可以大大减少在环境之间移动软件时对静态属性的需求。 您将在本文中学习如何做。
开发人员可以从操作中学到很多，操作可以从开发人员中学到很多。 本系列文章致力于探索将操作思维方式应用于开发（反之亦然）的实际用途，以及将软件产品视为可以以比以往任何时候都更高的敏捷性和频率交付的整体实体。
表1列出了组织内团队管理的一些典型属性：
这不是一个详尽的列表，但是它代表了典型软件系统中更常用的类型。
在由开发和运营团队组成的大多数软件组织中，开发团队（开发人员，测试人员，分析师等）通常会：
创建一个文件（例如local.properties）来管理与工作站相关的属性。 在dev.properties文件中修改“开发”环境的属性，并将其提交到版本控制存储库。 由于动态属性（例如IP地址）可以更改，因此开发人员必须在发生此类更改时不断修改此文件。 用相同的属性属性修改test.properties文件，但为测试人员使用不同的值 ，因为它们可能使用不同的IP地址，文件和目录。开发团队的配置通常不会在这里结束，因为组织的开发方通常会管理“开发”和“测试”之外的其他环境。
在传统的组织，开发团队将手离开软件包运营团队（数据库管理员，系统/ OPS，发布工程中，等等）来部署软件到下游环境的软件交付周期的一部分。 该团队：
修改stage.properties文件中“登台”环境的属性，并将其提交到版本控制存储库。 在prod.properties文件中为“生产”环境修改类似的属性，并将其提交到版本控制存储库。 因为动态属性（例如IP地址）可以更改，所以当发生此类更改时，操作必须不断更新这些属性文件。我见过具有属性层次结构的团队：本地，环境（通常至少具有四个环境属性文件，但通常还有更多），应用程序，子系统和实例。 当它们具有数百个实例时，它们具有数百个不同的属性文件，从而几乎不可能管理IP地址，目录和其他属性的不断变化。 这导致了频繁的环境和部署失败，通常很难解决，因为变更管理面临着挑战-谁在何时何地更改了？ —使得很难确定错误的根本原因。
在使用传统方法精心设计的软件系统中，所有可能因环境而异的属性都被外部化为属性文件。 换句话说，不会将可能是可变的设置硬编码到应用程序代码中。 但是，属性越多，就越容易引入部署错误。 这些错误代价高昂且难以排除，并且经常导致在“构建升级”过程中延迟将软件交付给用户。
清单1是属性文件的简单示例：
在非平凡的系统中，诸如此类的属性文件通常具有数百个属性。 这些属性通常在开发，测试，登台和生产环境中重复出现，从而导致将数百个或数千个属性交付给生产环境时进行管理。
清单2显示了一个Java™代码段，该代码段从属性文件中检索值：
这是团队在管理属性时最常用的方法。 但是，当今的软件交付系统能够以前所未有的规模运行。 多亏了硬件商品化，虚拟化和云计算，您才能在交付和管理软件系统时启动（终止）数百个环境。 您的配置管理方法必须能够相应地扩展。 而且（还得益于硬件商品化，虚拟化和云计算），它可以。
我在本文中主张的方法是动态设置和检索属性。 当您使用的基础设施自动化工具定义环境（见“ 敏捷DevOps的：基础设施自动化 ”），您可以设置配置项-如数据库名称，以及文件和目录名-在配置数据库中 。 您可以在脚本中执行此操作，因为整个基础架构是完全在提交到版本控制存储库的脚本中构建的。 此外，在云或虚拟基础架构中，您可以动态设置和检索配置项，例如IP地址和域名，这些配置项通常在传统基础架构中静态定义。
清单3中的代码是一个Ruby脚本，它将配置项加载到SimpleDB（NoSQL）数据库中：
Capistrano是用于定义脚本化部署的基于Ruby的域特定语言（DSL）。 清单4中的代码来自Capistrano脚本，该脚本根据用户一次定义的参数定义数据库用户名和密码：
Amazon Web Services（AWS）的CloudFormation是一种模板语言，用于描述AWS资源的供应。 这是一种使用JSON的DSL和类似于基础架构自动化工具（例如Chef或Puppet）的声明性方法。 CloudFormation最适合用于定义AWS资源的配置，而将其他基础结构资源的配置留给Chef或Puppet脚本。 尽管其他主要的云提供商当前未提供用于定义资源的类似DSL，但您通常可以通过其API与这些云提供商的资源进行接口。
因为您可以通过脚本完全控制基础结构，所以可以自动生成数据库用户名和密码并将其存储在安全的配置数据库中。
在整个软件交付系统的其余部分都使用此配置。 推送到该数据库的数据在上游环境中动态检索，并在下游环境中使用。
清单5中的代码是AWS CloudFormation JSON脚本的一部分，该脚本动态设置和关联外部IP地址：
您需要将这样的脚本与相应的自动化测试一起提交给版本控制存储库。
清单6中的CloudFormation JSON代码使用AWS Route 53服务动态设置应用程序的A域记录：
该脚本使您无需使用域名服务（DNS）提供程序手动配置此项目，这是传统方法。
清单7中的代码来自CloudFormation脚本，该脚本定义了一个名为DatabaseName的参数：
当脚本为应用程序创建新数据库时，会将DatabaseName参数传递给基础结构脚本（例如Puppet清单）。 整个脚本将提交到版本控制存储库，然后编写自动测试以验证数据库是否可访问。
清单8中的代码为环境（和应用程序）设置了外部端口：
developerWorks 敏捷转换提供新闻，讨论和培训，以帮助您和您的组织在敏捷开发原则上建立基础。
在此示例中，唯一具有外部访问权限的端口是端口22（用于SSH访问），端口8080（用于Apache Tomcat）和端口80（用于Apache HTTP Server）。 可以通过无类域间路由（CIDR）表示法进一步限制对网络甚至单个节点的访问（请参阅参考资料 ）。
在本文中，您了解了在大多数软件交付系统中通常静态定义的配置可以并且应该动态定义，因此您无需为每个目标环境都进行更改。 您看到了可以大大减少创建环境所需的可配置属性的数量。
下一部分将介绍一个开放源代码平台，用于在云中连续交付软件。 您将学习运行平台的基本步骤，如何使用交付管道以及如何运行作业以供应环境和运行部署。
翻译自: https://www.ibm.com/developerworks/opensource/library/a-devops7/index.html
相关资源：log4j 动态配置