编辑 – 我开始研究Perl的Template-Toolkit。 对于下面描述的问题，似乎很适合这个法案。 有没有人玩过？ 任何（详细的）build议？
我问了一个关于configurationpipe理的问题，并没有看到答复。 我的问题可能太模糊了，所以让我们回过头来看看。 下面是我们在将新客户实例join托pipe应用程序时遵循的过程：您将如何pipe理这个过程？ 我倾向于一个Perl脚本来填充模板来生成shell脚本，configuration文件，XMLconfiguration文件等。简单看CFengine和厨师，似乎他们不会减less工作量，因为我' d仍然必须手动指定工具内的所有更改/编辑。 通过直接触摸configuration文件似乎没有太大的收获。
- 我们为核心（第三方）应用程序的主configuration文件添加一节。 这节有价值的
- 定义实例（客户）名称
- 这个实例的TCP侦听器端口（目前没有使用）
- DB2数据库名称（序列数字标识符，已经存在，它们由DBA预先给我们）
- 三个子configuration文件，按名称 – 它们需要从3个模板创build，并按实例命名
- 子configuration文件定义：
- DB2卷的文件path
- 用于存储对象的文件path
- 只有一个DB2卷的文件path（是的，对第一个项目是冗余的。
- 我们运行一些应用程序命令，启动实例
- 我们做一些LDAP的事情（为实例做一个OU等）
- 我们为安全监听器的configuration文件添加一段，作为LDAP的传递
- 实例名称
- LDAP OU
- 例如TCP端口
- DB2数据库名称
- 我们重新启动安全监听器（下class时间），从项目1更改主configuration文件，停止并重新启动实例。 它现在通过LDAP进行身份validation。
- 我们将此实例的停止和启动命令添加到HA故障转移脚本。
- 我们将一个XMLconfiguration文件导入到为客户的实际应用程序（用户名，组，权限和业务规则）定义事物的实例中。 XML由实施团队提供。
现在，我们configuration数据导入应用程序
- 我们添加一个节到现有的顶层configuration文件，指向一个新的客户级configuration文件。 新的客户级configuration文件包括：
- 实例（客户）名称
- DB2数据库名称
- 任意数量的子configuration文件，按名称
- 每个子configuration文件定义：
- 文件path到摄取，反馈，备份和失败的目录
- 这些文件path具有到客户特定文件夹的公共path，然后每个子configuration文件都有一个文件夹
- 每个文件path都需要被创build
- 我们需要将这个客户实例添加到我们的监控脚本中，以确认正确的进程正在运行并且可以login。 当然，那些监视configuration文件包括实例名称，TCP端口，DB2数据库名称等。
- 还有一个需要为新实例configuration的报告应用程序。 你明白了。
- 中间件团队还将XML加载到WAS中。 我们给他们插入XML的价值 – 他们可以很容易地把模板交给我们，我们可以给他们返回完整的XML。
我想你可以非常成功地使用Bcfg2 。 这是一个令人难以置信的灵活和可扩展的configurationpipe理系统。 它带有Genshi的基本模板逻辑，但是允许任意的内联Python代码来做更复杂的事情。
您可以拥有一个包含有关每个实例的所有信息的单个数据库，然后设置Bcfg2以基于此生成每一位configuration。 作为一个额外的好处，如果你不得不在大量实例（或所有实例）上改变一些东西，那将是完全无痛的。
这看起来非常自定义，所以我会考虑使用Fabric来为后端运行所有这些和Django作为Web前端。
面料作为后端，你也可以在没有Django的ssh中使用它。