OS independent target configuration state definition
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, AIX - see the list of supported Operating Systems for Nodes) so that it provides generic, abstract, OS independent primitives to the user who can:
install software in OS native packaging system (RPM on RHEL, Windows software components, or even direct install from sources),
configure OS level parameters and services like logs, DNS, NTP, etc.
create and maintain user accounts (administrator accesses, developers) and groups with a transparent support of OS specific requirements on file format, password hashes algorithms, etc for any supported OS.
build an hardened system by configuring and then continuously verifying the correct set-up of security rules like file system rights, file integrity checking, etc.
configure middleware by files (for example in Linux world, whatever the file format, and be it from a template or by only specifying enforcement of some configuration parameters) or thanks to the Windows Registry,
manage service start-up at boot time and ensure that a service is correctly running at any time, starting it up again if needed.
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.
Centralize and aggregate real configuration states
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.
Audit trace and Change Requests
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.
Centralized authentication (LDAP, Active Directory, OpenID Connect)
By default, Rudder uses a dedicated configuration file to manage user credentials. Thanks to the ref:plugins:auth-backends.adoc[authentication backend 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.
← What is Rudder? Use cases →