A common problem with Powershell modules is that they need to be configured slightly differently when being used for different needs. For example, developers may want a module to use a local instance of a service in order to do development or testing. But, on a server, the module might be expected to connect to the instance of a service specific for that environment. These are two separate groups of users, but each has the same need, a default configuration that makes sense for them.
One way we’ve found to help make this a little more manageable is to create a standardized way to configure local default configuration’s for developers, while creating an interface which can be used by service providers to set default configurations for use on the servers.
This comes about by standardizing on 4 functions:
- Set-{ModuleName}Config –Environment [Prod|Test|Dev|Local]
This is the function that most people will use. If you want to point that module to use a particular environments services, use this function.
For developers, this is useful to point the module at their most commonly used environment. For a service they help build and maintain, that would most likely be local. But, for service they only consume, that is usually Prod.
For module developers, this function can be used to set the default configuration for the module. In general, this turns out to be defaulted to Prod. If your not the developer of a service, and you are going to use a Powershell module to interact with that service, you’re generally wanting to point it to Prod. This is the most common use case, and module developers usually setup module defaults for the most common use case.
For service developers that use the module within their services, this command is flexible enough for them to determine what environment their service is running in and set up the module to connect to the correct endpoints. - Save-{ModuleName}DefaultConfig
This is mostly used by developers.
Once you have the environment setup the way you want it, use the Save function to save the configuration locally to disk. We have had success saving this file under the users local folder (right next to their profile); so the settings are not machine wide, but user specific.
- Restore-{ModuleName}DefaultConfig
This function usually isn’t called by developers / end users.
This function is called when the module loads and it will check if the user has a local configuration file. If it finds one, it will load the values into memory.
Services usually don’t have a local configuration file. - Test-{ModuleName}Configured
This function usually won't be called by the end user. It's used internally to determine if all the important properties are setup before saving the properties to disk.
To get people to adopt this strategy, you have to make it easy for module developers to add the functionality into their module. To do that there’s one more function:
- Add-DefaultConfigToModule –ModuleName <ModuleName> –Path <Path>
This will add 4 templated files to a module, one for each function. It will also update the .psm1 file to end with a call to Restore-{ModuleName}DefaultConfig.
Below is a very mashed together version of the files for the module.
The code does assume all the module configuration information is stored in $global:ModuleName
And, these files are to be placed within a subdirectory of the DefaultConfig module called /resources/AddTemplate:
