Revision 30c7a866
Added by François ARMAND almost 7 years ago
| 00_introduction/20_key_features.txt | ||
|---|---|---|
|
[[key-features]]
|
||
|
=== Key Features
|
||
|
|
||
|
==== Os independent target configuration state definition
|
||
|
|
||
|
// image::./images/core_techniques.png[Standard Technique Library]
|
||
|
|
||
|
TODO
|
||
|
|
||
|
==== Centralize and aggregate real configuration state
|
||
|
==== 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
|
||
|
[TODO]) so that it provides generic, abstract, OS independant primitives to the
|
||
|
user who can:
|
||
|
|
||
|
image::./images/core_techniques.png["Standard Technique Library", float="right"]
|
||
|
|
||
|
* 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 Regestry,
|
||
|
* 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 todo_link[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.
|
||
|
|
||
|
image::./images/introduction/general_behavior_workflow.png[Define target, check, report, remediate]
|
||
|
|
||
|
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.
|
||
|
|
||
|
image::./images/introduction/rules_compliance.png[Rules compliance reporting]
|
||
|
|
||
|
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.
|
||
|
|
||
|
image::./images/introduction/rule_compliance_details.png[Fine grained reporting on configuration components]
|
||
|
|
||
|
|
||
|
==== Automatic inventory
|
||
|
|
||
|
TODO
|
||
|
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).
|
||
|
|
||
|
These informations are available in Rudder configuration data base and can be
|
||
|
used to defined coniguration 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 throught Rudder APIs (see link[TOTO]).
|
||
|
|
||
|
==== REST API
|
||
|
|
||
|
TODO
|
||
|
All Rudder commands are available throught an exhaustive REST API. That API is
|
||
|
http://www.rudder-project.org/rudder-api-doc/[fully documented online] and can
|
||
|
be used to todo_link[quickly and smoothly integrate Rudder with you 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.
|
||
|
|
||
|
image::./images/introduction/audit_trace.png[Trace events and display changes]
|
||
|
|
||
|
All changes can be forced to go through a peer review or validation step and
|
||
|
so be part of a conformity process.
|
||
|
|
||
|
image::./images/introduction/change_request.png[Change Request]
|
||
|
|
||
|
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 link_toward_thir_party_integration[an existing
|
||
|
plugin or a dedicated synchronisation tool].
|
||
|
|
||
|
==== Centralized authentication (LDAP, Active Directory, plugins)
|
||
|
|
||
|
TODO
|
||
|
Rudder can use enterprise directories (LDAP, Active Directory)
|
||
|
or be connected to an SSO to manage users authentication.
|
||
|
|
||
|
Moreover, Rudder authentication layer is plugable and can be extended to other
|
||
|
authentication protocol link_to_plugins[like Radius or SPNEGO with plugins].
|
||
|
|
||
|
==== Extensibilty
|
||
|
|
||
|
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 extremelly 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.
|
||
|
|
||
|
Module are atomic tasks, that can be extremelly simple (for example, check the
|
||
|
existence of a file, create an user or a group, update a software package) or
|
||
|
more complexe (for example, import JSON data from a REST API).
|
||
|
For information, the following image provides a NON-exhaustive list of
|
||
|
available modules:
|
||
|
|
||
|
image::./images/introduction/generic_methods_list.png[Non exhaustive list of generic methods]
|
||
|
|
||
|
These generic, unitary modules can be used to build new higher level,
|
||
|
OS independent, parametrizable configuration modules. By combining these module,
|
||
|
you are able to manage any configuration and build advanced configuration
|
||
|
policies for your IT services:
|
||
|
|
||
|
image::./images/introduction/rule_directive_generic_method_stack.png[Build your own configuration, matching your requirements]
|
||
|
|
||
|
image::./images/introduction/ncf_language.png[high level definition language]
|
||
|
The unitary configuration module can be configured thanks to a high level
|
||
|
programming language:
|
||
|
|
||
|
image::./images/introduction/technique_editor_overview.png[Graphical Technique Editor - the simplest way to build new configuration]
|
||
|
image::./images/introduction/ncf_language.png[high level definition 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
|
||
|
drag'n'drop. Of course, you can configure each unitary module to use data from
|
||
|
a node and behave specifically on each one.
|
||
|
|
||
|
image::./images/introduction/technique_editor_overview.png[Graphical Technique Editor - the simplest way to build new configuration]
|
||
|
|
||
Also available in: Unified diff
Fixes #10681: Complete documentation introduction