0

Infrastructure Blueprints – An Easier and Better Way to Share #PSDSC Configurations

A while ago, I wrote an article to introduce Infrastructure Blueprints. Today’s post is about a more refined version of that project. These infrastructure blueprints are the starting point for a bigger discussion on dynamic infrastructure. We will discuss that later. Read on!

Within the Infrastructure as Code (IaC) practices, there is enough emphasis on the repeatable and reusable automation enabled using configuration management tools. This is referred to as configuration as Code. Configuration as Code enables consistent methods to configure IT systems. And, when we integrate these processes into DevOps practices, we can ensure that the configuration across different stages of the deployment (Development / Test / Staging / Production) can be done in a efficient and consistent manner.

One of the best practices in Configuration as Code practice is to ensure that the configurations that we deploy are made reusable. This means that the configurations are parameterized and have the environmental data separated from the structural configuration data.

PowerShell Desired State Configuration (DSC) supports the separation of environmental configuration from structural configuration using the configuration data artifacts. And, sharing of parameterized configurations is done using the composite configuration modules or what we call composite resources. Composite configurations are very useful when a node configuration requires a combination multiple resources and becomes long and complex.

For example, building a Hyper-V cluster includes configuring host networking, domain join, updating firewall rules, creating/joining a cluster, and so on. Each node in the cluster should have this configuration done in a consistent manner. Therefore, the configurations that are applied for each of these items can be made reusable using the composite configuration methods.

Also, a real-world deployment pipeline implemented using IaC practices should also have validation of the infrastructure configuration at various stages of the deployment. In the PowerShell world, this is done using Pester. Within DSC too, Pester plays a very important role in validating the desired state after a configuration is applied and in the operations validation space.

Infrastructure Blueprints

The infrastructure blueprints project provides guidelines on enabling reusable and repeatable DSC configurations combined with Pester validations that are identified by Operations Validation Framework. As a part of this repository, there will be a set of composite resource modules for various common configurations that you will see in a typical IT infrastructure.

Infrastructure Blueprints are essentially composite resource packages that contain node configurations and Pester tests that validate desired state and integration after the configuration is applied.

This repository contains multiple composite configuration modules. Each module contains multiple composite resources with ready to use examples and tests that validate the configuration.

The following folder structure shows how these composite modules are packaged.

  • Diagnostics folder contains the Simple and Comprehensive tests for performing operations validation.
    • Simple: A set of tests that validate the functionality of infrastructure at the desired state.
    • Comprehensive: A set of tests that perform a comprehensive operations validation of the infrastructure at the desired state.
    • For ease of identification, the test script names include Simple or Comprehensive within the file name.

The Operations Validation Framework can be used to retrieve the list of tests in this module and invoke the relevant ones.

Once you know the composite resource that is applied on the system, you can invoke either simple or comprehensive tests using the Invoke-OperationValidation cmdlet.

  • Examples folder contains a sample configuration data foreach composite configuration and also a configuration document that demonstrates how to use the composite resource.
  • CompositeModuleName.psd1 is the module manifest for the composite configuration module.

This manifest contains the RequiredModules key that has all the required modules for the composite configuration to work. This is listed as a module specification object. For example, the RequiredModules key for Hyper-VConfigurations composite module contains the following hashtable.

These composite modules are available in the PowerShell Gallery as well. And, therefore, having the RequiredModules in the module manifest enables automatic download of all module dependencies automatically.

As you can see in the above Install-Module cmdlet output, the required modules are downloaded from the gallery. Thanks to Chrissy for this tip.

You can contribute to this project by submitting a pull request. All you need a set of composite resource modules packaged as a PowerShell module with DSC resources. Of course, ensure you add clear examples and tests.

Filed in: Articles, DevOps, Online Only Tags: , , ,

Leave a Reply

Submit Comment

© 9808 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: