This post was written by Kristopher Bash, Senior Program Manager
This blog post is #11 in a series of technical posts about running and managing Linux and FreeBSD in your on-premises datacenter. Other posts in the series are here:
Running Linux and FreeBSD as a guest operating system on Hyper-V
- Microsoft Loves Linux Deep Dive #1: Introduction to Linux and FreeBSD on Hyper-V
- Microsoft Loves Linux Deep Dive #2: Linux and FreeBSD Integration Services Core Features
- Microsoft Loves Linux Deep Dive #3: Linux Dynamic Memory and Live Backup
- Microsoft Loves Linux Deep Dive #4: Linux Network Features and Performance
- Microsoft Loves Linux Deep Dive #5: FreeBSD Overview and Status
Managing Linux and UNIX using System Center and PowerShell DSC
- Microsoft Loves Linux Deep Dive #6: Linux and UNIX Systems Management Overview
- Microsoft Loves Linux Deep Dive #7: Managing Linux in System Center Virtual Machine Manager
- Microsoft Loves Linux Deep Dive #8: Linux and UNIX Monitoring with Operations Manager
- Microsoft Loves Linux Deep Dive #9: Monitoring Open Source Middleware
- Microsoft Loves Linux Deep Dive #10: Managing the Software Configuration on Linux and UNIX Servers
- Microsoft Loves Linux Deep Dive #11: Linux Configuration Management with PowerShell DSC
- Microsoft Loves Linux Deep Dive #12: Summary of Running and Managing Linux and FreeBSD in Your Datacenter
Linux configuration management with PowerShell DSC
PowerShell Desired State Configuration (DSC) is a declarative configuration platform first delivered with Windows Server 2012 R2. Did you know that DSC can also be used to configure Linux servers? PowerShell DSC for Linux was initially released in May of 2015. The current version (1.1) is available in compiled Linux packages (rpm/deb) and as source code. Using a simple, human-readable, declarative syntax, configurations can be authored to control files and directories, manage installed software, configure services, and manage many more aspects of a server’s configuration. The state of the configured instances can be tested against the desired state, and any drift in configuration can be automatically remediated.
DSC is a powerful and flexible platform for managing configurations of Windows and Linux computers. Some key use cases for DSC for Linux include:
- Virtual Machine (VM) Provisioning: deploy the DSC for Linux agent in your virtual machine or Azure Resource Manager (ARM) template and automate initial configuration settings and application installation with a pre-defined MOF or through a pull server or Azure Automation DSC (more on that later in this post).
- Settings compliance: define configurations corresponding to enforced settings policies, ensure the configurations are kept in compliance, and test/report on state.
- DevOps: define your server configurations as code, and deploy server configurations along with the corresponding applications.
- Continuous Deployment: define the configuration for an application and automatically deploy new releases of an application to all servers in a farm. This is made simple through the capability of the nxFile resource to keep a file or directory in sync with a source file or directory as well as the nxArchive resource’s ability to sync an archive file with an extracted directory
Working with DSC for Linux starts with authoring the configuration. While you can use any number of tools or text editors to create the configuration document (a MOF document), authoring the configuration in PowerShell dramatically simplifies the experience through a Domain Specific Language. With PowerShell authoring, you can use the DSL declarative syntax (i.e. property = value) with IntelliSense and schema validation. With PowerShell authoring of configurations, you can accept configuration properties as parameters and use the richness of the PowerShell language to automate the configuration document creation.
As an example, a simple configuration to ensure that relevant MariaDB packages and the daemon are configured on CentOS or RHEL 7 might look like:
Once the configuration MOF is produced, it must be staged and deployed. Deployment can be done in two ways: pushing the configuration to the Linux server (in PowerShell, this is done with the Start-DSCConfiguration cmdlet) or staging the configuration MOF on a pull server to be downloaded by the DSC agent on the target Linux server.
In the final “make it so” phase, the DSC agent on the target Linux server parses the configuration, tests whether the machine’s current configuration is in compliance with the desired configuration, and enacts any configuration changes needed to enable the desired configuration. Once the configuration is applied, the compliance state can be tested locally (by running TestDscConfiguration.py) or remotely with PowerShell (Test-DscConfiguration) Likewise, details about the current configuration can be retrieved locally (GetDscConfiguration.py) or remotely with PowerShell (Get-DSCConfiguration). If you are using a Pull Server or Azure Automation DSC, the configuration compliance state is also reported to the server. By setting the Meta Configuration ConfigurationMode option for the DSC agent, you can control the agent’s behavior for remediating configuration drift. If the ConfigurationMode is set to ApplyAndAutoCorrect, DSC agent will periodically test whether the assigned configuration is in compliance, and if it is not, reapply the specific configuration settings that are out of compliance to ensure the desired state is maintained. The agent can also be placed in a mode where it only reports on configuration drift without taking any actions.
The DSC for Linux software implements a provider model and comprises two key components: The Local Configuration Manager (LCM) and the resources. The LCM is the core DSC agent and must be installed on each Linux server that you are managing with DSC. It processes configuration documents and dispatches instances and operations to the resources. Resources are the providers for the DSC agent and implement configuration management for specific areas, such as files, daemons, packages, and so forth. Resources implement the configuration actions to test, get, and set the declared configuration and also provide a layer of abstraction. This is particularly valuable on Linux, where different distributions may have alternate ways of performing similar configurations. These distribution differences are hidden behind the common parameters for the resource, so you don’t have to worry about remembering the different configuration file syntax for things like network adapters, firewalls, or daemons that may vary between versions or distributions. The DSC for Linux package includes a set of built-in resources, and additional resource modules can be installed. Resource modules are .zip files containing the resource schema and executables. These can be downloaded, as needed, from the pull server, or installed locally by running InstallModule.py.
DSC for Linux Architectural Diagram
The DSC for Linux Local Configuration Manager is a Common Information Model (CIM) provider, registered with an Open Management Infrastructure (OMI) server. OMI is an open source, lightweight CIM server and has been discussed in previous blog posts in this series pertaining to System Center Operations Manager and Configuration Manager agents for UNIX and Linux. The resources are also registered as providers with OMI, but they are invoked by the LCM provider, and not the OMI server directly. Only native (i.e. written in C or C++) resources are currently supported by OMI and DSC for Linux. However, the built-in and downloadable resources presently available for DSC for Linux are authored in Python. This is facilitated through the use of a thin C++ layer for each resource that uses sockets to communicate with a client Python layer.
Configurations can be pushed to DSC for Linux over the Web Services Management (WSMan) protocol (with a PowerShell CIM session or any other WSMan client). In this model, the WSMan connection is made to the OMI server. Alternatively, configurations can be pulled from a DSC pull server, either your own pull server or the Azure Automation DSC service. In the pull model, a cron job periodically triggers the LCM to check for changed configurations on the Pull server and check that the current configuration is correctly applied. For pull operations, the ubiquitous cURL https client is used to connect to the web service.
The DSC for Linux software includes 10 built-In resources:
• nxArchive – synchronize a .tar/.zip with a directory
• nxFile – manage files & directories
• nxFileLine – manage lines within a file
• nxPackage – manage installed packages
• nxUser – manage (local) user accounts
• nxGroup – manage user groups
• nxScript – extensible provider with user-defined Get/Set/Test scripts
• nxEnvironment – control defined environment variables
• nxSshAuthorizedKeys – manage ssh (public) keys for users
Two additional resource modules are currently available on the PowerShell Gallery: nxComputerManagement and nxNetworking. These modules provide four additional resources:
• nxComputer – manage hostname, timezone, DNS domain name
• nxIPAddress – manage IPv4/IPv6 configuration for an interface
• nxDNSServerAddress –manage DNS server addresses (DNS client)
• nxFirewall – manage firewall rules for 6 common Linux firewalls
Azure Automation DSC
Azure Automation DSC is a cloud service built on the DSC pull server model that greatly simplifies centralized management of Windows and Linux configuration (with DSC configurations) and provides rich reporting on configuration compliance for managed servers. Registering a Linux server with Azure Automation DSC requires simply installing the DSC for Linux package (and OMI) and running a single command. Within the Azure portal, or with Azure PowerShell, you can upload DSC configurations, compile them to MOF documents, and assign the MOFs to registered servers. Once a configuration has been assigned, you can see the current and historical compliance status for the managed systems:
Azure DSC for Linux
An Azure VM extension is also available for DSC for Linux. This VM extension will install DSC for Linux and apply the configuration (MOF) that you specify as well as any resource modules you supply. The extension is deployable through Azure CLI or Azure PowerShell, can be embedded in your ARM templates, and is a great way to automate initial configuration of your Linux VMs or provisioning of applications in Azure IaaS. For full documentation of the DSC for Linux extension, visit the extension’s GitHub repo. To recap: Azure Automation DSC provides a solution for ongoing configuration management of your Linux servers (no matter where they run) with drift remediation and reporting, while the Azure VM Extension enables easy deployment of the DSC for Linux software itself and one-time configuration setting for Azure IaaS virtual machines.
PowerShell Desired State Configuration is a flexible declarative configuration tool that can be used in many scenarios to automate and manage server configurations. PowerShell DSC for Linux extends this capability to Linux and enables common configuration management for your heterogeneous data centers and clouds. To get started with DSC for Linux, check out the Release Notes, and documentation.
Next week, this blog series will wrap up with a summary of Microsoft’s offerings for running and managing Linux and UNIX in your on-premises datacenter, putting all the pieces in context and looking at some future directions.