Question

很明显，每个环境都使用一个策略组（如dev，staging或production，如they do here）。但是，当处理一些与环境相关的属性（如名称或种子地址）时，与旧的角色/环境布局相比，处理策略文件是非常棘手的。

目前，我正在使用一个额外的属性名称空间层，其中包含策略组的名称，例如：

Doorkeeper::TokensController

然后在食谱中，他们就像这样说：

default['foo']['development']['bar'] = 'zaz'
default['foo']['production']['bar'] = 'zaz'

default['foo'][node.policy_group]['bar']将解析为node.policy_group或development的位置，具体取决于已分配的计算机production。

我主要担心的是，我必须在每个policy group上携带大量属性，这些属性与将要部署的环境无关，例如，如果我设置了ElasticSearch集群，我应该携带Policyfile上所有环境的主节点列表。

使用Policyfile管理环境属性是否有更好的方法？我真的谴责在每个Policyfile上携带一大堆属性？

Answer 1

本周我们在Config Managament Camp举行了一次“Ask me Anything”会议。

Chef Software Inc.的员工（IIRC Thom May）表示他们确实在考虑添加指定某些特定于环境的属性的可能性，因为这似乎是一个经常被请求的功能。

在此之前，您可能希望从数据包中检索此类数据（遵循某种命名约定）。

虽然我还不是Policyfile s的用户，但我正在使用similar approach（implementation）加载数据中心特定属性并将它们与来自目前的角色食谱。根据我的理解，这应该对你有所帮助。

Answer 2

poise-hoist cookbook可能会有所帮助，但粗略地说是的，你需要有一个很大的属性博客。您可以使用https://yolover.poise.io/中显示的一些instance_eval技巧避免在每个策略中重复它们。更常见的是，对于诸如“使用哪个ES服务器”之类的内容，您可能需要考虑使用Consul或Eureka等专用服务发现工具。

Answer 3

现在，将主持人的方法直接整合到下面的厨师中已有几年了：

https://docs.chef.io/release_notes_client/#policyfile-hoisting

Answer 4

执行此操作的另一种方法，我建议我的客户使用“环境data bag”，这里概述了传统的厨师环境：https://docs.chef.io/data_bags/#environments

通过执行以下操作，您可以采用相同的逻辑并将其应用于policy_group（环境的逻辑替换）：

{
  "id": "some_data_bag_item",
  "production" : {
    # Hash with all your data here
  },
  "testing" : {
    # Hash with all your data here
  }
}

在配方中使用数据袋时，可以使用类似于以下代码的方式从配方中访问数据：

data_bag_item[node.policy_group]['some_other_key']

这是利用poise-hoist版https://docs.chef.io/release_notes_client/#policyfile-hoisting中添加到Chef Infra Client中的14.0功能。

Chef的政策小组和环境

4 个答案: