Configuration management at scale, whether to align machines to organizational policy or to enable continuous deployment, can be a tedious and error-prone process. As an organization’s infrastructure footprint grows, so do its difficulties in this area, with common questions arising such as:
- How do I ensure all of my machines are matching their intended configuration and remain in the correct state?
- How do I prevent machine configuration from drifting from the desired state, due to changes made by people, process, and programs?
- How do I ensure new machines match the configuration of existing machines in the same role?
- How do I seamlessly set a new desired configuration for all or a subset of my machines?
- How do I limit access to who can change the desired configuration of machines or machine roles?
- How do I orchestrate configuration changes without impacting uptime?
- How do I do all of the above, consistently, across on-premises machines and those in public clouds, and across Windows and Linux?
Azure Automation Desired State Configuration (DSC) provides a highly available configuration management solution to help you with the above issues. Using Automation DSC, you can consistently deploy, reliably monitor, and automatically update the desired state of all your IT resources, at scale from the cloud. Automation DSC can align machine configuration with specific state across physical and virtual machines, Windows or Linux, in the cloud or on-premises, enabling continuous deployment and IT services delivery with consistent control. Managing rapid changes across heterogeneous environments and multiple clouds becomes simpler, giving you more flexibility in meeting the needs of your business.
But how does it work? Automation DSC builds on top of the fundamentals introduced in PowerShell Desired State Configuration (DSC) to provide an even easier configuration management experience. 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. These DSC items are placed on the Automation DSC pull server so that target nodes (physical and virtual machines) in the cloud or on-premises can pick them up, automatically conform to the desired state they specify, and report back to Automation DSC on their compliance.
For example, let’s say you’re relying on Microsoft’s Operations Management Suite (OMS) for log analytics and monitoring. Someone in this situation probably wants to ensure that all of their machines, wherever they may be, have the OMS agent installed, and that the agent is constantly running. Anything less would mean a loss of insight and control over your cloud and datacenter environments.
Using Automation DSC, ensuring machines match an intended desired state is incredibly simple. First, you write and import into Automation DSC a PowerShell DSC Configuration specifying the desired state that machines should match. In the OMS agent example above, the DSC Configuration would look something like this:
Configuration MyConfiguration {
# TODO: add your OMS workspace onboarding values here
$OmsWorkspaceId = "FILL ME IN"
$OmsWorkspaceKey = "FILL ME IN"
$OIPackageLocalPath = "C:MMASetup-AMD64.exe"
Import-DscResource -ModuleName xPSDesiredStateConfiguration
Node OMSServer {
#Service state
Service OIService {
Name = "HealthService"
State = "Running"
DependsOn = "[Package]OI"
}
xRemoteFile OIPackage {
Uri = "https://opsinsight.blob.core.windows.net/publicfiles/MMASetup-AMD64.exe"
DestinationPath = $OIPackageLocalPath
}
#Application
Package OI {
Ensure = "Present"
Path = $OIPackageLocalPath
Name = "Microsoft Monitoring Agent"
ProductId = "C318816D-D471-4F18-999A-7662DB906BC0"
Arguments = '/C:"setup.exe /qn ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=' + $OmsWorkspaceId + ' OPINSIGHTS_WORKSPACE_KEY=' + $OmsWorkspaceKey + ' AcceptEndUserLicenseAgreement=1"'
DependsOn = "[xRemoteFile]OIPackage"
}
}
}
Since this configuration depends on a non-native PowerShell DSC resource (xRemoteFile), you’ll need to also import the PowerShell module containing that DSC resource into Automation DSC as well. Then you simply compile the configuration in the Automation service, and assign the generated node configuration to your machines. They will pull this node configuration and either continually autocorrect to comply with the desired state, or simply report on compliance against the desired state, depending on the configuration mode you’ve set up for each machine. You can see this compliance information “all up” in the Automation DSC dashboard:
Making sure the OMS agent is installed/running is just one way you could use Automation DSC. There are, of course, many other “desired states” you may want to enforce or report compliance against, such as security policy, firewall rules, or the presence of the latest version of your application code.
Now that we’ve gone through the basics of Automation DSC, let’s talk about some of the new features of the service that we added as part of its recent generally available release. The first thing you’ll notice is the new, rich reporting interface we provide to help you determine exactly what resources on the machine are or are not matching the desired state. Previously, clicking into a DSC report for a machine in the Automation DSC UI would show something like this:
Now, if your machines are running WMF 5 RTM, we show the same information in a much friendlier user interface:
But there’s another lesser-known reporting feature of Automation DSC that we recently introduced – the support for machines to use Automation DSC solely for compliance reporting. It’s now possible to onboard machines so that they solely report compliance information, like that in the screenshots above, to Automation DSC, but continue to receive their desired state from PowerShell DSC Configurations that are directly pushed to them from within the datacenter. This provides you the choice and flexibility to take advantage of Automation DSC’s rich reporting features in the cloud while still relying on PowerShell DSC Configurations on-premises in your datacenter.
Here’s an example of what a report-only machine looks like in Automation DSC. As you can see, it looks and works exactly like other managed machines, in terms of its reporting information. However, it has no node configuration assigned since none is being delivered by Automation DSC:
You can learn more about how to onboard your machines to Automation DSC, including in report-only mode, here.
Another interesting use case for Automation DSC is Azure Virtual Machine Scale Sets. VM Scale Sets let you deploy and manage multiple Azure VMs as a set and easily scale the set in or out depending on load. The benefit of this capability is that it allows you to reduce management overhead while still enabling the ability to scale up to meet performance needs and scale down to reduce costs when performance needs are reduced. However, users of VM Scale Sets commonly wonder:
- How can I make sure machines in the scale set are identical, and stay identical, in configuration?
- How can I easily update the configuration of existing and yet-to-be-created machines in my scale set?
Automation DSC now gives you a very simple approach to this aspect of configuration management. Azure Virtual Machine Scale Sets can now be configured so that every machine in the set is automatically on-boarded for management by Automation DSC. If a configuration is updated in Automation DSC, all machines in the scale set will automatically conform to the new desired state, and whenever the scale set grows, any new VM instances will also conform to the desired state automatically. In addition, if any machine in the scale set somehow drifts from the desired state, it will be automatically corrected. And all this can be done without having to update and deploy Azure Resource Manager templates or remote into machines to set configuration. You can see an example ARM template that sets up a VM Scale Set that is managed by Automation DSC here.
As you can see, Automation DSC makes configuring machines on-premises and in the cloud, on Windows or Linux, simple. We hope you’ll give it a try, to reduce your own pain around managing configuration at scale.
Looking to learn more about Automation DSC? Check out the links below, or use this Azure Resource Manager template to quickly deploy a sample environment in Azure with a virtual machine preconfigured for management by Automation DSC.
Just getting started with Azure Automation? Learn about the service here, and follow Azure Automation on Twitter for the latest and greatest.
This blog post was originally published on the Microsoft Hybrid Cloud Management blog here. It has been slightly adapted for an Azure audience, since the service is usable by both Microsoft Azure and Microsoft Operations Management Suite customers.