xPDT – the Next Generation of Deployment Automation

  • Article

In my last post, I introduced a new set of DSC resources available in the DSC Resource Kit Wave 8 that enable automated deployment of System Center and related prerequisites including SQL Server. In the DSC Resource Kit Wave 9, we added resources for Azure Pack. In the DSC Resource Kit Wave 10, we will be adding more resources for configuration and cross-component integration, as well as resources that enable cross machine deployment of these components without requiring the WMF5 Preview.

Automating distributed deployment is an interesting challenge, and one I have been working on for around 4 years now – first as the Program Manager for the Unified Installer feature of System Center 2012, then as the creator of the PowerShell Deployment Toolkit (PDT), and now as the author of these new PowerShell Desired State Configuration (DSC) resources – something I refer to as “xPDT”. For clarity, I now refer to PDT as “the original PDT”. With the release of the resources in the DSC Resource Kit Wave 10, it will be possible to automate full deployment and integration of the System Center and Azure Pack components covered by those resources, so I thought it was worthwhile to step back and write about the requirements and challenges of distributed deployment and how I solved those challenges using DSC. While my focus has always been on automating deployment of the infrastructure for the Microsoft Private Cloud stack, the same approach can be used for almost any distributed application or service. In fact, much of the base xPDT module that is used in my resources is also included in the xExchange deployment resources also included in the DSC Resource Kit.

I will break down these requirements and challenges as follows:

  • Remoting Tasks and Validation – by definition, a distributed deployment is spread across multiple servers, which means there is a need to initiate a series of tasks that make up a deployment from one location to multiple machines, and to make sure those tasks are only initiated where required.
  • Credentials, CredSSP, and Execution – many setups have specific requirements about which credentials they are run under, what permissions those credentials have, and some interesting requirements for how they are initiated when using a distributed or remoting scenario.
  • Profiles – some setups assume that the credentials under which they are running have a user profile present.
  • Dependencies – there are requirements for sequencing order of setup, both on a single server and across multiple servers.
  • Reboots – some setups require a reboot before they are considered complete.
  • Service Restarts – some setups restart specific services that are used as part of the distributed deployment mechanism.
  • Progress – how to report on progress across multiple servers.

Where relevant, I will also discuss how WMF5 provides new ways to solve these challenges. Each of these will be the topic of a blog post, starting right away – so stay tuned to the Build Cloud Deployment track!

This series will assume a basic understanding of DSC – for that, I recommend starting with Michael Greene’s excellent post “Desired State Configuration Blog Series – Part 1, Information about DSC”.