A month ago, I presented a webinar entitled “Cooking on Windows with Chef” that demonstrates the power of Opscode Chef on Windows. If you missed the webinar, you can watch that recording here.
One major way in which Windows has lagged Unix/Linux is in the desktop-based virtual machine development model using tools like VirtualBox and Vagrant. Vagrant, if you’re not already familiar with it, allows you to bring up and tear down development environments very quickly, and provision (configure) them using the same Chef cookbooks with which you’d configure your actual production environments. To that end, a bunch of folks have released an updated version of the vagrant-windows plugin, which adds WinRM and native shared folder support between Windows guests and the host operating system. Vagrant-windows has actually been around for a while, but had to be updated to deal with the API changes between Vagrant 1.1 and 1.2. This took a significant amount of work.I finally had an opportunity to test vagrant-windows 1.2.0 and it works pretty flawlessly. To install, simply type
vagrant plugin install vagrant-windows
from your workstation running Vagrant 1.2 or above.
If you plan to use a Vagrantfile to test a particular cookbook, I recommend using Berkshelf to resolve all the dependencies and feed them to your Chef run. Berkshelf also has a plugin for Vagrant called vagrant-berkshelf.
A complete working Vagrantfile for the Opscode IIS cookbook can be found here. The output from a “vagrant up” looks very similar to a run on a Unix/Linux guest.
Where do I get Windows base boxes?
You may have noticed that in the above example run, I used a base box called “windows-2012-standard”. I generated this box using the Veewee definition in Opscode’s Bento project, which feeds an Autounattend.xml to the Veewee build.
Unfortunately, because of licensing reasons, Opscode isn’t able to distribute the completed boxes to you. In any case, the product key in use is a trial key, so the boxes expire 180 days after being built.
- It’s early days for this plugin, so there are a few bugs, particularly in the generated paths on the Windows guest. This results in errors like the one seen here.
- The Chef Minitest Handler‘s assertions may or may not work yet on Windows. The last time I tried this, I was able to make some basic assertions but not ones about file ownership, etc. or anything else that needs to be asserted differently on Windows versus Unix.
- Many other plugins in the Vagrant ecosystem do not yet support Windows. This includes vagrant-vbguest and vagrant-omnibus, two of the plugins I use. vagrant-chef-zero does work, but not when using Windows as a host, since the is-chef-zero-running detection logic is written only for Unix platforms.
The latest release of the vagrant-windows plugin brings the power of desktop-based development environments for Windows to Vagrant again. If you’re willing to live with a few rough edges, this is a viable way that you can quickly test your Chef cookbook work without having to converge on real machines.
One last piece of advice: buy an SSD for your workstation if you’re going to use Windows VMs. The startup time for Windows is much longer on spinning disk platters than on flash storage!
vagrant-omnibus now supports windows https://github.com/schisamo/vagrant-omnibus/pull/60