Configuration concepts

A technique defines a set of operations and configurations to reach the desired behaviour. This includes the initial set-up, but also a regular check on the parameters, and automatic repairs (when possible).

All the techniques are built with the possibility to change only part of a service configuration: each parameter may be either active, either set on the "Don’t change" value, that will let the default values or in place. This allows for a progressive deployment of the configuration management.

Finally, the techniques will generate a set of reports which are sent to the Rudder Root Server, which will let you analyse the percentage of compliance of your policies, and soon, detailed reports on their application.

Techniques shipped with Rudder are presented in a library that you can reorganize in Configuration → Techniques. The library is organized in two parts: the available techniques, and the selection made by the user.

The standard library only provides the most common techniques. You can create new technique with the Technique Editor.

Rudder is built to continuously assess drift compared to defined policies, with or without auto-healing.

By auto-healing, we mean that optionally, Rudder can continuously enforce correct configuration over time, correcting the assessed drift so that your configuration converges towards desired states. This behavior is optional, and Rudder can only report drift without changing configuration. That policy enforce or audit mode can be configured by node, rule or directive (see policy mode documentation for more details).

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.

Compliance and drift from expected configurations are then reported with possibility to drill down in non-compliance issues to identify the root problem.

Of course, one can always correct a drift error by hand by updating configuration target and changing policy mode from "audit" to "enforce" mode.

As previously seen, in Rudder you define rules which target groups of nodes, and are composed of configuration directives.

A directive contains one or multiple sub-configuration elements which generates reports. For example, for a Sudoers directive, each user can be such an element.

Reports have states explaining what is the drift between the expected configuration and the actual configuration. Some states depends if the user choose to automatically enforce drift correction or if he chose to only reports on drift).

Finally, a node can get a global state if reports don’t come at expected frequency or for expected policy configuration version.

Below you will find all details about the possible states and their meaning with the actual compliance calculus method.

Checking that the node is correctly reporting, at correct frequency

At the node level, we are checking that the node is sending reports according to the expected frequency, and for the currently defined version of the configuration for it.

Based on this information, we get a

At directive level: checking for drift and auto-healing

Compliance calculus

Based on these facts, the compliance of a rule is calculated like this:

Number of nodes for which conformity is reached for every directive of the rule / Total number of nodes on which the rule has been applied

We will here explain what is the computation made during generation to decide which mode to apply to a directive on a node, based on the current settings.

The short rule is: Override wins, then Audit wins

For a given directive on a given node at a given time, we have three different policy mode settings:

The result is: