Automatic creation of images with puppet, MDT

This document describes the plan for building Windows images for bare metal provisioning.

The intention is to build a modular and repeatable image build process using Microsoft Deployment Workbench (MDT) and Puppet but without Group Policy or other services that require joining a Microsoft Domain. The overall build process will rely heavily on Puppet to provide more visibility and accessibility to our configuration for Windows Operating Systems.

Assumptions

• There is no intention to join machines to a domain or provide ongoing configuration management with GPO or puppet. Changes will require the building and deployment of new images, similar to AMIs in AWS.
• Building the image will be broken down into two MDT task sequences to capture images. The first task sequence will create the base image. By using a base image we will cut down time spent to recapture deploy images when changes are need and gives us a point to diverge when needing to create multiple versions of an OS The second image will include software installed and modifications made by puppet and will be the one that is deployed to bare-metal nodes. This second image will include Loaner and other divergent configs.
• The creation of the second image should be able to be completely automated. With the workflow of: Make a change to puppet, request an image be created, get an image with the new puppet config applied.
• Puppet will provide a common, publicly discoverable configuration point for windows as well as linux and OS X, allowing modification of the system configuration by people other than Windows administrators.
• The 2008r2 builder image is the one currently being reworked to fit into the above mentioned architecture (per Tara's request) . Once complete, this will provide us with a template to start for other Windows OSes, but there will be varying degrees of changes required depending upon the OS and tester vs builder configurations.

Image Build Steps

• The first task sequence or base task sequence
  • Installs and builds onto the out-of-box Windows Image
  • Will consist of:
    • The installation of large applications that is unlikely to change for extended periods of time
      • Such as Microsoft Visual Studio
    • The installation of unlikely to change developer tools
      • Such as Microsoft Direct X SDK
    • The installation of Microsoft updates
      • This will install the pre-approved updates from our WSUS server
      • In this task sequence Windows is configured to talk to our server and run a one time update
    • Application or tools that may be useful during the Deploy task sequence or troubleshooting in case image capture fails
    • An Image capture of the above
• The second task sequence or deploy task sequence
  • Installs and builds onto the base image
  • Will consists of:
    • Installation and configuration of Puppet
    • One time Puppet run
      • The majority of OS configuration, application install, and file management will be handled here
    • A full sysprep
    • Init scripts capture for bootstrap for both cloud and baremetel installs
      • Used for host naming, etc
      • Will need to to be versatile enough to work with multiple hooks.
    • An image capture of the final deploy image

In theory the deploy image will be deploy-able by Ironic. Though this is still needed to be tested once ironic supports whole disk images. Also the deploy image can be deployed to a VM and recaptured to create a cloud deploy-able image such as an ami should we later decide to replicate this into a cloud infrastructure.

Costs/Risks

• There may be issues with the number of registrations with KMS because we are redeploying an image instead of building a new image on each deploy
• The machine naming sysprep/init script will need to be reworked and executed in a different manner than we currently use for deployment
• Actual deployment of images will rely on the ability of openstack/Ironic to deploy whole disk images

[tracking etherpad]