【问题标题】:berks doesn't resolve dependency from cookbooksberks 无法解决来自食谱的依赖
【发布时间】:2016-06-11 03:35:33
【问题描述】:

我正在尝试拥有一个管理我的环境的 git 存储库。我已经为特定任务编写了一组 lwrp。这些 lwrps 内部依赖于许多社区食谱。

我的每本食谱都有一个 Berksfile,我在其中指定依赖关系解析。在我的存储库的根文件夹中,我有一个主 Berksfile,其中列出了我想要从我的存储库中获得的所有食谱。

我现在想要的是,当我从根位置进行 berks 安装时,它应该获取我的说明书,然后解析它们以从每个说明书中找到单独的 berks 文件并解决所有依赖项。但是它的行为并非如此。

有人对此有任何想法吗?这是 Berks 如何工作的常见场景吗?还是我遗漏了一些东西以致无法解决依赖关系?

提供更多信息:我的食谱有这个berksfile

source 'https://supermarket.chef.io'
cookbook 'apache_spark', '~> 1.2.12'

而且apache spark内部有依赖

cookbook 'monit', github: 'phlipper/chef-monit', tag: '1.5.2'

【问题讨论】:

标签: chef-infra cookbook berkshelf berksfile


【解决方案1】:

这是上述问题的重复,但由于没有超详细的答案,我将在此处添加更多内容。

如其他答案所述,Berksfile 指令是“不可传递的”。食谱的metadata.rb 中的依赖项是符号依赖项,只是一个名称和一个版本约束,没有关于从何处获取它的信息。每个与说明书一起使用的工具对如何处理这些符号依赖项都有不同的理解,例如,当您运行 berks install 时,您可能会从超市或 GitHub 中提取依赖项,但当厨师客户端处理它们时,它会从厨师服务器获取所有内容.在符号依赖项与从何处获取它们之间保持这种分离允许许多工具共存。 Berksfile 提供了有关从何处下载特定说明书的附加数据,可以增加或替换符号依赖项中的信息,但由于这些额外的指令不是说明书元数据的一部分,因此无法递归完成。

最大的问题是 Supermarket 是一个平面命名空间,因此只能有一本名为 monit 的食谱。这导致许多人不在 Supermarket 上发布东西,而是通过 git 源指令依赖它们。这意味着depends "monit" 不再像应有的那样清晰。这确实应该被视为未发布食谱的错误,但我理解人们不愿意重命名他们的食谱以正确发布它们。

通常的解决方法是将一些东西从上游复制粘贴到新的 Berksfile 中,或者在私有超市实例(或等效的 Chef Server 组织)中创建一个隔离的食谱宇宙,您可以在其中上传您自己的东西想要,这样做depends "monit" 再次变得明确。

【讨论】:

  • 是的,现在我正在处理一个上游 berksfile,它列出了我需要的所有食谱并将它们指向具有指定分支或标签的 git 位置。
  • 我建议不要这样做。要么使用你的厨师服务器的 berkshelf/universe 端点(自 12.6 左右可用),要么建立自己的超市。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-06-18
  • 1970-01-01
  • 1970-01-01
  • 2015-07-01
  • 1970-01-01
  • 2016-04-13
  • 1970-01-01
相关资源
最近更新 更多