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 / Desired State Configuration in DevOps

Desired State Configuration in DevOps

.
View transcript
17.5
Hello, and welcome back to module 2. In this module, we’re going to start off by learning a little bit about DSC. And I promised you in the last module that we were going to spend a lot of time discovering what DSC means in concept, and then working our way through implementation in actual automation using DSC. So back here to deliver on that promise. This is a concept video. I’m going to spend 5, 10 minutes with you talking about DSC, why it’s required, what are its benefits, and what is the real problem that DSC solves that has traditionally always been a gap. No great concept video is complete without a story of evolution, and evolution it is.
58.8
Well, we started with Windows NT, which kind of felt like the server for masses era, where servers were being created to reach the broader audience. There wasn’t really any automation. The only way to automate anything was writing some VBS or some DOS-based batch files. From that era, we promoted ourselves into an enterprise era where PowerShell got introduced into the mix, and you could do some level of automation by scripting using PowerShell to create a solution that would do something, and then quickly do that activity across multiple servers. You still didn’t really have the concepts of remoting in place, so you still had to manage your data centre yourself.
109.2
Then, with the events of Windows Server 2008 and Windows Server 2012, really came the era of data centres, where PowerShell had reached a certain level of maturity. You could use PowerShell to remotely administer servers, and you really had the power of cmdlets and modules, and it was also the introduction of desired state configuration. What this era really allowed you to do is– allowed you to do is use PowerShell for automation, but meaningful structured automation. And because PowerShell had reached a level of maturity, it got a huge ecosystem around it, an ecosystem which was vibrant. Not open source yet, though. And the era that we’re in now, the era of Windows Server 2016 and Nano Server is the cloud era.
159.6
The PowerShell is absolutely ready for it, and it’s ready, built ground up again, keeping devops at the centre of it. With PowerShell today, you have desired state configuration. You have a testing framework called tester which allows you to unit test your PowerShell scripts. You have an embedded package manager. So no more do you have to go and hunt for modules that you need to instal. It just offers that capability right from within the console. You have got code analysis using Script Analyzer. You’ve got support with Visual Studio Code, which means you can write PowerShell backed by Git repositories, unit test them, CI them, CD them. PowerShell have classes as well now, so you could do your structured programming against them.
207.3
PowerShell now also has security, which is referred to as JEA, Just Enough Administration, and it’s improved audit logs as well. You’ve got a PowerShell Gallery, massive Gallery open source support, and cross-platform support. A cross-platform support is huge. You could run your PowerShell scripts not only on Windows but on Mac and Linux as well. Kind of feels that PowerShell is ready. It’s gone through its evolution, and it’s ready for prime time. So PowerShell has been in play for a very long time. And as the PowerShell framework itself has evolved, the style of writing PowerShell has had to evolve along with it.
248.4
And because the OS has evolved as well, if you bring the three together, you’re kind of heading in a great space there. Now, the screen on the left side has an imperative syntax, and the one on the right has a declarative syntax. The imperative syntax is, if you look at it, kind of assuming an early state of where the script is running, as in the base state, and then the script is really building on top from there. So if the base changes, the script is bound to fail. So, for example, we are checking whether ASP.NET–
287.9
we’re checking whether the web server feature is enabled or not. And then, if it’s not enabled, then go and instal it. But if it’s enabled, then don’t instal it. Then you have to manage your try-catch block. So what if the execution fails? You kind of need to handle it within your catch block. If you run the script again, is it going to perform in a consistent way? Maybe, maybe not. For example, at the bottom there, you’re creating a website. If it already exists, how is the script going to handle it? It becomes very tedious to manage implementation or automation in this syntax. On the right side is the declarative syntax, where you’re leveraging the capabilities of the OS.
327.1
Rather than script what you want, you tell the OS what you need. And the OS is capable of looking at the current state of the OS and working out what it would take to get to the desired state. And in the process of that, behind the scenes, it creates the imperative script that it needs in order to bridge that gap. For example, I’m demanding that there is IIS setup. I’m demanding that ASP.NET is set up. I’m demanding that a website exists there. So if the website already exists there, then the OS just verifies that it exists and has the same variables that I’ve called out here.
366.3
If any of these variables are missing, it will bridge the gap by creating the imperative script to perform that action. And the OS is able to do it because the OS has what’s called an LCM. An LCM is a Local Configuration Manager, which takes the instructions and does the heavy lifting behind the scenes to bridge that gap. No surprise, the syntax on the left is helping us arrive at what I called earlier desired state configuration. This is– the concept desired state manager– management– desired state manager– DSC– sorry– Desired State Configuration is not just a Microsoft concept. It’s a concept that’s been there out in the industry. PowerShell with DSC helps you achieve it in the Microsoft stack.
412.4
So moving into the next slide here, we’re saying what is really desired state configuration? When I say desired state configuration, I mean what is PowerShell DSC? No surprise, PowerShell DSC is really an extension to PowerShell. It is not a new framework of any kind. You don’t have to go off and learn a new language. What that means is the cmdlets that you’ve been using for years, you continue using them in a declarative syntax now. That’s the only change. Let the OS deal with the underpinning of figuring out how it needs to update the target. What it also does is it leverages the OS to help achieve the configuration you need.
449.6
So, in summary, as long as you can understand these three points, that’s PowerShell DSC for you. We could just call it the end of module, but we won’t because we have to get through some demos as well. And why is desired state configuration important? Well, desired state configuration is important because it prevents server configuration drift. You could just tell the server this is the desired state I want you to have, and the server just manages its state so that it’s always to that state.
477.2
So, for example, if you wanted to roll out an update of a Windows feature across all the servers you had, for Telnet, for example– that’s a Windows feature– you don’t need to programme it, keeping in mind what the base state of each of the servers is. You would just create a declarative script which says your demand is that there’s this Windows feature enabled. And as you roll that out, it’s enabled across every server. What it also does is it takes away the configuration from the implementation.
506.3
And what that really means is if I am trying to run a software that depends on a web server, then the logic to deploy the software is separate from me provisioning a web server or a server that has the web server role enabled on it. Now, this part of the equation, I can easily tackle with the desired state script. So the software deployment doesn’t need to worry about it. And that segregation of duties makes it really easy to administer, makes it really easy to manage, and troubleshoot, and recover from failures as well. Because, for example, if your server goes down, then setting up– standing up a new web server role using the automation you have is easier.
547.1
But if that responsibility was partially shared by the script that was trying to deploy the software, then you run into all sorts of conflict. It helps you think about continuous in deployment because it’s a desired state. If you run the script once or twice, it’s not going to change the state. It’s just going to keep the current state. So you become brave about continuously rolling that script out again and again, and helps you think about the continuous deployment mode. A DSC script can be run on-prem, can be run in the cloud, can be run in other cloud platforms as well, and it would just work in the same way.
580.8
So it’s knowing one technology and being able to use it across cloud platforms. And, topmost for me, it kind of helps you leverage your existing PowerShell scripts. It’s not having to go and learn a new framework. It’s just building on it on an existing framework.

In this step, you’re going to learn about the concept of Desired State Configuration (DSC), why DSC is required, and its benefits.

The Evolution of DSC

Windows PowerShell was understood as a scripting language to help administrators automate routine jobs. PowerShell quickly gained ground, and today most products are accompanied by a PowerShell module to enable product administration via scripts.

Scripting traditionally relies on a start state, followed by a list of instructions to achieve an end state. The biggest drawback to this approach is that when the start state changes, the scripts tend to break. For example, when you create a script to install a web application on a server, the script assumes that the server will have Internet Information Services (IIS) preinstalled. If the target server does not have IIS, the script fails. The script could fail even if a different version of IIS is installed. This makes scripts very fragile and unreliable.

What is DSC?

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

In Windows Server 2008 R2, Microsoft shipped an add-on to PowerShell called Desired State Configuration (DSC). DSC allows you to describe your environment’s desired state with a simple declarative syntax that has been introduced into the PowerShell language and then distributed to each target node in your environment. This solves the problem of configuration drift by either correcting it or reporting it. Without adding complicated logic to your script, you can make and deploy incremental changes to your configuration over time without fear of putting your systems in a bad state.

The Benefits of DSC

The DevOps way of working demands getting software out to end-users more frequently. Continuous delivery of software relies heavily on automated provisioning of infrastructure. While the traditional way of provisioning infrastructure with declarative scripts gives you an automated process, it significantly reduces the predictability in dealing with change.

DSC can add significant value to your release pipeline. With on-premises or infrastructure as a service (IaaS) applications, DSC is an excellent choice to help control the environment configuration and support your deployment scenarios. The benefits of DSC include:

  • DSC provides idempotency, meaning that the desired state will be reached by applying the entire configuration, regardless of the current state.
  • You can spin up and tear down known versions of your environments.
  • You can avoid troublesome issues because of environmental differences between development and production
  • You can express the application environment-specific dependencies in code and carry them along in version control.

What DSC is not

DSC is not meant to be used for every scenario. If you’re deploying Azure platform as a service (PaaS) resources, it’s recommended that you use Azure Resource Manager to get the virtual machines (VMs) started and the networking configured. This is not something that DSC is designed to do. Once the VMs are running, you can use DSC to get the local configuration the way you want it and ensure that the configuration elements you care about don’t change.

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