Configuration data

Now that we have covered both how deployments work (push and pull) in DSC and the workflow (authoring, staging, and execution) for using DSC, we will pause here for a moment to discuss the differences between configuration files and configuration data.

It is important to understand the concept of the separation of the what from the where that we covered in Chapter 1, Introduction to PowerShell DSC, when considering how to deploy servers, applications, and environments using DSC.

The DSC configuration blocks contain the entirety of the expected state of the target node. The DSL syntax used to describe the state is expressed in one configuration file in a near list format. It expresses all configuration points of the target system and is able to express dependencies between configuration points.

DSC configuration data is separated from DSC configuration files to reduce variance and duplication. Some points that are considered data are software version numbers, file path locations, registry setting values, and domain-specific information like server roles or department names.

You may be thinking, what is the difference between the data you put in a configuration file and a configuration data file. The data we put in a configuration file is structural data, data that does not change based on the environment. The data we put in configuration data files is environmental. For example, no matter the environment, a server needs IIS installed in order to serve web pages. The location of the source files for a web page may change depending on whether the environment is the development environment or the production environment.

The structural information (that we need IIS for) is contained in the DSC configuration file, and the environmental information (source file locations) is stored in the configuration data file.

Configuration data can be expressed in DSC in several ways.

Hardcoded data

Configuration data can be hardcoded inside DSC configuration files, but this is not optimal in most cases. You will mostly use this for static sets of information or to reduce redundant code as shown in the following code snippet:

configuration FooBar
{
    $features = @('Web-Server', 'Web-Asp-Net45')

    Foreach($feature in $features){
        WindowsFeature "Install$($feature)"
        {
            Name = $feature
        }
    }
}

Parameter-based data

Parameter-based data can be passed as parameters to a configuration block, like so:

configuration FooBar
{
    param([switch]$foo,$bar)

    if($foo){
        WindowsFeature InstallIIS
        {
            Name = "Web-Server"
        }
    }elseif($bar){ 
        WindowsFeature InstallHyperV
        {
            Name = "Microsoft-Hyper-V"
        }
    }

}
FooBar –Foo

Hashtable data

The most flexible and preferred method is to use the ConfigurationData hashtable. This specifically-structured hashtable provides a flexible way of declaring frequently changing data in a format that DSC will be able to read and then insert into the MOF file as it compiles it. This approach will be covered in greater detail later in Chapter 3, DSC Configuration Files, but must be included in this chapter to fully describe DSC architecture. Don't worry too much if the importance of this feature is not readily apparent. With the following command lines, we define a specifically formatted hashtable called $data:

$data = @{
    # Node specific data
    # Note that is an array of hashes. It's easy to miss
    # the array designation here
    AllNodes = @(
        # All the WebServers have this identical config
        @{
            NodeName           = "*"
            WebsiteName        = "FooWeb"
            SourcePath         = "C:FooBar"
            DestinationPath    = "C:inetpubFooBar"
            DefaultWebSitePath = "C:inetpubwwwroot"
        },
        @{
            NodeName = "web1.foobar.com"
            Role     = "Web"
        },
        @{
            NodeName = "web2.foobar.com"
            Role     = "Web"
        },
        @{
            NodeName = "sql.foobar.com"
            Role     = "Sql"
        }
    );
}
configuration FooBar
{
    # Dynamically find the web nodes from configuration data
    Node $AllNodes.where{$_.Role -eq "Web"}.NodeName
    {
        # Install the IIS role
        WindowsFeature IIS
        {
            Ensure          = "Present"
            Name            = "Web-Server"
        }
    }
}
# Pass the configuration data to configuration as follows:
FooBar -ConfigurationData $data

The first item's key is called the $AllNodes key, the value of which is an array of hashtables. The contents of these hashtables are free form, and can be whatever we need them to be, but they are meant to express the data on each target node. Here, we specify the roles of each node so that, inside the configuration, we can perform a where clause and filter for only the nodes that have a web role.

If you look back at the $AllNodes definition, you'll see the three nodes we defined (web1, web2, and sql), but also notice one where we just put an * sign in the NodeName field. This is a special convention that tells DSC that all the information in this hashtable is available to all the nodes defined in this AllNodes array. This is an easy way to specify defaults or properties that apply to all nodes being worked on. We'll cover some strategies for using this as we move forward in the book.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset