Search code examples
vagrantchef-infravagrantfiletest-kitchen

Set up a test kitchen cookbook recipe to generate chef server inside vagrant


I'm experimenting with chef and test kitchen.

The problem I'm facing is as follows. I'm using arch linux and I couldn't get chef installed on my machine, so I decided to use a centos7 box for a working vm to do so.

My goal is to have enterprise chef server created using a cookbook by test kitchen and have both machines (server and the working vm) accessible on the same network one depending on the other. So yeah, it's a nested setup. If anyone has a better idea, I'm open to different suggestions.

For the working vm, I used this box:

https://github.com/holms/vagrant-centos7-box/releases/download/7.1.1503.001/CentOS-7.1.1503-x86_64-netboot.box

Here's the contents of my Vagrant file:

Vagrant.configure(2) do |config|
    config.vm.box = "chef-repo"
    
    config.vm.network "public_network"
end

So really basic stuff ...

I successfully installed chef and test kitchen on that machine and life was good.

The problem now is using test kitchen to install chef server from here:

https://downloads.chef.io/chef-server/

I created a really simple config with test kitchen that resembles the following:

recipes/default.rb

package_url = node['enterprise-chef']['url']
package_name = ::File.basename(package_url)
package_local_path = "#{Chef::Config[:file_cache_path]}/#{package_name}"

# omnibus_package is remote (i.e., a URL) let's download it
remote_file package_local_path do
  source package_url
end

package package_local_path

# reconfigure the installation
execute 'private-chef-ctl reconfigure'

...and attributes/default.rb

default['enterprise-chef']['url'] = 'https://web-dl.packagecloud.io/chef/stable/packages/el/7/chef-server-core-12.1.0-1.el7.x86_64.rpm'

After which I run $ kitchen converge and it fails miserably with this:

[vagrant@localhost enterprise-chef]$ kitchen converge
-----> Starting Kitchen (v1.4.0)
-----> Creating <default-centos-65>...
       Bringing machine 'default' up with 'virtualbox' provider...
       ==> default: Importing base box 'opscode-centos-6.5'...
==> default: Matching MAC address for NAT networking...
       ==> default: Setting the name of the VM: kitchen-enterprise-chef-default-centos-65_default_1436040993946_29931
       ==> default: Clearing any previously set network interfaces...
       ==> default: Available bridged network interfaces:
       1) eth0
       2) eth1
       ==> default: When choosing an interface, it is usually the one that is
       ==> default: being used to connect to the internet.
       Vagrant is attempting to interface with the UI in a way that requires
       a TTY. Most actions in Vagrant that require a TTY have configuration
       switches to disable this requirement. Please do that or run Vagrant
       with TTY.
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #create action: [Expected process to exit with [0], but received '1'
---- Begin output of vagrant up --no-provision --provider virtualbox ----
STDOUT: Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'opscode-centos-6.5'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: kitchen-enterprise-chef-default-centos-65_default_1436040993946_29931
==> default: Clearing any previously set network interfaces...
==> default: Available bridged network interfaces:
1) eth0
2) eth1
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
STDERR: Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.
---- End output of vagrant up --no-provision --provider virtualbox ----
Ran vagrant up --no-provision --provider virtualbox returned 1]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

[vagrant@localhost enterprise-chef]$ 

I'm currently trying to figure out the problem by manually changing the Vagrantfile located in .kitchen/kitchen-vagrant/kitchen-enterprise-chef-default-centos-65:

Vagrant.configure("2") do |c|
  c.berkshelf.enabled = false if Vagrant.has_plugin?("vagrant-berkshelf")
  c.vm.box = "opscode-centos-6.5"
  c.vm.box_url = "https://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box"

  c.vm.network :public_network

  c.vm.synced_folder ".", "/vagrant", disabled: true
  c.vm.provider :virtualbox do |p|
  end
end

so far, I'm getting this error:

[vagrant@localhost kitchen-enterprise-chef-default-centos-65]$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Available bridged network interfaces:
1) eth0
2) eth1
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
    default: Which interface should the network bridge to? 1
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: bridged
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
^C==> default: Waiting for cleanup before exiting...
Vagrant exited after cleanup due to external interrupt.
$

The default: Warning: Connection timeout. Retrying... goes indefinitely and I'm forced to stop it. But the machine seems to be running, only inaccessible to the first vagrant instance.

[vagrant@localhost kitchen-enterprise-chef-default-centos-65]$ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.
[vagrant@localhost kitchen-enterprise-chef-default-centos-65]$ 

My guess is that something is terrible wrong with the network configuration.

Any ideas or some feedback around my setup are very much welcome.

Thank you.


Solution

  • I'd suggest you just use chef-zero provisioner for foodcritic.

    provisioner:
      name: chef_zero
      data_bags_path: /some/path
      ...
    

    That will spin up a temporary chef-zero server on the host box, and make it available to the foodcritic run. This also saves you the major overhead of a second server running. The only setback I know of here is if you happen to need multiple nodes under test at the same time. I'm not entirely sure how the plugin would handle that. Either it would share one Chef-zero (which could be good or bad), create one per test suite (again, good or bad, depending on what you actually want), or it may just crash.