Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £29.99 £19.99. New subscribers only. T&Cs apply

Find out more
Home / IT & Computer Science / AWS / Microsoft Future Ready: DevOps Development, Implementation and Azure Automation / Automation DSC

Automation DSC

.
View transcript
17.2
Now that we understand why PowerShell and DSC is important and how it works, let’s spend a little bit of time looking at the architecture within DSC. So the DSC, Desired State Configuration, has two modes. One is push, one is pull. Now the names kind of define them quite well within themselves, but just to call out, a push mode is where you author a script and you push it to the server where you need the desired state configured. A pull is you author the script and send it to a central authority, and every node that needs that script will come to the central authority to get an update.
55.3
And this model really scales because I only create the script once, and I put it in the central authority. And Then every node– and node is what it’s called, right? The target machine– connects to the central repository to pull the updates that it needs to make sure that it’s aligned to the configuration that I had authored. The pull can be set up. The pull server can be set up by yourself. But then again, you know, we’re moving into this brave world where we don’t want to manage administration and automation tools ourselves. And that’s where Azure automation comes in handy because Azure automation hosts the DSC pull server for you.
92.7
So you don’t have to worry about setting up an HTTP, HTTPS end point, load balancing it, fault tolerancing it. It’s all built into the Azure Automation framework. Now this slide is really just to take you through the workflow of how a pull server works. Now we kind of talked about it but at a high level. This is the guts of how it works. And knowing this is useful because when things fail or they work as not so expected, then you at least have the inner knowledge of figuring out where the problem lies. So in this script here, you know, I’m authoring that the telnet Windows feature be enabled. It’s a configuration that I’m creating using PowerShell.
134.2
Once I have authored the script, I will send it to the central server, which is called the pull server. What the pull server does is it compiles this script, this configuration script, into two key outputs. One is MOF, and one is resource. Now MOF, if you’re coming from a .NET programming language background, it’s the IL. It’s the Intermediary Language, which means MOF is not just a Microsoft solution. MOF is a solution that all operating systems understand. As long as you can produce MOF, you can run MOF on any framework, any tool, any platform. And that’s exactly what the pull server is doing. It’s compiling your configuration script into MOF file. Any dependencies are captured as resources.
176.6
So all these nodes on the right that you see in the execution block have been registered with the pull server. So when they come to the pull server, they say, well, this is my current state. What is the target state? Let me validate. And if it finds that there’s been a drift, then it will take the updated configuration from the pull server, i.e. the MOF file and the resources, give it to LCM, the Local Configuration Manager on the OS. And the LCM will just queue a job for itself to figure out what the desired state is, what the current state is, and the kind of scripts it needs to create to bridge that gap. And that’s really it.
210
And that will just complete the whole workflow. Now the question that I get asked a lot is, OK, well, you showed this DSC script. It looks pretty straightforward. Are there any best practises when authoring DSC script? You know, when you start with DSC, you could just start creating basic scripts. But when you start to roll these scripts out at scale, you kind of need to think about best practises. Now the great thing is that the PowerShell DSC GitHub repository, the open source GitHub repository, has had over 100 [INAUDIBLE] and umpteen number of contributions from the open source community. And this is a great result of that.
248.7
They have a common page now which talks about all the best practises that are available. So let me just quickly flip over and show you the page and talk about or mention briefly some of the best practises. So here’s the DC resources– PowerShell, GitHub repository. And on the best practises page, you can see it’s been quite well categorised into what it relates to. So for example, avoid using hardcoded computer names. So if you are going to use a DSC script and it needs to be applied to multiple servers, then why not take a parameter as the input, which becomes the parameter to accept the computer name. So don’t hardcode it. Avoid empty catch blocks.
289.6
I’ve seen that a lot where people just want the script to run even when there is an exception. So they’ll create an empty catch block. The problem with this is if there’s a real problem or a failure that happens, well, you kind of eat the exception. So you never know why it failed. And there are plenty of examples on other good practises, best practises that you can follow when authoring DSC scripts. So I hope you found the concept video on DSC useful. It’s clear now why DSC is important, what it’s built on, the evolution, and why it’s set up to help you deliver DevOps better.

Now that you have an understanding of DSC, let’s explore the architecture and automation within DSC. This step is an introduction to using DSC frameworks and how automation DSC works, and will prepare you for implementing Automation DSC.

Using DSC Frameworks

Microsoft PowerShell DSC is one of many DSC frameworks and is one of the tools you can use in your DevOps solutions. Within Microsoft PowerShell DSC, you can use DSC in pull or push modes and use the declarative phase to control the server state.

The push mode is unidirectional and immediate. This means that the configuration is pushed to its intended targets, and those targets are configured. In pull mode, each pull client machine is configured to get its desired state configuration from the pull server.

The pull server is set up to host the DSC service, and it’s provisioned with the configurations and resources required by the pull clients. Each pull client has a scheduled task that performs periodic compliance checks on the node configuration.

Want to keep
learning?

This content is taken from
CloudSwyft Global Systems, Inc. online course,

Microsoft Future Ready: DevOps Development, Implementation and Azure Automation

View Course

configuration settings for client and server targets

When the event is triggered for the first time, it causes the Local Configuration Manager (LCM) on the pull client to validate the configuration. If the pull client is not configured as desired, the LCM makes a request to the pull server to get a given configuration. If that configuration exists on the pull server and it passes validation checks, the configuration is transmitted to the pull client where it is then executed by the LCM.

Controlling the desired state can be as simple as ensuring that a file or directory exists, or something more complex such as modifying the registry, stopping or starting services, or running scripts to deploy an application. You can do this repeatedly without error. You can also define your own DSC resources or leverage many built-in resources.

DSC Use Cases

The following are some example scenarios where you can use built-in DSC resources to configure and manage a set of target nodes in an automated way.

  • Enabling or disabling server roles and features.
  • Managing files and directories.
  • Starting, stopping, and managing processes and services.
  • Deploying new software or software updates.
  • Fixing a configuration that has drifted away from the desired state.
  • Managing updates.

How does Automation DSC work?

Automation DSC allows you to author and manage PowerShell DSC Configurations, import DSC Resources, and generate DSC Node Configurations (MOF documents), all in the cloud.

automation DSC and configurations with nodes

To implement Automation DSC, you would:

  1. Create a Windows PowerShell script with the configuration element.
  2. Upload the script to Azure Automation and compile the script into a Managed Object Format (MOF) file. The file is transferred to the DSC pull server.
  3. Define the nodes that will use the configuration.

In the next section, we’ll look at each step in Automation DSC in detail.

Join the discussion

Can you think of an everyday example of where Automation DSC is used? Share your ideas with the group.

Use the Discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to move on to the next step.

Want to keep learning?

This content is taken from CloudSwyft Global Systems, Inc. online course
Microsoft Future Ready: DevOps Development, Implementation and Azure Automation
View Course
See other articles from this course
This article is from the online course:

Microsoft Future Ready: DevOps Development, Implementation and Azure Automation

Created by
Join Now
This article is from the free online

Microsoft Future Ready: DevOps Development, Implementation and Azure Automation

Created by
Join Now
FutureLearn - Learning For Life

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.

Start Learning now

Register to receive updates

  • Create an account to receive our newsletter, course recommendations and promotions.

    Register for free