PowerShell

Before jumping into DSC I decided to build out my understanding of infrastructure automation by doing it with plain vanilla Powershell. This was a good thing because I only had a cursory understanding of Powershell and this exercise provided a much needed deep dive into Powershell and the base platform for DSC.

After a doing a couple DSC tutorials, I took a few days of deep thought, much Googling, and a lot of trial and error scripting from an OOP perspective to produce this architecture. I would not take this as something that should be followed as it has not passed the test of time nor has it been used at scale on multiple environment. The only purpose was to learn Powershell to prepare me for DSC, which is the tool I recommend for Windows infrastructure configuration.

Powershell Infrastructure Management System

• Environment Nodes Script

  • Environment Node Data Module

    • Environment Node Data Base Module

  • Workflow Module

    • Workflow Server Class Module

      • Workflow Server Type Module

        • Workflow Base Module

  • Client API Module

    • Service Module

      • Dependent Modules/Scripts

The environment node script would pass environment node data to a workflow module.

Environment node data would define properties of a node that are specific to one node. This data would also include the base environment node data that includes data that is common across all instances of a specific type of node. This could be extended to build up environment data from various modules containing data from various levels of generalization.

The workflow modules define the steps necessary to configure or provision a node. I assume there could be additional workflows besides provisioning and configuration. There could also be various types of provisioning and configuration workflows. The workflow module doesn't contain much in terms of logic. It is responsible for logging, but it calls the client API module to do work.

Workflows are composable. Depending on the server type and server class defined for the node, additional workflows can be triggered. So, you can alter a nodes configuration just by defining specific values for server type and class to trigger the specifc workflows you want to configure a node.

The client API module provides an abstraction layer to help stabilize and decouple the the workflow from having dependencies on specific modules. It does this by having just one dependency on a service module. The dependencies can be changed by using various service modules that adhere to the API that the client module expects. The client API will also be light on logic and its main purpose is to provide a stable interface to the service module.

Why not have the workflow call the service module directly? The service module is where most of the logic will be and will be the most volotile part of the architecture. Having the client API between the workflow and the service provides some added stability for the the workflow.

The service module is where the work of actually configuring nodes occurs. It used base Powershell commands and various modules to configure nodes. This is also the layer where most of the changes occur. Since the changes are hidden behind the client API we don't have to constantly change the workflow, when we make a change it is automatically applied to any client API and workflow that uses the service.

Having these abstractions allowed me to get rid of lots of duplication and make scripting a much more maintainable endeavor. Also, separating data from logic made the modules more generic and reusable, again reducing duplication and while gaining maintainability. I basically applied some of my OOP knowledge to scripting based on my overview of DSC.

Pester

Pester provides a framework for running Unit Tests to execute and validate PowerShell commands inside of PowerShell.