| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [View Raw Code] [Original HTTPS Page] |
DSC offers different ways of abstraction and composability (see examples here or follow the link to documentation).
And here's a rule of thumb on how you can compose them:
Always remember that the goal of DSC is to create a human-readable Policy document that give a good idea of the current configuration, at least for the layer of abstraction you're looking at. The layers you create are there to contain change within a manageable scope, so that they are decoupled from one another.
One way to compose Node configuration from different sub-configurations is to use a root configuration that dot source the sub-configurations and call the nested configuration function, as per the ticketmaster example by Mike Walker
Although it may look like the best option, it has severe drawbacks:
. $here\..\SharedDscConfig.ps1
Configuration Default {
#The 'parameter' for ModuleName can't be a variable here
# and the import in sub-resources are ignored
Import-DSCresource -ModuleName PSDesiredStateConfiguration
node $AllNodes.Nodename {
#This is ok
SharedDscConfig -blah 'a'
#This is the best declarative syntax we can do
$MySharedDscConfig = @{
blah = 'c'
}
SharedDscConfig @MySharedDscConfig
#this does not work (unless the SharedDscConfig is in the same file)
#dot sourcing does not work either
#SharedDscConfig Test {
# Blah = 'b'
#}
}
}So the way to package some configuration to be re-used, is via Composite Resource. In the end, those are just Configuration Packaged in a certain way.
| Back | FazBrowse Home | New Git URL |