Home / IT & Computer Science / Cloud Computing / Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline / Automation Desired State Configuration (DSC)
Automation Desired State Configuration (DSC)
A demonstration of the someone utilising some of the DSC options discussed previously
Let’s take a look at a walkthrough of using Azure Automation to deploy desired state configuration to a virtual machine running in Azure. Now, I’ve already set this up and got it working, so we’ll take a look at the finished product here in a second. It takes a little bit of time to import things, and configure things, and wait for them to run. So we’re going to go ahead and set this up, go through all the motions, but then take a look at the one that I’ve already implemented. So to begin, let’s take a look at a couple of things. So here we have our Automation account. And what I’ve done is I’ve imported a couple of assets.
The assets I’ve brought in are actually some modules. And the modules that you can get from the gallery can really extend what you can do with PowerShell DSC. What I’ve brought in are the xNetworking module and I’ve brought in the Chocolatey module. So xNetworking gives you some additional desired state configuration options for networking, things like firewall rules, which is what we’re going to do. And then Chocolatey is a package management tool that I’m going to use. We’re not to use it as part of DSC, but we just want to make sure it’s installed on the system that we’re managing. So these are just two additional modules that I brought in from the gallery.
And so we can go search the gallery and just type, for example, xNetworking.
And we can find that module. We can import it, just like we did when we looked at the assets. So nothing terribly special about this. We’ll just import the module and get it ready to go. And so once that module is available, we can now use it as part of PowerShell DSC. So what we’re going to do– let’s close this down– is we’re going to configure two things. We’re going to create a DSC configuration, which is the definition of all the things we want to enforce. And the node is the systems that we want to manage. So I’ve already got one configuration deployed, which is a web server configuration, and it’s managing a running virtual machine that’s called STOPME.
Don’t worry about the name. It’s a strange reason why it has that name. We’re going to add a second configuration that does the same thing and add the node that it’s going to manage. So to do that, let’s take a look at, very briefly, our DSC definition. So here’s the configuration that we actually want to enforce. Now, to do this, to build this configuration, first of all, you’ve got to obviously how to use DSC. We’re not going to cover how to build DSC or the specifics of how it works. But this is a very simple configuration that instals Chocolatey, instals a web server, and then creates a firewall rule to allow inbound traffic to the web server.
The Chocolatey module is what instals Chocolatey, and the xNetworking is what gives you the xFirewall resource that lets you configure the firewall rules. To help you write this, you’re going to write this in something like PowerShell ISE locally. You’d actually want to download those packages.
So we can use the find-package commandlet to find those packages and than actually instal the package on the system.
I forget the commandlet for importing the package.
Oh, what am I thinking? get-package.
That’ll actually add the package to the system and that’ll actually make it available to us. And we’ll do the same thing for the Chocolatey package, as well. And then that way, we can import those packages as DSC resources. Now, I make a habit of– you notice the version because these come from the PowerShell gallery. They can be changed from time to time. So we’ve actually got a version number, and I like to, when I build my DSC scripts, I do include the version number of any packages referencing. So that way, if it fails for some reason down the road, I can quickly check to see if the definition that I have matches the version number of the package.
One thing that was interesting is that I downloaded this as a sample, just a sample DSC configuration I found on the internet, and it was based on an earlier version of the networking package. And so for example, group was actually called GroupName. And so when I initially installed it, it was failing. You’ll see this in some of the history that I’ll show you. So I had to look at the documentation, figure out that, OK, a few things had changed. Update it, and everything worked great. So once that’s ready, we can actually go ahead and save this. I’ll Save this as, and we’ll call this one AzureDSC_Config2, just to keep it different.
And we’re now ready to import that definition into AzureAutomation. So what we’re going to do is bring up this definition, this PowerShell file, as a DSC configuration. So I’ll come into my DSC Configurations, click Add configuration, and just browse to that file.
So AzureDSC_Config2. Click Open. Gives it a name, which is isWebServer. I’m actually going to go back very quickly and again, just to keep these things nice and separate, we’re just going to update it. So I’m going to call this isWebServer2. Call the node webServer2. And this will just help us keep it separate from the one that we already did. So I have this configuration.
Config2, isWebServer2, and we’ll click OK on that. And so that’s going to go ahead and actually import that definition.
And so we can click on it. We can see that it’s being imported, and everything looks OK. The next step is to actually compile it. Now, compiling it takes a couple of minutes. But what it will actually do is compile this into the appropriate [INAUDIBLE] object that we can then go actually apply to a server. So this is now queued. It’s going to go compile in the background. And the compilation generally doesn’t take that long, but because it gets queued, you might have to wait a few minutes. While that’s queued, let’s take a look at the one I did earlier. So I did this one a couple of hours ago.
And you can see that my initial couple of compilation jobs actually failed. And if we look at some of the output you get, you can start to see why it failed. So this one had an exception. And it said, hey, I couldn’t find the module xNetworking. Reason for that? I hadn’t imported the module yet. So I hadn’t gone to the assets and added the module. So that’s the first error. The second error was that it couldn’t find– for example, here, The member DisplayGroup is not valid. I had mentioned that I had to actually modify, because of package changes, this Group value. When I initially found the sample on the internet, it was from a couple of years ago.
It was called DisplayGroup. And so this error tells me that, hey, something’s changed. At that point, I had to go in and look at the documentation for the package and see that, OK, some of these parameters have actually gotten updated. And so DisplayGroup became DisplayName, and then Enabled went from status enabled or disabled to Enabled = True, False. So there were two little things I had to adjust.
And so after working through those errors, it compiled and everything was OK. So let’s go back to our module that we just uploaded.
And we’re going to see, that compilation is now running. That’ll take just a couple of minutes and that package will be ready to go.
All right. So that’s now completed and it was successful. That took just a couple of minutes to complete. So now what we’re going to do is– well, we can see that this configuration is available. What we’re going to do is assign this isWebServer2 configuration to a virtual machine, and it’s going to make sure that what we’ve defined as part of that desired state configuration script is what’s actually implemented on our website server. So to do that, we’re going to come back here to our DSC Nodes. And we’re going to add an Azure virtual machine.
Select our virtual machine. And I’ve got one here that’s called DSCMe. We’re just going to click on that one. And then we need to configure some registration data. So the configuration we want to apply, isWebServer2. We’re going to apply it every 30 minutes. We’re going to make sure it’s validated every 15 minutes. We’re going to ApplyAndAutoCorrect. So in the case of ApplyAndAutoCorrect, if it finds that something doesn’t match the desired configuration, it’s actually going to make a change. Allow reboots if needed. And if it reboots, ContinueConfiguration. So we’ll click OK, and then click Create to create this node registration. The process of doing this node registration takes a little while. It’s got to instal the DSC virtual machine extension.
It’s got to initially go into the virtual machine, then make any configuration changes that it needs. So we’re going to let that run in the background. While that’s running, let’s take a look at the virtual machine that I already applied this to. And I’ve given it some time to run already. So let’s click on STOPME. And we can see that its configuration applied here is called isWebServer. And you can see that it’s been checking this configuration roughly every 15 minutes.
And if we click on one of these, here’s
one that happened at 9:13. We can see that, at the time this was checked, this machine was considered compliant. If we look at the first one down here, the first time it was run, you can see it’s compliant here, as well. And the reason that all these are going to list compliant is because this registration enforces it to actually be changed. So every time it runs, if it finds an issue, it’ll actually go in and fix it. And if we take a look at that virtual machine–
I’m going to switch to our RDP session of that VM– you can see that it’s created the Chocolatey directory, instal the tools. And then, as well, if we quickly look in Server Manager, you’ll see that this machine has IIS installed. And so both of those activities were implemented by that DSC provider. If I go ahead and either remove IIS or delete this folder, the next time the DSC consistency check runs, it’s going to fix those errors. It’s going to reinstall IIS or re-add that directory with the appropriate files to it. So if we look at our jobs, let’s see how this guy is doing over here. So this guy is still running.
It takes a little bit of time the initial time you do it, probably 5 or 10 minutes in my experience. So we’ll leave that running in the background. So that’s the basics of how you can actually use DSC simply and easily to apply desired state configuration to virtual machines that are running in Azure using Azure Automation.
In the previous step, we discussed Automation DSC and in this step, we will view a demo.
DSC Configuration Files
DSC configurations are PowerShell scripts that define a special type of function. Review this simple configuration.
The Configuration block is the outermost script block. In this case, the name of the configuration is LabConfig. Notice the curly brackets to define the block
There can be one or more Node blocks. These define the nodes (computers and VMs) that you are configuring. In this example, the node targets a computer called WebServer.
Lastly, there can be one or more resource blocks. This is where the configuration sets the properties for the resources. In this case, there is one resource block called WindowsFeature. Notice the parameters that are defined.
Note: You can create the configuration in any editor, such as the PowerShell ISE. Save the file as a PowerShell script with a ps1 file type
Import and Compile
After you create your DSC configuration file, you must import the file and compile it to the DSC pull server. Compiling will create the MOF file.
Note: If you prefer, you can use the PowerShell Start-AzureRmAutomationDscCompilationJob to compile the configuration file.
Registering DSC Nodes
After your configuration is in place, you select the Azure virtual machines or on-premises virtual machines that you would like to onboard:
For each machine, you need to configure the registration data
Monitoring DSC Jobs
Each time that Azure Automation DSC performs a consistency check on a managed node, the node sends a status report back to the pull server. You can view these reports on the blade for that node.
Notice that you can also Unregister the node and Assign it a different configuration.
In our next step, we will complete our second CloudSwyft Hands-On Lab focusing on standardising environments.
This article is from the online course:
Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline
Created by
This article is from the free online
Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
