Kitchen supports a driver plugin architecture which allows a user to run code on a variety of public cloud providers and local virtualization technologies.
Some of these are included in
chef-dk and some are not.
There are drivers not included in this list, and it is not intended to be exhaustive. However, as a sample of some of the supported platforms:
Some notes about specific drivers below.
Vagrant is often considered the "minimum-viable" driver. Many projects include
.kitchen.yml which can run under Vagrant, in addition to any specific
drivers which they may use internally or on continuous integration servers.
Vagrant runs using Virtualbox VMs, so it requires a platform which supports virtualization. For example, it cannot run on top of Xen HVM.
kitchen-vagrant requires that you additionally have Vagrant installed.
Amazon Web Services' EC2 service can be used to spin up new EC2 instances for testing.
kitchen-ec2 does not have any external requirements on your system, but you
need to configure AWS credentials which are used to manage the EC2 instances.
This is a common property of many of the cloud-based drivers: rather than
locally installed software, they require credentials into the service which
they use to launch and destroy VMs.
Using Docker containers for testing often offers faster runtimes than its alternatives. Because containers are lighter weight than full virtualization, the numerous creation and deletion operations performed by Kitchen over a large test matrix can make this an attractive option.
kitchen-docker requires that you have Docker installed locally. Additionally,
it is useful to configure your user to have sudo-less access to Docker.
A popular alternative to
kitchen-dokken is a driver which
only works with the Chef provisioner.
kitchen-dokken differs significantly from
kitchen-docker by using bind
mounts to share data without the need to copy it into the container.
This can result in significant speed improvements with no additional