Nested ConfigData

This topic contains 2 replies, has 2 voices, and was last updated by Profile photo of Alan Roberson Alan Roberson 2 years, 1 month ago.

  • Author
    Posts
  • #20166
    Profile photo of Alan Roberson
    Alan Roberson
    Participant

    These are close to the "Seperating What from Where" Blog entry but I can't quiet extrapolate an answer to the below questions.

    Question 1:
    have 10 production and 10 dev servers each split between 2 locations. They all have the same settings/configurations applied but with different values between Dev and Production. For example: Dev servers have an environment variable set to "TEST" Production servers have it set to "PROD"

    I know I could set the proper value for each server individually in configdata
    or
    in the configuration script I could use a conditional like
    node $allNodes.Where({$_.ServerStage -eq 'production'}).NodeName

    Is there a better way ?

    I would like to have some construct in the configdata simular to NodeName = '*'
    (maybe like NodeName.Serverstage = 'production' ????)

    where I could group the prod settings and the dev settings without having to assign individually to each server or repeat blocks in the configuration for each server type.

    Question 2:
    In the Configuration file is it possible to create compound 'Where' conditionsLike
    node $allNodes.Where({$_.ServerStage -eq 'production'} –and {$_.ServerLoc -eq outTown'}) .NodeName

    Thanks for insights, suggestions, and even rants

  • #20170
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    You have a few options here. There does need to be something the distinguishes your Dev servers from Prod at the node level, but that can be a single attribute (such as the ServerState = 'Production' used in your example.) Once you have that, you can store other variables outside of the AllNodes section in your configuration data, and use that ServerState value to figure out which values to look up. Something like this:

    $configurationData = @{
        AllNodes = @(
            @{
                NodeName = 'Server1'
                ServerState = 'Production'
            }
    
    
            @{
                NodeName = 'Server2'
                ServerState = 'Production'
            }
    
    
            @{
                NodeName = 'Server3'
                ServerState = 'Development'
            }
    
    
            @{
                NodeName = 'Server4'
                ServerState = 'Development'
            }
        )
    
        Settings = @{
            Production = @{
                Value1 = 'Value1ForProduction'
                Value2 = 'Value2ForProduction'
            }
    
            Development = @{
                Value1 = 'Value1ForDevelopment'
                Value2 = 'Value2ForDevelopment'
            }
        }
    }
    

    Then in your configuration, you'd just have:

    node $someNodeNames
    {
        someResource Blah
        {
            Value1 = $ConfigurationData.Settings[$Node.ServerState].Value1
            Value2 = $ConfigurationData.Settings[$Node.ServerState].Value2
        }
    }
    

    That's a reasonably straightforward approach that only uses functionality offered in the base DSC module.

    If you're using the DSC tooling from https://github.com/PowerShellOrg/DSC (originally written at Stack Exchange by Steven Murawski), the DscConfiguration module offers some alternative ways of organizing and maintaining your config data. Mainly, it involves splitting the giant hashtable up into multiple files, and providing some hierarchical structure where you can override values and group nodes together. You could use this approach to create Services for your Production and Development environments, and the Resolve-DscConfigurationProperty command would take care of figuring out which values to use (based on which nodes you have associated with each service.)

    This doesn't make the configuration function itself any simpler, but makes it easier to manage a large ConfigurationData structure without a bunch of repetition.

  • #20205
    Profile photo of Alan Roberson
    Alan Roberson
    Participant

    Thanks Dave, that's what I was looking for. Much easier to understand with the example.

You must be logged in to reply to this topic.