Writing Resuable, Modular DSC Configurations
A few weeks go I posted about writing better DSC Configurations with Configuration Data. Really, this was just the start of the journey. Ideally, you want to want to pull your Configuration Data from your CMDB, but often tools or processes are missing to get your configuration management up to this level of integration. So let's go with something 90% of the way there. Now this in-between state is nothing to scoff at. You can run with this if you need to. Let's take a look.
When you are building your configuration, you have two essential parts. Your Configuration, the .ps1 file that is compiled to generate MOFs and the Configuration Data, the .psd1 file that is used to provide data to the configuration. You want to modify the Configuration file as infrequently as possible, modifying this file is bound to cause errors and issues (People make mistakes). Also, you want the Configuration Data to be modular, so multiple people can work on it at the same time without any chance of conflicts.
So, let's build a succinct and reusable configuration. Take a look at the below example:
The small block of code above installs all the features for any given node, based on its role. The node is defined like this:
As you can see, the Roles property is an array. This allows you to specify multiple roles for a given node, making it extremely powerful and allows your roles to be more modular.
Let's take a look at the role definition.
The role definition defines which features are associated with the role.
Now let's discuss how you can bring all this together. The Configuration Data is made of of two major parts. The AllNodes block and the other Configuration Data. This is sometimes called Non-node Data. Ignore that name, we going to use it to store all sorts of information. Take a look at the below code and file structure.
When you are building your configuration, you have two essential parts. Your Configuration, the .ps1 file that is compiled to generate MOFs and the Configuration Data, the .psd1 file that is used to provide data to the configuration. You want to modify the Configuration file as infrequently as possible, modifying this file is bound to cause errors and issues (People make mistakes). Also, you want the Configuration Data to be modular, so multiple people can work on it at the same time without any chance of conflicts.
So, let's build a succinct and reusable configuration. Take a look at the below example:
The small block of code above installs all the features for any given node, based on its role. The node is defined like this:
As you can see, the Roles property is an array. This allows you to specify multiple roles for a given node, making it extremely powerful and allows your roles to be more modular.
Let's take a look at the role definition.
The role definition defines which features are associated with the role.
Now let's discuss how you can bring all this together. The Configuration Data is made of of two major parts. The AllNodes block and the other Configuration Data. This is sometimes called Non-node Data. Ignore that name, we going to use it to store all sorts of information. Take a look at the below code and file structure.
The script creates a hashtable for the configuration, then pulls in each of the Nodes that are represented in individual files. Then it pulls in all of the additional configuration data, such as domain and site information, finally the role information is imported, building a single configuration data file that can be used to compile your MOFs.
What are your thoughts on this type of modular DSC configuration?
Did you happen to notice the naming convention applied to resource names? That allows you to dynamically build DependsOn blocks.
