nodespec

RSpec style tests for multiple nodes/server instances with support for provisioning with puppet, chef, ansible.

• Read the documentation

Nodespec vs Serverspec

Serverspec is a popular gem that allows you to write rspec tests to validate your servers/hosts configuration.

Nodespec is not an alternative to Serverspec, rather it's build on top of it, so you can still leverage all of its features while enjoying some extra goodies.

What's different

Nodespec overcomes some of the limitations of Serverspec, such as mixed OS'/backends support (Windows/WinRM and UN*X/SSH) and easy configurability and connectivity to your target hosts.

Nodespec enables a declarative way of configuring your remote connections, be it simple Ssh, a Vagrant box, or an Amazon EC2 instance.

Nodespec adds support for issuing provisioning commands (through Puppet, Chef or Ansible) to your target hosts, that could be incorporated as part of your test setup.

Below is a quick summary of the main features of nodespec. Refer to the wiki for more details and examples.

Nodespec features

Hostname declared or inferred in specs

In serverspec you would typically have to create folders named after your target servers, whereas in nodespec you can simply declare your target server names as your spec example group:

describe "test.example1.com" do
  ...
end

describe "test.example2.com" do
  ...
end

Easy connection configuration

No more ruby code and create programmatically SSH objects, just a quick and easy inline (or file/yaml based) configuration:

describe "test.example.com", nodespec: {
    'adapter' => 'ssh',
    'user'    => 'testuser',
    'keys'    => 'path/to/key'
  } do
...
end

Support connections to Windows & Un*x servers

One of the major limitations of serverspec is that you have to make a hard decision beforehand on which OS/backend you are targeting with your tests. In particular you have to include specific specinfra modules in your spec_helper depending on whether you're connecting to Un*x or Windows machines, using ssh or winrm. Practically it is not possible to test different OSs/backends as part of the same spec run, unless you start hacking some conditional logic in your spec_helper, that is.

With Nodespec that problem is resolved and you can easily connect and test multiple OS and multiple backends in the same rspec run by simply specifying the desired adapter and connection properties for your target host. For instance, to connect to a Windows/WinRM box:

describe "test.windows-example.com", nodespec: {
    'adapter'         => 'winrm',
    'user'            => 'testuser',
    'pass'            => 'somepass',
    'transport'       => 'ssl'
  	'basic_auth_only' => true
  } do
...
end

Provisioning (aka TDD your infrastructure)

Nodespec provides support for running Chef, Puppet, Ansible or shellscript commands as part of your tests, e.g.:

Chef

describe "server1", nodespec: {'adapter' => 'vagrant'} do
  before :all do
    provision_node_with_chef do
      set_cookbook_paths '/vshared/src/cookbooks'
	  set_attributes demo: {crontab: {user: 'peter'}}
      chef_client_runlist 'demo::folders', 'demo::crontab'
    end
  end
...
end

Puppet

describe "test.server", nodespec: {'adapter' => 'ssh'} do
  before :all do
    provision_node_with_puppet do
      set_modulepaths '/vshared/src/modules'
      set_hieradata('users' => {'roger' => {'uid' => 5801}, 'peter' => {'uid' => 5802}})
      puppet_apply_execute "include demo::wheel_users"
    end
  end
...
end

Ansible

describe "i-8f5e74r9", nodespec: {'adapter' => 'aws_ec2'} do
  before :all do
    provision_node_with_ansible do
      enable_host_auto_discovery
      set_host_key_checking false
      ansible_playbook 'src/ansible/demo.yml', ['--sudo']
    end
  end
...
end