Matt Wrock has a new article in the Skills Library, “Create a Windows Server 2016 Vagrant box with Chef and Packer.” In it, Matt talks about how to use Chef and Packer together to create a Windows Server 2016 on a Vagrant box.
Matt takes you through the process step by step and explains how to deal with a few “gotchas” he encountered along the way. All of the Chef recipes, PowerShell scripts and Packer templates can be cloned from his packer-templates github repo.
Here are some excerpts of what you’ll find in the full article:
Dealing with cookbook dependencies
I’ve broken down most of the scripts that I use in a Packer run into various Chef recipes that are encapsulated in a single cookbook called packer-templates, which I include in my Packer template repository. Either of Packer’s Chef provisioners will copy this cookbook to the image being built but what about other cookbooks that my packer-templates cookbook depends on? My cookbook uses the windows cookbook, the wsus-client cookbook, the dependencies that they have, and so on, but Packer does not expose any mechanism for discovering those cookbooks and downloading them. Read more…
Configuring WinRM
As we will find as we make our way to a completed Vagrant .box file, there are a few key places where we need to change some machine state outside of Chef. The first of these is configuring WinRM. Before you can use any provisioner, WinRM must be configured correctly. The Go WinRM library cannot authenticate via NTLM so we must enable Basic Authentication and allow unencrypted traffic. Note that my template removes these settings prior to shutting down the VM, before the image is exported, since my testing scenarios have NTLM authentication available. Read more…
Choosing a Chef provisioner
There are two Chef-flavored provisioners that come with Packer: chef-solo and chef-client. The chef-client provisioner is ideal if you store your cookbooks on a Chef server. However, since I am storing the cookbook along with the Packer templates that will be copied to the image, I am using the chef-solo provisioner. Read more…
Windows updates and other WinRM unfriendly tasks
The Chef provisioner invokes the Chef client via WinRM and all of the restrictions of WinRM apply here. That means no Windows updates, no installing .Net, no installing SQL Server and a few other edge case restrictions. Read more…
Multiple Chef provisioning blocks
A couple important things to include when you run the Chef provisioner more than once is to tell it not to install Chef and to reuse the cookbook directories it used on the first run. Read more…
Cleaning up
Once the image configuration is what you want, you might (or might not) want to remove the Chef client. I try to optimize my Packer setup for minimal size and the Chef client is rather large (a few hundred MB). Now, you can’t remove Chef with Chef. Read more…
Testing provisioning recipes with Test-Kitchen
One thing I’ve found very important is to be able to test Packer provisioning scripts outside of an actual Packer run. Remember that, even if you pare down your provisioning scripts to almost nothing, a Packer run will always have to run through the initial Windows install. Read more…
Using kitchen-hyperv to test scripts on Hyper-V
If I’m using a hyperv builder to first create a minimal image, Packer puts the build .vhdx file in output-hyperv-iso/virtual hard disks. I can use kitchen-hyperv and point it at that image and it will create a new VM using that vhdx file as the parent of a new differencing disk where I can test my recipes. I can then have test-kitchen run these recipes in just a few minutes or less, which is a much tighter feedback loop than Packer provides. Read more…
Using kitchen-vagrant to test on Virtualbox
If you create a .box file with a minimal Packer template, it will output that .box file in the root of the packer-template repo. Read more…