Deal with multiple receipe versions

DSC
1

Hi all,

We have some servers to deploy with an subset of components and some configurations (registry, env variables etc.), we call it a ‘baselayer’. This baselayer is ‘versioned’: dev team have something like that:
Version 1:

  • component A: v1.0.0
  • component B: v5.4.0
  • component C: v1.2.3
  • share: someshare(everyone:read)
  • …
    Version 2:
  • component A: v1.1.0
  • component B: v5.4.0
  • component C: v1.2.5
  • share: someshare(everyone:read/write)
  • …

We try to translate it into DSC logic and face some trouble to made things work smoothly.

Our goal would be to have a config like that:

$MyData = @{
    AllNodes = @(
        @{
            NodeName = 'ProdSrv'
            Version  = '1'
        }
        @{
            NodeName = 'PilotSrv'
            Version  = '2'
        }
    )
}

Configuration MyDscConfiguration {
    Node $AllNodes.NodeName {
        BaseLayer myBaseLayer{
            Version = $Node.Version
        }
    }
}

With this kind of config, I can dynamicaly get the baselayer desired version in our CMDB.

I tried to keep those ‘versions’ in a versioned DSC Module. So I have 2 modules:

  • module Baselayer version 1 that contains a single composite resource describing my version 1 of BaseLayer
  • module Baselayer version 2 that contains a single composite resource describing my version 2 of BaseLayer

I figured how to dynamicaly load the module with the version parameter (with some kind of ugly on the fly dot sourcing)

It works if my 2 example nodes have the samed version, but if there are more than one version, I get the message :
Resource name ‘BaseLayer’ is already being used by another Resource or Configuration.

I think I’m on the wrong way … how would-you implement my initial need (have some kind of versionned receipes) ?

2

Yeah, there’s a few dozen ways to do this - I cover them in “The DSC Book” - but none are perfect. The problem is more tooling than anything else. DSC can do a lot, but without tooling, it can all be a lot of effort.

My thinking is that Tug (the open-source DSC pull server) becomes the answer. With it, you can code up your own responses to LCM requests, meaning you could dynamically create a MOF on the fly when the LCM asks for a MOF. That would make a lot of scenarios a crap-ton easier, including this one. You could store fragments in a database, query them, create a config script, run it, and get a MOF, all on the fly. It means some coding for you, but you’ll be able to do whatever you want without worrying about what the LCM is willing to do (e.g., with partials).