berks不解决烹饪书的依赖性

时间:2016-06-10 12:02:36

标签: chef cookbook berkshelf berksfile

我正在尝试使用git存储库来管理我的环境。我为特定任务编写了lwrp集。这些lwrps内部依赖于许多社区烹饪书。

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

我现在想要的是,当我从根位置安装berks时,它应该获取我的cookbook然后解析它们以从每个cookbook中找到单独的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'

1 个答案:

答案 0 :(得分:1)

这是上述问题的副本,但因为没有超详细的答案,我会在这里加上更多。

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

最大的问题是超市是一个扁平的名称空间,因此只能有一个名为monit的食谱。这导致许多人不在超市发布内容并通过git source指令依赖它们。这意味着depends "monit"不再像它应该的那样清晰。这应该被认为是未发表的食谱的一个错误,但我理解人们不愿意重新命名他们的食谱以便正确地释放它们。

通常的解决方法是从上游向您的新Berksfile复制一些东西,或者在私人超市实例(或等效的Chef Server组织)中创建一个孤立的食谱世界,您只需上传你想要的东西,并且这样做depends "monit"再次变得明确无误。

相关问题