☰

Chef 节点和角色的版本控制

tag-icon • tag-icon chef version-control
Chef 节点和角色的版本控制

使用 chef 时对节点和角色进行版本控制是一种好的做法吗？如果是这样，有什么好的方法吗？

看起来应该能够获取使用创建的 JSON 文件树chef_server_backup.rb并将其简单地签入 VC。还有更好的替代方案吗？

更新

事实证明，检查生成的 JSONchef_server_backup.rb是不是一个很好的解决方案。问题是脚本生成的 JSON 不稳定。每次哈希值都以不同的顺序出现，生成的文件与以前的版本完全不同……即使它们在解析为 JSON 时意味着相同的事情。我最好只保存压缩 tarball。

（但如果我可以通过排序属性来规范化 JSON 文件……）

答案1

我尝试将尽可能多的配置保存为 JSON 文件，并使用 更新 chef-server knife [noun] from file name.json。我从以下存储库开始：https://github.com/opscode/chef-repo我将所有 JSON 文件保存在相应的目录中。您也可以对 YAML 或 Ruby 文件执行相同操作。使用命令show，例如knife role show apache2 -Fj > roles/apache2.json从 chef-server 上已有的数据创建文件。

基于“来自文件”的方法的一些好处包括：

  • 在托管厨师和私人厨师之间转换相对容易
  • 您可以使用现有的角色文件、data_bag 项目等通过 chef-solo 进行测试
  • 通过跟踪更改之间的差异git diff，并查看不仅仅是食谱版本的历史记录
  • 数据冗余：如果您的 Private Chef 服务器或 Hosted Chef 不可用，您仍然拥有所有基础设施配置

唯一没有的是opscode/chef-repo是节点文件。您也可以从文件中导出/导入节点，但通常不建议这样做，因为节点应该是一次性的。我喜欢纳森·哈维曾经说过：“把节点看作牛，而不是宠物。”

相关内容