Use Packer for Windows to enhance machine image automation
Packer can curtail time sinks for administrators, especially those dealing with rapid OS releases. But the DevOps tool can require additional effort to work for Windows.
IT professionals constantly look to automate tasks, and one process worthy of falling into their sights is machine image creation and updating.
IT operations teams deploy machine images to servers and endpoints throughout an enterprise, using the same configuration and software each time. Packer, an open source HashiCorp tool, can put the template information for a machine image into code, which enables automatic image provisioning, as well as easier updates. It's useful for administrators who must deploy one configuration on multiple platforms, such as Microsoft Azure, AWS and VMware.
Administrators can use Packer for Windows to minimize a particularly troublesome time sink: the rapid cadence of updates in Microsoft's Windows Server 2016/Windows 10 OS release method. When the machine image itself needs to update, IT professionals start from scratch and install the OS and its updates, as well as configure the OS and any software on the image. With a new OS release every six months, Windows administrators should offload tasks to Packer; however, the tool does require upfront work.
Packer for Windows
Packer was not created with Windows in mind. Like many other DevOps-born tools, it was made for Linux systems. Packer does support Windows, but it takes a little effort to make it work.
For instance, Packer uses communicators to perform tasks on a VM as it builds an image. This process, called provisioning, is done either with the Secure Shell (SSH) or Windows Remote Management (WinRM) protocol. A Packer executable runs locally and communicates information via one of these protocols to a VM to build the machine image. To build a Windows image with Packer, use WinRM rather than SSH. For this setup to work, the administrator's local machine must run Windows; MacOS and Linux systems cannot use WinRM. OpenSSH has ported to Windows, opening up another option, although few Packer users seem versed on this nascent approach.
An issue with Packer for Windows arises around a headless build. Headless builds do not display a window of the console when you build a machine image. The headless approach fits with the highly automated steps of a code delivery and deployment pipeline, but Windows builds can encounter problems. For example, if a Windows update doesn't install during the build, the administrator cannot see the error without a console.
Use Packer for a Windows install
A Windows image requires a Windows setup ISO file and an autounattend XML file that will automate a lot of the Windows installation in the build VM.
The Packer template is a JSON file. In it, the administrator should define an ISO checksum, checksum type and URL so Packer can find the ISO to install the OS. Packer refers to this information as provisioners, which are tasks that can be done when the build is complete -- typically to install software and run scripts. Attach the autounattend file and any scripts to run before the provisioners via floppy files:
In this example, the administrator included a script to install Chocolatey, a package manager for Windows, in the Packer template to build a Windows machine image.
Using PowerShell scripts
DevOps engineers who configure Windows machines in code typically use PowerShell. Packer can work with this common scripting language.
One option is to call PowerShell scripts in the autounattend.xml file during the Windows setup. Use this to accomplish tasks such as installing a Windows update or enabling WinRM. Another approach relies on provisioners in a Packer template for PowerShell commands or scripts, as shown in this example:
This example tells Packer to run two PowerShell scripts on the VM. The code block specifies the type of script (PowerShell). Packer works with other types of scripts, such as bash, in the provisioners section.
Be careful with exit codes while running PowerShell in Packer. Packer, by default, only accepts an exit code in PowerShell of 0. However, there are other exit codes, such as 3010, when the admin installs software that requires a reboot. Packer would consider the script that exits with 3010 to have an error, unless the admin specifies valid exit codes in the template.
As the DevOps approach to code-based IT management becomes more common in Microsoft-centric teams, Packer for Windows is an option IT professionals should add to their automation arsenal.
