The content below is taken from the original (Introduction to Azure Automation Desired State Configuration), to continue reading please visit the site. Remember to respect the Author & Copyright.
In today’s Ask the Admin, I’ll explain the ins and outs of Azure Automation Desired State Configuration.
Azure Automation Desired State Configuration (DSC) is composed of two key technologies: Azure Automation, a cloud service that’s been around for a couple of years, and PowerShell DSC, a declarative syntax based on PowerShell that allows system administrators to define device configuration.
Azure Automation
If you’re not already familiar with Azure Automation, it’s a management platform for automating and maintaining cloud resources using a PowerShell-based workflow engine (runbooks). Azure Automation can be used to automate and schedule routine tasks, such as starting and stopping virtual machines, restarting web services or doing anything that is supported by Azure PowerShell. And just like PowerShell, the platform is extensible, so in theory, any internet-connected service or platform can be managed.
For more information on Azure Automation, see Getting Started with Microsoft Azure Automation and How to Use Microsoft Azure Automation on the Petri IT Knowledgebase.
PowerShell DSC
PowerShell Desired State Configuration is similar to Puppet and Chef, and is used for configuring servers and preventing configuration drift. Rather than scripting a configuration, for instance install this component, set registry keys and then reboot the server, DSC uses a declarative syntax that defines how servers should be configured without specifying a list of tasks needed to achieve the result. It’s like Group Policy on steroids, allowing servers to be configured without specialist knowledge of how components should be installed.
For more information on DSC, see Why PowerShell’s Desired State Configuration Should Matter to You and Deploying a Desired State Configuration Web Host Using PowerShell on Petri.
Azure Automation DSC
One of the problems with DSC is that to be really useful, it requires some infrastructure, usually in the form of a pull server from which nodes retrieve configurations, and even then doesn’t scale well. That’s where Azure Automation DSC comes in. When you create an Azure Automation account, a DSC pull and reporting server are automatically configured from which your cloud or on premise Windows and Linux VMs (nodes) can get MOF files, meaning that you don’t need to have a VM running 24/7 for the purposes of DSC.
A key advantage of Azure Automation DSC is the cloud-based pull server that’s automatically deployed and managed by Microsoft, but there are also a host of other features. The service allows organizations to control who can access DSC configurations and assign them to nodes. Changes to configuration can also be tracked, recording when and how configurations are applied to nodes. There’s also a reporting server so you can check for VM compliance against your configurations.
It’s also possible to combine the use of Azure Automation runbooks and DSC. For example, runbooks can come in useful if you want to coordinate a process and configure VMs as part of a larger operation.
Pricing
Azure Automation DSC comes in Free and Basic tiers, and is charged according the number of nodes registered with the pull server. The free tier supports up to five nodes, after which you need to switch to the basic tier, which costs $6/month per node. Click here for more information on pricing.
Look out for more articles on Petri soon, where I’ll show you how to work with Azure Automation DSC.
The post Introduction to Azure Automation Desired State Configuration appeared first on Petri.
