Question

最近我遇到了一些问题vagrant-berkshelf无法可靠地同步现有机器上的Chef cookbook。而且，基本上，在研究变通方法时，我会看到类似的东西：

不推荐使用

vagrant-berkshelf，而是使用Test Kitchen 。

我的用例是我有Vagrantfile s，用于构建VM和DigitalOcean飞沫，它们是手写的，只使用Chef来配置VM。我绝对是以用户身份接近Chef，而不是烹饪书的作者或测试者。

所以，我的情况是Vagrant -> Chef，而不是Chef -> Vagrant。

在查看Kitche-Vagrant时，我看到了：

Kitchen的kitchen-vagrant驱动程序为沙盒目录中的每个Kitchen实例生成一个Vagrantfile。。

我的问题是：如果我的工作流依赖于手写的，复杂的Vagrantfiles，我是否可以继续使用Chef作为供应者而不必依赖vagrant-berkshelf？

我看到的一些可能的替代方案是：

mangle测试Kitchen配置以使用我现有的Vagrantfile。我担心这不是这个工具的意图，也不会很好地结束。
在vagrant中使用chef.cookbooks_path属性，让它取代vagrant-berkshelf。
切换出供应商并使用说Vagrant-＆gt; Ansible。

下面的Vagrantfile有点简化，但要点是 Vagrantfile负责而Chef只用于提供。

# -*- mode: ruby -*-
# vi: set ft=ruby :

#...grab some variables from my host environment...
DJANGO_SECRET_KEY = ENV['BUILD_DJANGO_SECRET_KEY']

Vagrant.configure('2') do |config|

  config.vm.define "myserver" do |config|
      config.vm.provider :digital_ocean do |provider, override|
        override.ssh.private_key_path = digoconf.private_key_path
        override.vm.box_url = "https://github.com/devopsgroup-io/vagrant-digitalocean/raw/master/box/digital_ocean.box"
        provider.token = digoconf.TOKEN
        ...
      end

      #had chef_client before, that worked too.
      config.vm.provision "chef_zero" do |chef|

        chef.log_level = "info"

        #I haven't tested these out
        #chef.cookbooks_path = ["../community/cookbooks","../.berkshelf/cookbooks"]

        env_for_chef = " DJANGO_SECRET_KEY='#{DJANGO_SECRET_KEY}'"
        chef.binary_env = env_for_chef

        chef.environment = "digitalocean"
        chef.add_recipe "base::install"
      end
  end
end

Answer 1

它本身并没有被弃用，但它不再具有维护者，并强烈建议不要使用它。您描述的工作流程没有替代品。抱歉。如果您有兴趣接管维护人员，我可以让您与团队联系。

随着vagrant-berkshelf被弃用，是否有可能从Vagrant驱动构建，而Chef只作为供应者？

1 个答案: