A tool to simplify PowerShell DSC using YAML
PowerShell Desired State Configuration (DSC) is an essential part of the configuration, management and maintenance of Windows-based servers. It allows a PowerShell script to specify the configuration of the machine using a declarative model in a simple standard way that is easy to maintain and understand.
DSC requires that you create a Configuration Script which, when executed generates a Managed Object Format (.mof) file that gets consumed by a nodes Local Configuration Manager (LCM). DSC requires that the user creating the configuration script and the associated configuration data has a solid understanding of the PowerShell syntax and language structure.
The purpose of this tool is to simplify DSC and make it more accessible for developers and operators of all backgrounds by abstracting the need for any PowerShell code creation.
OK, so why make this tool?
One of the problems I have seen over the last couple of years of using DSC is that: developers don't know PowerShell. This is not exactly unexpected when we think of the amount of developers we have in the wild and the odds of knowing PowerShell even at a basic level is mostly down to people with a Windows/.NET background.
However, DSC should not be limited to only people with Windows/.NET backgrounds.
The concept is simple, Take a .yml
configuration file and transform that in a hashtable of data that is then consumed by the LCM on a remote node(s).
winrm quickconfig
Import-Module vamp.psm1
vamp -apply example
winrm quickconfig
Import-Module vamp.psm1
spec
yml file. (see examples)config
yml file. (see examples)vamp -prep nameofspecfile
vamp -apply nameofspecfile
All of the .yml
files in the spec
and config
directory can be used as an example, These are not required.
Omg this is confusing! Help. Lets break this down to show how simple vamp is to use.
The TestAll switch will simply run the Test-WSMan
cmdlet against all the nodes defined within your spec file.
This is a simple way to ensure your nodes are listening to incoming connections over WinRM.
In the below example we run the testall functionality against the development spec file.
vamp -testall development
The need for the Prep switch comes from the underlying functionality of Modules in PowerShell. In order to run code from a module we need that module to be stored locally on the node that is executing the code and also in the PowerShell module path.
The Prep switch allows us to grab the required modules that are defined within the configuration files for the defined spec file and download them from the PS Gallery.
This action is only performed on the node in which you're running vamp. Once downloaded, the modules will be pushed to the nodes that require the modules for the upcoming configuration. This step helps take the guess work out of having to manage modules for specific configurations.
vamp -prep development
This would look into the spec file named development.spec.yml
and find the nodes listed within. Once discovered we can look into the config files that relate to those nodes and download the required modules. Once downloaded we copy them to the nodes that will need them for their upcoming configuration.
This one is simple, Make it so!
The Apply switch allows us to apply the configurations for the nodes listed in our spec file.
vamp -apply development
Apply will first call the test method of the DSC resource to check that the node is in desired state. If the resource is in desired state then we simply move along to the next resource. If not then we call the set method of the resource to apply the changes requested to the node.
Keep your configuration files in the config directory. You can keep all your configuration in here (the root) or split them up into subfolders that help you make more sense of your environment.
A configuration file is written in standard .yml
making it easy for everyone to use and adopt. This helps really hit home the main functionality of the tool in that you don't need to write a scrap of PowerShell in order to use PowerShell DSC with vamp.
Lets take a look at an example:
WebServer.yml
- WindowsFeature:
name: Web-Server
ensure: present
ModuleName : PsDesiredStateConfiguration
- WindowsFeature:
name: Web-Asp-Net45
ensure: present
ModuleName : PsDesiredStateConfiguration
In this example we're configuring a Windows Feature (Web-Server) and a Service (bits).
The syntax here is simple. We start off by declaring the name of the resource we would like to use. This can be ANY PowerShell DSC resource.
Then, we access the name property of the DSC resource and pass in the name of the Windows Feature
and Service
we want to configure.
We also pass in any other required values for properties in the resource such as ensure
and status
. For more information on required parameters for each resource be sure to read the documentation for the module in question.
We also pass in the ModuleName
for the module in which the resource resides. This is used in both to Prep
and Apply
phase of vamp and is required in all vamp configuration files.
There is no limit to the amount of configuration steps you could have in one file. However, to keep things modular it may be easiest to create a set of .yml files needed for your desired configuration.
The Spec files are used as guidance for vamp.
We need to know which nodes are going to be applying which configurations. This is where spec file(s) come in. You can have as many as you like to help you organize your environment.
This is a simple way to organize roles and spread them over multiple groups of nodes.
important
that the name of the config match the .yml
file name in the config
folder.development.spec.yml
- nodes:
name:
- CoolServer02
- CoolServer03
configs:
name:
- WebServer
- Firewall_Example
- Git
TO DO
There is always lots to do with this project.
The aim of this project is to simplify DSC to a state that anyone can pick it up and get going.
Here are a couple of things on the to-do list for now: