In this article I am going to expand on my simple example from the last article. Step it up a notch if you will.
The first thing I am going to cover is the DependsOn property.
This is why each of your declared resources has a name.
Lets consider the following sample:
The Log resource DependsOn the File resource citrixFolder. What this means is that the File citrixFolder must complete or else the Log afterCitrixFolder will not be attempted. Another way to say this is that the test for citrixFolder must return True.
This allows a chain of dependencies to be defined. Defining them here, the configuration author must know about the dependencies and declare them. Another option is that the resource provider itself is aware of dependencies and enforces them, but that is definitely an advanced topic.
In the last article I had mentioned that the Local Configuration Manager configuration could be changed. This to is a configuration, and a special command.
Here is my scenario, I have a package installation that DSC is handling for me. This is a complex installation and it requires two reboots for everything to be installed properly. I want DSC to handle the rebooting, I don't want to have to setup jobs and start-up commands and the like as in the past.
For this I use the following example;
The first thing to notice is lines 6 through 10. This is a special resource; localconfigurationmanager. It supports modifying the properties of the LCM itself. In this case the reboot behavior is false by default and I want to set that.
After I generate the MOF document, there will be two documents in the .\sample path. The localhost.mof as before and a localhost.meta.mof that defines the behavior of the LCM. Set-DscLocalConfiguraitonManager applies the LCM configuration and then Start-DscConfiguration applies the remainder.
If you have done any blog reading of DSC you would most likely have run across the 'Pull' model (and realize that I have been showing the 'push' model) of applying and managing configurations.
I bring this up now just to mention that the Pull model requires the LCM to be configured this way; as shown here:
In this sample I am setting the GUID that matches the configuration of this machine, I am telling it that it is using WebDownloadManager to download its configuration, the URL of my DSC Pull Server, that it will only apply the configuration and then stop, that it will reboot, and I set the frequency down to the minimum since I am impatient.
Just like above, This is a modification of the Local Configuration Manager on the target machine.
The Pull model is pretty handy, as there is simply one web endpoint where configurations call home to and then fetch their configuration and apply it. If I change the configuration, I change it here and when the node performs its refresh it will look to see if the configuration changed and if it did the new configuration is downloaded and applied.
Pretty slick feature. But I have to admit, keeping a bunch of GUIDs straight is not the easiest thing. In this mode each configuration is the GUID identified by the ConfigurationID. And you have to make sure you give the right configuration ID to the right VM.
Optimally, you set up an array and simply randomly assign one configuration to a machine out of a bunch of machines and wait for the magic to happen. That is really where that model works.
If you really want to get into all of the possibilities of applying configurations to machines there is a good blog article that describes the options when you want your machine to automatically configure on boot up with DSC. There are some interesting options in there such as
- using mini-setup and the unattend.xml to set a task to run a configuration script on boot.
- drop a pending.mof in the path %systemdrive%\Windows\System32\Configuration (mount the vhd and copy the file in) that the LCM will automatically process on boot
- inject a meta-configuration (the configuration of the LCM) to download its configuration document
Not mentioned is that you can use and agent in the VM to execute a script, set a MOF, or trigger the LCM in a number of combinations. And there is also remote applying a configuration as this is what Start-DscConfiguration uses by default using the -ComputerName of a remote machine (you have to be administrator).
Using SCVMM Service Templates the DSC configuration script would be the 'script application package' being executed by the SCVMM agent. And the model is similar for a Windows Azure Pack Gallery Image. If you are deploying to Azure you can use the VM DSC Extension or the VM Script Extension - both through the Azure API.
So, as you can see, the flexibility is all over the place.
No comments:
Post a Comment