[Autogenerated] now let's look at Azure automation dsc
or desired state configuration again,
this is some repeat from what we did in the previous lesson but I'm
going to extend on that discussion and flesh it out.
DsC is meant to rectify the problem of configuration
drift which occurs when someone,
one of your colleagues I know not you makes a change to a
production system without recording those changes and without
ensuring parity between staging and production.
In other words,
configuration drift is an unauthorized change and we want to rectify that.
So we've got a capability built into PowerShell and
it's been a few years now anyway,
so dsC or desired state configurations of mature technology
built into PowerShell and built into PowerShell course so we
can use dsC across operating systems,
Mac os Linux and Windows down as a reminder.
101 deal only with Windows.
So we're assuming Windows PowerShell 5.1.
Here's the high level view,
we've got this library of open source resources that define what it is that
you're looking to do with your desired state configuration?
Do you want to ensure that the iis web server is always installed on a machine?
Do you need to enforce environment variables or registry settings?
If there's third party products that you need to monitor.
I almost guarantee you at GitHub you'll find a.
Dsc resource that either Microsoft a third party or independent
software vendor or a community member has created.
So you want to install those dsc resources on your administrator,
pc as well as your target node as well as your poll server.
You define your desired state for your target systems in a power shell
script file using what's called configuration syntax.
We're using ordinary garden variety PowerShell here and
we're using declare it of syntax.
Were just basically going to describe the desired state of that system and let
the PowerShell dsc local configuration manager make it So now there's two ways
to do dsC in Azure where when we use Azure automation dsC this is the poll
server model where we centrally stage our configuration script and our DSC
resources on the pole server.
Those config scripts are compiled into moff files or managed object
format files and this is the file format that's required on the
target node to actually do the processing the local configuration
manager is the client piece of dsc And that's responsible for
checking with the pole server.
Is there a configuration I need to apply if so, how am I doing the application?
What if the machine comes out of compliance,
do I just want to audit that or do I actually want to auto
correct to bring the node back into compliance,
you see?
So this is a very high level perspective of dSC and the other option,
if you don't want to do pull you can directly push a configuration to a node.
But because we're concerned with at scale Systems administration
and we want to use Azure automation that's using a highly available
poll server architecture where again the benefit is we don't have
to manage those poll servers.
They're managed for us.
Let's take a look at a declarative configuration script.
If you've built PowerShell functions, it's quite a similar syntax,
not identical by any means.
We use the configuration keyword rather than the function keyword,
you'll do import dsc resources to pull in any resources that
are going to be referenced inside the script.
You've got your no declaration and for each node you have these
blocks where you pull from your dsc resources and then each
resource has its own particular properties.
In this case we're pulling from X web administration to
ensure that the iis web server is present as is the
graphical web management console.
Pretty straightforward declared of syntax and depending upon how we
configure the L C M or the local configuration manager,
if we do apply an auto correct.
This means that somebody again not you.
One of your colleagues might uninstall IIs on a machine mistakenly.
Well the next time the L C M does an evaluation if
it's configured to auto correct?
It will go ahead and re install the IIS feature in order to
bring the machine back into compliance.
This is one of the value propositions of desired state
configuration and what's cool about it is that it's free.
It's built right into PowerShell so it's not like a chef or a puppet that
you would need an enterprise license for necessarily you can use desired
state configuration with or without Azure automation to deploy the agents
we've been talking about in this course,
particularly the connected machine agent for Azure arc enabled servers
or log analytics agent as far as that goes here,
notice that we can use parameters and you can use
parameters with any dsc configuration to make the
configuration more portable and flexible.
You also can target multiple nodes,
check the exercise files for some reference links on dsc and of course
check the Pluralsight library because we have plenty of dSC training and
basically all we're doing in this script file is automating the
installation of the connected machine agent and we would also need to make
sure that we provide the metadata to make sure that we're coming in that is
that the machine that we want to be an arc enabled server is represented in
our Azure subscription in the appropriate resource group and so on and so
forth.
I give you all of these script and sample files in the course files as well by the way,