Inside the Node keyword block are the actual statements that will determine the configuration state of your target nodes. This is where you'll use the DSC DSL and DSC resources to describe the different operations, settings, software, and other aspects of your nodes. This is the last and most important step in the syntax of DSC configuration script files, as this is the part that is parsed by DSC and compiled to MOF using DSC resources. There are a lot of moving parts here but not much to explain in general as this will be very implementation-specific. It would not be much use to you to regurgitate help file documentation for each DSC resource, but we will cover some best practices here.
It is very easy to hardcode or write down the exact text of configuration data next to the DSC resource parameters that are using it. You must identify these hardcoded values and extract them to configuration data variables ($AllNodes, $Node, or $ConfigurationData). We covered the separation of environmental data and structural data in Chapter 2, DSC Architecture, in the Configuration data section, and this is where it comes into play. We want to take all the environmental data out of our DSC configuration script file and inside the node blocks is where it most often crops up. Fortunately, DSC makes this easy to extract using the DSC special variables. We will move more into the format of specifying the configuration data in the Defining a DSC configuration data file section of this chapter.
A common mistake is to put the PowerShell code inside the node block that performs some kind of decision logic for the target node. You might need to parse a string, figure out a version number, or resolve a path, and so on. There are many different things you might try to accomplish inside the node block because it's so easy to drop down to PowerShell and get it done. You must resist this temptation because adding logic that needs to be executed on the target node here breaks the utility and power of the DSC engine. DSC allows idempotent configuration of a target node no matter how many times it is run on the target node. The logic put into the DSC configuration block or node block is not part of the DSC resources, and so it is not executed on the target node but instead on the computer you compiled the MOF on. Remember, the DSC resource is the part that does the actual work of determining and applying the state, and the code that you put in the node block is never seen by the DSC resources. When you go to run DSC on the target node again, your code will not be re-evaluated.
For example, you write some code to determine what version software to install on a target node based on a file on a remote server. When you compile your DSC configuration to MOF, that value is stored, as is in the MOF file. When applied to the target node, that value is used. If run again, that value does not change because the MOF was not regenerated.
There are some cases where code can be placed inside a node block and not be a problem. Code or conditional logic inside this area that makes decisions based on your deployment processes can be very useful and powerful here, for example, code that determines whether a software package is installed on test servers or production servers or code that determines which set of servers are web servers or database servers, or both. These are examples of environmental choices whose data is stored in your ConfigurationData files, but the decision to use it lies in your DSC configuration script.
If you are not supposed to put any code inside the Node or configuration blocks, where should it be put? If you have code in these places, it is a clear sign that you should be creating a DSC resource that handles this logic or decision-making. The DSC resource is the best place to understand how to apply this logic in an idempotent manner. In the next chapter, we will cover how to create DSC resources, so stay tuned.