小编Mik*_*aro的帖子

在第一次启动 EC2 实例时cloud-init 运行用户数据脚本后，可能会写入一个状态文件，以便 cloud-init 在后续重新启动时不会再次运行该脚本。在某些情况下，我想删除此状态文件，以便再次运行用户数据脚本。它在哪里？

在运行了大约 18 个小时后，这个系统使用了大约 10GB 的内存，导致我们在运行我们的日常任务时触发了 OOM-killer：

# free -h
             total       used       free     shared    buffers     cached
Mem:           14G       9.4G       5.3G       400K        27M        59M
-/+ buffers/cache:       9.3G       5.4G
Swap:           0B         0B         0B

# cat /proc/meminfo
MemTotal:       15400928 kB
MemFree:         5567028 kB
Buffers:           28464 kB
Cached:            60816 kB
SwapCached:            0 kB
Active:           321464 kB
Inactive:          59156 kB
Active(anon):     291464 kB
Inactive(anon):      316 kB
Active(file):      30000 kB
Inactive(file):    58840 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                40 …

Chef-solo 缺乏环境支持似乎很有争议。一方面，环境的特征之一是能够将食谱固定到特定环境，而这对于 Chef-solo 来说完全没有意义。另一方面，我们很多人都希望在使用 Vagrant 进行测试时能够合并环境级别的属性并使用特定于环境的运行列表。我想我可能已经找到了一个简单的方法来解决这个问题。假设我在所有环境和角色中使用 JSON 语法，并且我坚持以下约定来设置属性（从最低到最高优先级）：

1. 食谱属性文件中的默认值
2. 角色文件中的默认值
3. 在环境文件中覆盖

看起来我可以自己解析这些文件并使用 -j 选项将属性注入到chef-solo中。例如，我可以在我的 Vagrantfile 中做这样的事情：

chef_env_conf = parse_json("./environments/#{ENV['CHEF_ENVIRONMENT']}.json")
chef.json = chef_env_conf["override_attributes"]

由于通过 -j 选项设置的属性在正常优先级级别应用，因此这可以是覆盖角色默认值的另一种方法，并且这可能是您在未自动拉入环境的上下文中所需的全部内容。

您可以执行类似的操作来获取每个环境的运行列表（通过解析角色文件）：

chef_role_conf = parse_json("./roles/#{role}.json")
chef.run_list = chef_role_conf["env_run_lists"][ENV['CHEF_ENVIRONMENT']]

我意识到这不是最优雅的 hack，但对于某些人来说，这似乎是一个可行的解决方案。有没有人认为这是一个非常糟糕的主意？