Need help with vagrant-serverspec?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

vvchik
194 Stars 29 Forks MIT License 67 Commits 3 Opened issues

Description

Vagrant plugin that integrates serverspec

Services available

!
?

Need anything else?

Contributors list

# 142,326
Ruby
Shell
HTML
Vagrant
20 commits
# 365,541
C
Shell
automat...
golang
5 commits
# 207,265
mopidy
Terrafo...
Amazon ...
ruby-ge...
3 commits
# 353,266
CSS
Kuberne...
PHP
etcd
2 commits
# 138,414
Go
Terrafo...
golang
volume
2 commits
# 94,993
seleniu...
cli-uti...
Groovy
phantom...
1 commit
# 623,873
Python
Ruby
1 commit
# 61,171
Ruby
tcl
circlec...
travis-...
1 commit
# 358,563
Shell
HTML
Groovy
azure-s...
1 commit

Vagrant-Serverspec


Gem Version

vagrant-serverspec is a vagrant plugin that implements serverspec as a provisioner.

Installing

Standard way

First, install the plugin.

$ vagrant plugin install vagrant-serverspec

In case of fork usage

in case of fork usage you need to build it first

shell
gem build vagrant-serverspec.gemspec
(on windows you may use embedded vagrant ruby for that)
shell
C:\HashiCorp\Vagrant\embedded\bin\gem.bat build vagrant-serverspec.gemspec
after that install plugin from filesystem
shell
vagrant plugin install ./vagrant-serverspec-0.5.0.gem

Example Usage

Next, configure the provisioner in your

Vagrantfile
.
Vagrant.configure('2') do |config|
  config.vm.box = 'precise64'
  config.vm.box_url = 'http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-vagrant-amd64-disk1.box'

config.vm.provision :shell, inline: < specfiles can be saved into ansible role repository for example ). Default: true spec.error_no_spec_files = false # save result into html an report, saved into a 'rspec_html_reports' directory. Default: false spec.html_output = true # save result into junit xml report, default file name is 'rspec.xml' spec.junit_output = true # set custom junit xml report file name spec.junit_output_file = 'junit.xml' end end

You may want to override standard settings; a file named

spec_helper.rb
is usually used for that. Here are some examples of possible overrides.
# Disable sudo
# set :disable_sudo, true

Set environment variables

set :env, :LANG => 'C', :LC_MESSAGES => 'C'

Set PATH

set :path, '/sbin:/usr/local/sbin:$PATH'

Then you're ready to write your specs.

require_relative 'spec_helper'

describe package('ufw') do it { should be_installed } end

describe service('ufw') do it { should be_enabled } it { should be_running } end

describe port(22) do it { should be_listening } end

Testing Docker Containers on OSX

On OSX the Vagrant docker provider runs a Boot2Docker VM, then launches your docker container on that VM. Vagrant does SSH Proxying to send the commands through that VM and have them reach the Docker Container. Vagrant serverspec handles this the same way by getting the container host VM infromation and proxying the commands to the machine through an SSH Proxy. This functionality was introduced in this PR

Additional informations

SSH connections

SSH connection is closed before each provision run. This is mandatory if the provision is applied to multiple vms in the same run, else all runs will be applied to the first vm (See #22) due to an SSH connection which already exists. This functionality was introduced in this PR

Server spec examples

RSpec examples are clear before each provision run. This is mandatory if the provision is applied to multiple vms in the same run, else each run replay examples of previous calls also. This functionality was introduced in this PR

In case of shared examples

If you use shared examples into your test suite, you need to use 'load' instead of 'require', else errors can occurs (See #23 comments).

Versioning

vagrant-serverspec aims to adhere to Semantic Versioning 2.0.0.

Development

Pull requests are very welcome! Make sure your patches are well tested. Ideally create a topic branch for every separate change you make. For example:

  1. Fork the repo
  2. Create your feature branch (
    git checkout -b my-new-feature
    )
  3. Commit your changes (
    git commit -am 'Added some feature'
    )
  4. Push to the branch (
    git push origin my-new-feature
    )
  5. Create new Pull Request

Authors

Original Idea Jeremy Voorhis ([email protected]).
Current version author and maintainer Vladimir Babchynskyy ([email protected])
and a growing community of contributors.

License

MIT license (see LICENSE)

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.