A Test Kitchen Driver for Vagrant.
This driver works by generating a single Vagrantfile for each instance in a sandboxed directory. Since the Vagrantfile is written out on disk, Vagrant needs absolutely no knowledge of Test Kitchen. So no Vagrant plugins are required.
A Vagrant version of 1.1.0 or higher is required for this driver which means that a native package must be installed on the system running Test Kitchen.
Note: If you have previously installed Vagrant as a gem (a version prior
to 1.1.0), this version may be resolved first in your PATH
. If you receive an
error message that Vagrant is too old despite having installed Vagrant as a
package, you may be required to uninstall the gem version or modify your PATH
environment. If you require the vagrant gem for older projects you should
consider the vagrant-wrapper gem which helps manage both
styles of Vagrant installations
(background details).
Currently this driver supports VirtualBox and VMware Fusion/Workstation. Virtualbox is free and is the default provider for Vagrant.
If you would like to use VMware Fusion/Workstation you must purchase the software from VMware and then must also purchase the Vagrant VMware plugin.
Please read the Driver usage page for more details.
This driver can predict the Vagrant box name and download URL for a select number of platforms (VirtualBox provider only) that have been published by Opscode, such as:
---
platforms:
- name: ubuntu-10.04
- name: ubuntu-12.04
- name: ubuntu-12.10
- name: ubuntu-13.04
- name: centos-5.9
- name: centos-6.4
- name: debian-7.1.0
This will effectively generate a configuration similar to:
---
platforms:
- name: ubuntu-10.04
driver:
box: opscode-ubuntu-10.04
box_url: https://opscode-vm-bento.s3.amazonaws.com/vagrant/opscode_ubuntu-10.04_provisionerless.box
- name: ubuntu-12.04
driver:
box: opscode-ubuntu-12.04
box_url: https://opscode-vm-bento.s3.amazonaws.com/vagrant/opscode_ubuntu-12.04_provisionerless.box
- name: windows2012r2_cloud
driver:
box: windows2012r2_cloud
box_url: https://s3.amazonaws.com/box-cutter-us-east-1-cloudtrail/windows/virtualbox4.3.12/win2012r2-datacenter-chef11.12.8.box
guest: :windows
- name: ubuntu-12.10
driver:
box: opscode-ubuntu-12.10
box_url: ...
# ...
Many host wide defaults for Vagrant can be set using $HOME/.vagrant.d/Vagrantfile
. See the Vagrantfile documentation for more information.
Required This determines which Vagrant box will be used. For more details, please read the Vagrant machine settings page.
The default will be computed from the platform name of the instance. For
example, a platform called "fuzzypants-9.000" will produce a default box
value of "opscode-fuzzypants-9.000"
.
The URL that the configured box can be found at. If the box is not installed on the system, it will be retrieved from this URL when the virtual machine is started.
The default will be computed from the platform name of the instance.
This determines which Vagrant provider to use. The value should match
the provider name in Vagrant. For example, to use VMware Fusion the provider
should be vmware_fusion
. Please see the docs on providers
for further details.
By default the value is unset, or nil
. In this case the driver will use the
Vagrant default provider which at this current time
is virtualbox
unless set by VAGRANT_DEFAULT_PROVIDER
environment variable.
A Hash of customizations to a Vagrant virtual machine. Each key/value
pair will be passed to your providers customization block. For example, with
the default virtualbox
provider:
driver:
customize:
memory: 1024
cpuexecutioncap: 50
will generate a Vagrantfile configuration similar to:
Vagrant.configure("2") do |config|
# ...
config.vm.provider :virtualbox do |virtualbox|
virtualbox.customize ["modifyvm", :id, "--memory", "1024"]
virtualbox.customize ["modifyvm", :id, "--cpuexecutioncap", "50"]
end
end
Please read the "Customizations" sections for VirtualBox and VMware for more details.
Useful when debugging Vagrant CLI commands. If set to true
, all Vagrant CLI
commands will be displayed rather than executed.
The default is unset, or nil
.
If you are using a Windows box you MUST set this to:
driver:
guest: :windows
This will let test-kitchen know that it need to use WinRM comunication protocol
instead of SSH. It also set the config.vm.guest
setting in the default Vagrantfile. For more details
please read the
config.vm.guest
section of the Vagrant documentation.
The default is unset, or nil
.
An Array of network customizations for the virtual machine. Each Array
element is itself an Array of arguments to be passed to the config.vm.network
method. For example:
driver:
network:
- ["forwarded_port", {guest: 80, host: 8080}]
- ["private_network", {ip: "192.168.33.33"}]
will generate a Vagrantfile configuration similar to:
Vagrant.configure("2") do |config|
# ...
config.vm.network :forwarded_port, guest: 80, host: 8080
config.vm.network :private_network, ip: "192.168.33.33"
end
Please read the Vagrant networking basic usage page for more details.
The default is an empty Array, []
.
An optional hook to run a command immediately prior to the
vagrant up --no-provisioner
command being executed.
There is an optional token, {{vagrant_root}}
that can be used in the
pre_create_command
string which will be expanded by the driver to be the full
path to the sandboxed Vagrant root directory containing the Vagrantfile. This
command will be executed from the directory containing the .kitchen.yml file,
or the kitchen_root
.
For example, if your project requires Bindler, this command could be:
pre_create_command: cp .vagrant_plugins.json {{vagrant_root}}/ && vagrant plugin bundle
The default is unset, or nil
.
Allow the user to specify a collection of synced folders on each Vagrant instance. Source paths can be relative to the kitchen root.
The default is an empty Array, or []
. The example:
driver:
synced_folders:
- ["data/%{instance_name}", "/opt/instance_data"]
- ["/host_path", "/vm_path", "create: true, type: :nfs"]
will generate a Vagrantfile configuration similar to:
Vagrant.configure("2") do |config|
# ...
c.vm.synced_folder "/Users/mray/cookbooks/pxe_dust/data/default-ubuntu-1204", "/opt/instance_data"
c.vm.synced_folder "/host_path", "/vm_path", create: true, type: :nfs
end
This is the username used for SSH authentication if you would like to connect with a different account than Vagrant default user.
If this value is nil, then Vagrant parameter config.ssh.default.username
will be used (which is usually set to 'vagrant').
An alternate Vagrantfile ERB template that will be rendered for use by this
driver. The binding context for the ERB processing is that of the Driver
object, which means that methods like config[:kitchen_root]
, instance.name
,
and instance.provisioner[:run_list]
can be used to compose a custom
Vagrantfile if necessary.
Warning: Be cautious when going down this road as your setup may cease to be portable or applicable to other Test Kitchen Drivers such as Ec2 or Docker. Using the alternative Vagrantfile template strategy may be a dangerous road--be aware.
The default is to use a template which ships with this gem.
Sets the internal hostname for the instance. This is not used when connecting to the Vagrant virtual machine.
For more details on this setting please read the config.vm.hostname section of the Vagrant documentation.
To prevent this value from being rendered in the default Vagrantfile, you can
set this value to false
.
The default will be computed from the name of the instance. For
example, the instance was called "default-fuzz-9" will produce a default
vm_hostname
value of "default-fuzz-9.vagrantup.com"
.
This is the path to the private key file used for SSH authentication if you would like to use your own private ssh key instead of the default vagrant insecure private key.
If this value is a relative path, then it will be expanded relative to the location of the main Vagrantfile. If this value is nil, then the default insecure private key that ships with Vagrant will be used.
The default value is unset, or nil
.
- Source hosted at GitHub
- Report issues/questions/feature requests on GitHub Issues
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:
- Fork the repo
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Added some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create new Pull Request
Created and maintained by Fletcher Nichol (fnichol@nichol.ca)
Apache 2.0 (see LICENSE)