Configuration and Configuration Data!

Let’s take a look!

As I have mentioned in the previous post  – we need to describe what we want! HOW? Where? What to start from?

That what I was trying to understand when have decided to try it!

If you are already in Love with PowerShell – you will probably have a lovely editor and all the staff you need.  The only thing you may be missing – is “Windows Management Framework 5.0”. It is currently in Production Preview (RTM version: http://aka.ms/wmf5download)

If you are not in love with PowerShell – you will need an Script Editor. As for the starters – “PowerShell ISE” would be fine, as you can extend it functionality with the addons, that make you fall in love with scripting! I’ll make a post about one of them later!

Once you have got what you need and watched the videos from MVA and Channel9 – we are ready to go!

As a start point I would suggest to take a look what is configuration and configuration data.

Сonfiguration

I would not copy and past the stuff from this resource that I have found very useful!!! But I would probably go through the challenges I have had during the understanding how it really works and what approach to choose initially.

When I have first looked onto different examples I usually saw something like this:

[DSCLocalConfigurationManager()]

configuration  ClientConfig {

Node localhost{

Settings

{

So… do I need to set this up for every Node? Is it something right to do, as you want to have automated as much as possible?

That was initially confusing. And the answer is – You don’t! There is a better way to organise this!

The main benefit that we will have there – is variables:

configuration DEV_TEST
{
  # Import the module that defines custom resources
  Import-DscResource -Module PSDesiredStateConfiguration
  Import-DscResource -Module xWebAdministration
  Import-DscResource -Module xCertificate

  Node $AllNodes.NodeName
  {

    WindowsFeature Web-Server 		{
      Ensure = 'Present'
      Name = 'Web-Server'
    }

.......

 xWebSite DefaultWebSite
    {
      Name = $node.DefaultSiteName
      Ensure = 'Present'
      BindingInfo = MSFT_xWebBindingInformation
      {
        Port = $node.DefaultPort
        Protocol = $node.DefaultProtocol
        CertificateThumbprint = $node.PfxPortalThumbprint
        CertificateStoreName = $node.PfxStore
      }

      PhysicalPath = $node.DefaultPhysicalPathWebSite
      State = 'Started'
      DependsOn = @('[xWebAppPool]DefaultAppPool', '[File]DefaultWebContent', '[xWebSite]DefaultSiteNameRemove', '[xPfxImport]PortalWebCertificate')
    }

.......

DEV_TEST -ConfigurationData 'Test_Websites_Config.psd1' -OutputPath c:\DSC\HTTPS

The variable approach, that this example has, will basically create the configuration for all the nodes that represent the service.
It (The last line :)) will create a set of MOF files for each Node with common and Node specific settings that the Configuration Data (see below) has.
If you you are using Push – you are ready to go to test it, if Pull – you need to check something else….

Configuration Data

This is where you will define all the variables that will be used.

It will have to major sections:

1. Data that is common for all nodes.

2. Data that is node specific. Be aware that you will need to have each node in this section, even if the node specific config will be empty. This need to be done, because DSC simply need to know the list of nodes 🙂

Data that is common for all nodes.

AllNodes = @(
	@{
		NodeName = "*";

		DefaultAppPoolName = "DefaultAppPool";
		DefaultSiteNameRemove = "Default Web Site";
		DefaultSiteName = "Default";
		DefaultPhysicalPathWebSite = "C:\inetpub\wwwroot\Default";
		DefaultPort = 443;
		DefaultProtocol = "https";
		DefaultSourcePath = "\\Server\DSC_Data\Project\WebSites_Data\Dev2\wwwroot\Default";
		DefaultrestartSchedule =  @('00:00:00', '07:00:00', '16:00:00');

That config will define that will be created on the all nodes.

If your config describe the nodes for one service - then they will have most parameters and components in common.

Data that is node specific.

	@{
		NodeName = "*-SH-TEST-011";
		PSDscAllowPlainTextPassword = $true;
		}
	@{
		NodeName = "*-SH-TEST-012";
		PSDscAllowPlainTextPassword = $true;
		}
)
}

That is something you may want to be specific for a node. As a good example – could be the connection string changes for the service, if you are running you service in multiple regions, that will have different local or geo-replicated databases for you service to connect to.
I have not yet played with that, but I have already found that module xWebAdministration gives you ability to operate with configs during the deployment!

P.S.
It is my 4th day of playing with the DSC – and I can say that I really impressed with this magic, and have already created the configuration for the IaaS elements configuration for the project I’m currently working on!
Few more days of testing – and we can definitely start using it!

Next steps would be config changes and tuning the PROD!!!