如何在Git中管理带有依赖的Chef Cookbook？

我之前也碰到过一模一样的问题——把Cookbook拆成单独Git仓库后，依赖的第三方Cookbook总是拖后腿。其实核心就是要解决Cookbook依赖的版本化和同步问题，下面是几个业内常用的靠谱方案：

1. 用Berkshelf做依赖管理（最经典的方案） #

Berkshelf是Chef生态里专门用来管理Cookbook依赖的工具，完美适配单Cookbook仓库的场景：

• 在你的chef_docker_test仓库根目录创建Berksfile，明确声明依赖来源和版本：

  source 'https://supermarket.chef.io' # 指向Chef Marketplace
  cookbook 'docker', '~> 2.0' # 替换成你实际需要的版本号
  

• 开发时，运行berks install就能自动把依赖的docker Cookbook拉取到本地缓存；如果需要把依赖打包到项目目录（比如离线开发），可以用berks vendor vendor/cookbooks，然后把vendor/目录加入.gitignore（避免提交第三方代码）
• 部署阶段，berks upload可以把你的Cookbook和依赖一起上传到Chef Server，或者用berks package打成tar包，方便分发到离线环境

2. 用Policyfiles做现代化的环境与依赖管理 #

如果你想更精细化地控制整个Chef环境的依赖版本，Policyfiles是更好的选择：

• 在chef_docker_test仓库里创建Policyfile.rb，示例内容：

  name 'chef_docker_test_policy'
  default_source :supermarket # 默认从Marketplace拉取依赖
  cookbook 'chef_docker_test', path: '.' # 指定当前仓库的Cookbook
  cookbook 'docker', '~> 2.0' # 声明docker Cookbook的版本
  

• 运行chef install生成Policyfile.lock.json（这个文件要提交到Git，保证所有环境依赖版本一致），然后用chef push <policy_group>把整个策略推送到Chef Server，部署时节点会自动拉取正确的Cookbook版本

3. 手动管理（不推荐，仅临时场景用） #

如果实在不想用工具，你可以手动把docker Cookbook克隆到本地的cookbooks目录，但这种方式问题很多：版本更新要手动同步、不同开发环境容易出现版本不一致、仓库体积变大，只适合临时测试用，长期维护千万别这么干。

额外的最佳实践 #

• 每个Cookbook单独Git仓库是完全正确的选择，模块化开发能让每个Cookbook独立迭代、复用，还能单独发布版本
• 一定要在Cookbook的metadata.rb里也声明依赖，比如：

  depends 'docker', '~> 2.0'
  

  这样Chef Server和其他工具都能识别依赖关系，避免部署时出错
• 把Berksfile/Policyfile.rb和锁文件（如果用Policyfiles）都提交到Git，其他开发者克隆仓库后，只需运行对应的安装命令就能一键搞定依赖

内容的提问来源于stack exchange，提问作者DenCowboy