To deal with increasingly complex infrastructure growth, reliability and security issues, the establishment of a continuous approach into IT automation tends to progressively become the obvious answer to these evolutions. This complexity results from the infrastructure manager struggle to handle a double heterogeneity : technlogy diversity and team members skill disparity.
However, to take advantage of all its benefits, automation can’t be confined to just one platform or just one part of the team : automation solution will deliver on its promises only when implemented to every operating systems in use and accessible for every person involved in their maintenance.ance.
This is why the ability to adapt to users -no matter what their specialization field or their skill level are- is one of the foundations of RUDDER’s original vision.
The most remarkable realization of this principle is the ability to use RUDDER with the same extend and the same granularity, whether it is through the web interface, the command line or the API. But this is not the only feature resulting from this will : the implementation discrepancies abstraction for the user regarding the operating system reminds as well this leitmotif. This particular point is the subject treated in this article.
So far, Microsoft Windows systems’ support by RUDDER needed a third agent, CFEngine Enterprise, edited by Notern.tech. This solution had limits :
- RUDDER’s developpers didn’t have access to the source code due to the property license of this third agent, therefore developments were more difficult, longer but also less optimised than those on open source platforms,
- The overcharge repercution of this third agent on IT departments was an obstacle to the solution integration on Windows systems.
In order to take these restrictions off Rudder we established a technical partnership with Microsoft France and developed a new RUDDER agent, using native technology Microsoft PowerShell Desired State Configuration (DSC).
What does it change for RUDDER users ?
Whether in the Web interface, the CLI or the API, everything works as usual : the configuration rules targeting Windows systems can are used in the same way as on Unix systems. The only difference with our previous Windows agent is that performances are far better thanks to the native technology we are now using.
The Windows support requires the installation of a plugin on the RUDDER server, that contains the configuration blocks (the 1.0 version provides 32 generic methods and 4 techniques, and this number will keep growing in the next releases) and the ability to generate configuration policies for Windows nodes.
On the managed nodes, like on Unix systems, an agent that will will apply the policies has to be installed. This agent is compatible with Windows 2008R2 and later, and requires the presence of (at least) PowerShell 4. The server-side plugin requires at least a RUDDER 4.2 server (released the 2017/09/28, see https://www.rudder-project.org/doc-4.2/install-server.html for the installation documentation).
From a user perspective, managing a Windows node is exactly the same as managing a Unix one. The only difference comes from the usage of different techniques in some cases, with some Windows-specific (like Windows Registry management) and Unix-specific (like Packages management) ones.
In the Technique Editor, the compatibility of the generic methods with the new agent is indicated through a small DSC icon on it. A filter on the methods list is also provided to easily create compatible techniques:
They allow creating techniques for Windows:
Compatible techniques are tagged with the same icon:
All or the available configuration blocks (techniques and methods) are compatible with both Audit and Enforce audit modes.
The agent CLI works like the Unix one, and the output is approximately the same:
Under the hood
The way the agent works is the same as the Linux and AIX one: after the user has defined the desired state, the agent will fetch its policies from the RUDDER server (using HTTPS) and locally check each item in the policy, fix it if necessary (if not in audit mode) and send a report to the server. Reports are for now sent using the syslog protocol (through Windows Event Logs). Inventory and agent execution are triggered using Windows Scheduled Tasks.
DSC (for Desired State Configuration) is a configuration management tool based on a declarative language integrated with Windows Powershell.
Inside the configuration policies, everything is defined using generic methods, that are the common ground between the Unix and Windows agent. The techniques compatible with Windows will directly use the generic methods with the Powershell/DSC implementation.
The plugin that is installed on the server contains internal configuration policies for RUDDER on Windows (also known as System Techniques), the compatible generic methods, as well as Windows-compatible techniques. It allows adding the logic for Windows policy generation, absent from the base version.
The Windows agent contains the inventory tool, the scripts to manage configuration policies, scheduled tasks, and the default configuration policy provided at installation.
Going further
To learn more about Rudder agent Windows systems management, you can:
- get in touch with Alexandre, +33 1 85 08 88 08 or at abr@normation.com
- see the agent inaction in the demo video
