Key Features

Rudder is able to adapt to complex process and only do the minimal required work so that the server converges to the desired state, and so whatever was the starting state point. Rudder works as a GPS would, adapting the path to your destination depending of the path you actually took. This process is much more resilient to changes than a step by step, procedural description of the commands to execute.

Rudder is natively integrated with the supported OS (Linux, Windows - see the list of supported Operating Systems for Nodes) so that it provides generic, abstract, OS independent primitives to the user who can:

The simple primitives can be simply mixed and extended to provide solutions for any and all of your unique use cases of software stacks, deployments, IT services or configuration that can’t be natively supported.

The nominal working mode of Rudder is a continuous verification mode, which makes Rudder manage the whole application life cycle and check that configurations remain valid at any time.

Rudder can also continuously check that rules are valid and proactively correct any drift from the desired application state when needed. A graphical reporting displays what happened and when.

Rudder can notify the ops team about a drift from the desired configuration state. Understanding what the problem is is made simpler by the graphical reporting which allows to drill down toward the technical root cause and see in a blink where the drift comes from.

Rudder automatically does a technical, detailed inventory of the servers on which the agent is installed. That inventory contains hardware information (like server kind, CPU, RAM, hard drives, etc), networks information (network interface and configuration), OS level data (OS type and name, version and patch level, etc) and software information (installed software with their versions).

This information are available in Rudder configuration data base and can be used to defined configuration rule targets. Typically, some configurations are linked to the kind of server (physical or virtual), the quantity of RAM available, the version of an OS library which contains a security bug, etc.

All of these data are also available through Rudder APIs.

All Rudder commands are available through an exhaustive REST API. That API is fully documented online and can be used to quickly and smoothly integrate Rudder with your existing infrastructure.

Any change done thanks to Rudder in your infrastructure is automatically recorded in an Audit Log which allows a full traceability of all changes. That feature also allows rollbacks of the recorded change.

All changes can be forced to go through a peer review or validation step and so be part of a conformity process.

The validation process can be externalized to third party ticketing system, like a CMDB, so that it can integrated into an existing company workflow. This integration is done thanks to an existing plugin or a dedicated synchronisation tool.

By default, Rudder uses a dedicated configuration file to manage user credentials. Thanks to the authentication backends plugin, Rudder can use a centralized authentication provider, like enterprise directories (LDAP, Active Directory) or an SSO via OpenID Connect (OIDC).

Rudder has a built-in library of common software components and configuration. But of course, your infrastructure is not limited to that handful of standard components and that’s why Rudder was made to be extremely simply extended so that it can manage services, process or software specific to your company and your workflows.

To achieve that goal, Rudder provided a big set of OS independent and generic, unitary modules. Rudder agent is able to translate these abstract modules to native OS specific commands and configurations.

Modules are atomic tasks, that can be extremely simple (for example, check the existence of a file, create an user or a group, update a software package) or more complex (for example, import JSON data from a REST API). For information, the following image provides a NON-exhaustive list of available modules:

These generic, unitary modules can be used to build new higher level, OS independent, parameterizable configuration modules. By combining these module, you are able to manage any configuration and build advanced configuration policies for your IT services:

The unitary configuration modules can be configured thanks to a high level programming language:

But the natural, common strategy to use them is with the "provided graphical editor" which allows to use all the same modules, but with a web UI and with drag’n’drop. Of course, you can configure each unitary module to use data from a node and behave specifically on each one.