在厨师环境菜单中管理应用程序配置 [英] Managing application configuration in a chef environment cookbook

问题描述

我是厨师的新人，一直在努力寻找如何在环境食谱中配置应用程序配置的最佳做法[来源1]。

环境食谱我应该做以下工作：

• 通过创建目录，用户等来准备自定义应用程序部署的节点，


• 添加特定于应用程序部署的初始化和监控脚本。


• 定义应用程序配置设置。

这最后一个责任是一个非常难以破解的问题。

一个示例配置文件应用程序部署可能如下所示：

  {
server：{
port： 9090 
}，
session：{
proxy：false，
expires：100 
}，
redis：[ {
port：9031，
host：rds01.prd.example.com
}，{
port：9031，
 host：rds02.prd.example.com
}]，
ldapConfig：{
url：ldap：//example.inc：389，
adminDn：CN = Admin，CN = Users，DC = example，DC = inc，
adminUsername：user，
adminPassword：secret，
searchBase：OU = BigCustomer，OU = customers，DC = example，DC = inc，
searchFilter：（example = *）
}，
 log4js：{
appenders：[
 {
category：[all]，
type：file，
filename ：./logs/myapp.log
} 
]，
levels：{
[all]：ERROR
} b $ b}，
otherService：{
basePath：http://api.prd.example.com:1234/otherService，
smokeTestVariable：testVar 
} 
} 
  

此部署配置文件的某些部分更稳定比其他。虽然这可能因应用程序和设置而异，例如端口号和用户名，为了简单起见，我喜欢在环境中保持一致。

让我分类配置设置

• li>
  
• 服务器


• log4js.appenders


• ldapConfig.adminUsername


• ldapConfig .searchFilter


• otherService.basePath


• redis.port

环境特定属性

• log4js.levels


• .smokeTestVariable

部分环境特定属性

• redis.host： rds01。[environment] .example.com


• otherService.basePath： http：// api。[environment] .example.com：1234 / otherService

加密的环境特定属性

• ldapConfig.adminPassword

问题

1. 如何创建配置文件？一些选项：1）使用应用程序部署本身中发布的文件，2）使用cookbook文件模板，3）使用JSON blob作为属性[source＃2]，4）... other？


2. 配置文件中有很大的变异性;如何最好地管理这些使用厨师？角色，环境，每节点配置，数据包，加密的数据包...？

方法中的一些关键问题：

• 我希望只有一种方法来设置配置设置。


• 更改开发人员的配置文件应该相当简单


• 厨师食谱是在同一个git仓库中管理的。
作为源代码。

• 一些配置设置需要很大的灵活性;例如我的示例配置中的 log4js 设置可能包含许多更多的 appender 和几十个相当非结构化的变量。 li>
  

任何体验都将非常感激！

>

1. http://blog.vialstudios.com/the-environment-cookbook-pattern/


2. http://lists.opscode.com/sympa/arc/chef/2013-01/msg00392.html li>
   
3. http ：//jtimberman.housepub.org/blog/2013/01/28/local-templates-for-application-configuration/


4. http://realityforge.org/code/2012/11/12/reusable-cookbooks-revisited.html

解决方案

Jamie Winsor在chefconf发表演讲， 环境食谱模式的基本原理和用法：

• Chefcon：谈论自包含版本，使用厨师


• 幻灯片

在我看来，这个模式介绍的一个关键概念是使用厨师环境，以控制每个应用程序的设置实例。使用 berkshelf 更新环境，其中包含应用程序使用的运行时版本的烹饪书。

不太明显的是，如果您决定为使用单个应用程序实例预留Chef环境，那么使用该环境可以安全地配置应用程序的全局运行时设置。

如果在berkshelf-api 安装中提供的示例说明。在那里你将看到用各种运行时设置编辑的生产环境（对于应用程序）：

 刀具环境编辑berkshelf-api生产
  

总之，厨师给了我们很多选择。我将提出以下一般建议：

1. 捕获应用程序cookbook中的默认值


2. 创建环境


3. 在环境中设置运行时属性过载

注意：

• 另请参阅 berksflow 工具。旨在使环境食谱模式更易于实施。


• 我没有提到使用角色。这些也可以用于在运行时覆盖属性，但可能更容易捕获在专门的厨师环境中的一切。角色似乎更适合捕获应用程序组件特有的信息。

I am new to chef and have been struggling to find best practices on how to configure application configuration in an environment cookbook [source #1].

The environment cookbook I'm working on should do the following:

• Prepare the node for a custom application deployment by creating directories, users, etc. that are specific for this deployment only.
• Add initialization and monitoring scripts specific for the application deployment.
• Define the application configuration settings.

This last responsibility has been a particularly tough nut to crack.

An example configuration file of an application deployment might look as follows:

{
    "server": {
        "port": 9090
    },
    "session": {
        "proxy": false,
        "expires": 100
    },
    "redis": [{
        "port": 9031,
        "host": "rds01.prd.example.com"
    }, {
        "port": 9031,
        "host": "rds02.prd.example.com"
    }],
    "ldapConfig": {
        "url": "ldap://example.inc:389",
        "adminDn": "CN=Admin,CN=Users,DC=example,DC=inc",
        "adminUsername": "user",
        "adminPassword": "secret",
        "searchBase": "OU=BigCustomer,OU=customers,DC=example,DC=inc",
        "searchFilter": "(example=*)"
    },
    "log4js": {
        "appenders": [
            {
                "category": "[all]",
                "type": "file",
                "filename": "./logs/myapp.log"
            }
        ],
        "levels": {
            "[all]": "ERROR"
        }
    },
    "otherService": {
        "basePath" : "http://api.prd.example.com:1234/otherService",
        "smokeTestVariable" : "testVar"
    }
}

Some parts of this deployment configuration file are more stable than others. While this may vary depending on the application and setup, things like port numbers and usernames I prefer to keep the same across environments for simplicity's sake.

Let me classify the configuration settings:

Stable properties

• session
• server
• log4js.appenders
• ldapConfig.adminUsername
• ldapConfig.searchFilter
• otherService.basePath
• redis.port

Environment specific properties

• log4js.levels
• otherService.smokeTestVariable

Partial-environment specific properties

• redis.host: rds01.[environment].example.com
• otherService.basePath: http://api.[environment].example.com:1234/otherService

Encrypted environment specific properties

• ldapConfig.adminPassword

Questions

1. How should I create the configuration file? Some options: 1) use a file shipped within the application deployment itself, 2) use a cookbook file template, 3) use a JSON blob as one of the attributes [source #2], 4)... other?
2. There is a great diversity of variability in the configuration file; how best to manage these using Chef? Roles, environments, per-node configuration, data-bags, encrypted data-bags...? Or should I opt for environment variables instead?

Some key concerns in the approach:

• I would prefer there is only 1 way to set the configuration settings.
• Changing the configuration file for a developer should be fairly straightforward (they are using Vagrant on their local machines before pushing to test).
• The passwords must be secure.
• The chef cookbook is managed within the same git repository as the sourcecode.
• Some configuration settings require a great deal of flexibility; for example the log4js setting in my example config might contain many more appenders with dozens of fairly unstructured variables.

Any experiences would be much appreciated!

Sources

1. http://blog.vialstudios.com/the-environment-cookbook-pattern/
2. http://lists.opscode.com/sympa/arc/chef/2013-01/msg00392.html
3. http://jtimberman.housepub.org/blog/2013/01/28/local-templates-for-application-configuration/
4. http://realityforge.org/code/2012/11/12/reusable-cookbooks-revisited.html

解决方案

Jamie Winsor gave a talk at chefconf that goes further in explaining the environment cookbook pattern's rationale and usage:

• Chefcon: talking about self-contained releases, using chef
• Slides

In my opinion one of the key concepts this pattern introduces is the idea of using chef environments to control the settings of each application instance. The environment is updated, using berkshelf, with the run-time version of the cookbooks being used by the application.

What is less obvious is that if you decide to reserve a chef environment for the use of a single application instance, it then it becomes safe to use that environment to configure the application's global run-time settings.

An example if given in the berkshelf-api installation instructions. There you will see production environment (for the application) being edited with various run-time settings:

knife environment edit berkshelf-api-production

In conclusion, chef gives us lots of options. I would make the following generic recommendations:

1. Capture defaults in the application cookbook
2. Create an environment for each application instance (as recommended by pattern)
3. Set run-time attribute over-rides in the environment

Notes:

• See also the berksflow tool. Designed to make the environment cookbook pattern easier to implement.
• I have made no mention of using roles. These can also be used to override attributes at run-time, but might be simpler to capture everything in a dedicated chef environment. Roles seem better suited to capturing information peculiar to a component of an application.

这篇关于在厨师环境菜单中管理应用程序配置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！