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:
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…
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…
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…
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…
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…
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…
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…
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…
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…