In a few weeks, we will be releasing RUDDER 5, a new major version built around the needs of those who use RUDDER on a daily basis, following an in-depth analysis of our current users to reach a better understanding of their needs.
—
Growth vs improvement: rationalization as a solution
Since RUDDER was created in 2011, the RUDDER roadmap has been driven by a dual goal:
- Performance: to improve the key features used by all of our users in order to reinforce RUDDER’s reputation as an efficient and reliable tool.
- Versatility: to add new features to cover more and more different use cases.
As more and more new users have adopted RUDDER and shared details of how they use it, the number of features dedicated to relatively rare use cases has increased, causing the software to become overly complex with features that ultimately interest only a small subset of users.
Our new release, Version 5, streamlines RUDDER’s structure to better balance these two priorities.
Some much-requested optimizations
RUDDER 5 continues to optimize and build on the improvements made in previous minor versions from 4.1 to 4.3, as well as further advancing the tool’s power and ease of use by improving existing features:
Localized validation workflow
One of RUDDER’s main goals has always been to combine the greatest possible accessibility with the power of infrastructure as-code, with features such as the management interface, the ready-to-use rule library, the Technique Editor, and the abstraction of differences in implementation between different OSs.
However, giving the ability to propagate changes across an entire production infrastructure in a few clicks will not help make IT more reliable if we are not constantly thinking about balancing this accessibility with features to manage these changes, and to maintain control. Examples of these features include the audit mode, which makes it possible to simulate changes without modifying the configurations in order to anticipate their impact, and the validation workflow, that requires another user to review any changes before deployment (those of you who use “pull requests” on Github will already be familiar with the benefits of peer review).
In RUDDER 5, this validation workflow is improved, and can now be applied to one or more targeted groups of machines only, for example only to production servers leaving unrestricted access to the development platform, instead of to all the nodes managed by the RUDDER servers. This updated feature makes RUDDER better adapted to the human environments for which it was designed, i.e. the multidisciplinary and multi-level teams that naturally occur in large-scale IT departments.
New advanced reporting
RUDDER’s compliance check was initially designed to show the current state of application of configurations at a given point in time.
Advanced reporting allows you to log compliance data to see how it’s changing over time using custom dashboards. These entirely customizable dashboards (from the time period over which to show the analysis, to the group of machines or configuration rules in question) can be exported as a PDF report to prove compliance to an external auditor, or to a client or their superiors, without having to conduct a manual inspection.
This feature gets a new look in version 5 with a brand new interface.
External authentication
IT teams in well-established companies often use a directory-based user management system (AD, LDAP, etc.) to manage large numbers of users. This feature, designed for larger companies, allows for user authentication using information from an external source such as LDAP or RADIUS, directly within the RUDDER web interface.
Branding
When RUDDER is deployed on a large infrastructure, it is common to have several RUDDER servers, each managing different environments (production/QA/dev, different sites, etc.). To make life easier for administrators, but above all to avoid confusion between different servers (which is all the more likely if they contain similar configurations), it is important to be able to distinguish them visually, at a single glance, within the RUDDER interface, anywhere in the navigation menu.
The branding feature, by adding a color coding system and a short description to each page, addresses this small but not insignificant problem.
Access rights (per action)
This feature gives you the option of having a separate API token for each RUDDER user, and adds precise ACL support for system tokens (of the same kind as user rights, with read/write limitation on different items). Everything is configurable from the web interface. This makes it possible to accurately trace and log each RUDDER user’s access to the configuration (including via the API), and to finely restrict the rights given to system API tokens (not linked to a user) for higher security and a better separation of privileges.
Integration
- Centreon
Monitoring and configuration management are two key functions of maintaining your infrastructure in operating condition. Centreon is a commonly used open source monitoring tool. The integration of Centreon within RUDDER automatically and immediately adds any machines accepted by RUDDER into Centreon. In addition, RUDDER’s configuration policies include a new method that can automatically associate a monitoring template for a configured application to a machine. - Zabbix
Zabbix is another widely used open source monitoring solution. This integration works in a similar way to Centreon. - iTop
iTop is a frequently used open source CMDB. RUDDER’s integration with iTop allows you to synchronize data between the CMDB and RUDDER. In particular, it makes it possible to synchronize both configuration rules and parts of machine’s inventories to iTop. - Vault
Vault is a storage and secrecy management tool (passwords, keys, etc.). This Vault integration makes it possible to use data from a Vault server for configuration policies, thus avoiding storing them on the RUDDER server and allowing access only to the relevant machines. - Slack [beta]
RUDDER produces a stream of changes from various agents connected to a server, centralizing all the actions and errors that take place. RUDDER’s new integration with Slack makes it possible to select certain events (belonging to a particular rule and/or group of machines), and to generate corresponding messages on Slack.
Reworking our documentation: centralised resources and new guides
The most attention-worthy addition found in this latest version, may not actually be inside RUDDER itself!
In fact, the RUDDER team has addressed a request expressed time and time again by current users during exchanges over which improvements to add as a priority: more complete documentation with a real getting started guide, specific use cases as examples, and a more intuitive structure.
This is now a reality thanks to docs.rudder.io, a platform designed as to act as a real user resource hub that centralizes both the RUDDER documentation and the API documentation, the bugtracker, changelogs, ways to participate in the RUDDER community, etc.
Common features for everyone’s basic needs – plugins for additional requirements
With each new version comes many new features, and RUDDER 5 is no exception to this rule. However, some in-depth thinking led us to update the way we incorporate these new features into the software.
The initial RUDDER model consisting of a single software block which includes all features, thus imposing a greater and greater complexity on all of our users, has reached its limits. We have now reached a sufficient understanding of the domain, its challenges, and the way RUDDER is used, to make us realize that this all-in-one model is not, or is no longer, the best suited.
This is why the first goal of RUDDER 5 was to bring the primary uses of RUDDER back to the center of the solution by separating the features by:
- Simplifying the essential RUDDER experience, to contain only the basic functions that are widely used by all,
- Leaving the choice to install more advanced features using individual plugins, each addressing a precise need.
In this way, RUDDER 5 can offer a more natural and spontaneous experience of auditing and automating infrastructure.
A proven model
We are far from being the inventors of this plugin system, WordPress and Jenkins are just two examples of other tools that are built around this model. Imagine if these solutions were based on the same model that RUDDER has used up to now, and that every WordPress or Jenkins environment systematically embedded all of the existing plugins; navigating and using these tools would be both ridiculous and inconvenient, and adoption by new users would be seriously compromised. Of course, RUDDER has not yet got the same quantity of features as these examples, but we wanted to find a solution to this issue now, before it dramatically impacted RUDDER’s ease of use!
So how to decide what is essential and what is not? The rule is that the basic RUDDER experience must contain all the features that are used by over 80% of our users. The remaining 20% of features provide solutions that are no less important, only less common. Any feature that the majority of users don’t know of, are not familiar with, think they will never use, or want to immediately disable, serves a better purpose if isolated in the form of a plugin.
An in-depth reorganization of the RUDDER project
This rationalization of RUDDER is part of a broader project aimed at promoting a faster development environment.
Indeed, our old economic model was exclusively centered around services (training, remote expertise, on-site intervention, production support, etc.) despite the fact that we now know that the main expectation of users is for product evolutions. Given this past economic model, turning away from services would have jeopardized the financial stability of the RUDDER team. So in order to allow the RUDDER team to devote more of their efforts to developing the product, it is first necessary to change the economic model of the project so that it rewards this move towards development, thus ensuring both the survival and the growth of the project.
So how do we decide which model to use to realize this simple but modular experience based on a plugin ecosystem, while at the same time ensuring the financial stability of the project?
In the past, RUDDER has managed to stand out from other configuration management solutions thanks to its Technique Editor, the drag & drop editor which makes it possible to easily address any unforeseen needs in the ready-to-use techniques library. Since this model has been proven to work well within RUDDER, it also has its place in the conception of RUDDER’s new structure. This is the reason why we chose to isolate the more sophisticated features into individual plugins, so that each specific need is resolved by the advanced feature dedicated to it.
Commercially speaking, access to all of the plugin packages is available as part of a subscription offer, in a similar way to Red Hat, which also includes publisher support, and an extended maintenance of versions for up to 24 months. This model has the advantage of being fairer: until now, a small number of companies financed extended maintenance while all other users benefited from it. From now on this extended maintenance will be reserved only for subscribers.
Subscribers will also be the only ones to receive advanced feature plugins as ready-to-use RPKG packages. The motto here is simply that those who finance the product should be the ones who benefit the most.
Here is an overview of the changes (to see the full details of the subscription offer: https://rudder.io/en/subscription/):
| Before | RUDDER 5 | |
| MANAGEMENT INTERFACE | ||
| Full configuration web UI | ✔ | ✔ |
| Drag & drop Technique Editor | ✔ | ✔ |
| Web interface customization (logo, color) | ✗ | Optional |
| AUDIT AND COMPLIANCE | ||
| “Audit only” mode (no changes) | ✔ | ✔ |
| Compliance by node and rules (instant) | ✔ | ✔ |
| Aggregation & compliance history | ✗ | Optional |
| Validation workflow (change requests) | Obligatory → global application only |
Optional → configurable by groupe |
| INTEGRATION | ||
| Plugin manager (RPKG packages) | ✔ | ✔ |
| Detailed inventory of nodes (extensible) | ✔ | ✔ |
| Scale-out relay servers (for network zone isolation and scalability) | Optional | Optional→ new protocol in 5.x |
| High availability best practices | ✗ | Optional |
| Import of node properties from external HTTP sources | Optional | Optional |
| External authentication (LDAP, AD) | Obligatory → LDAP et AD → not within the interface |
Optional → LDAP, AD and RADIUS → configurable within the web interface |
| Web access rights management (by type of action) | Obligatory | Optional (in 5.x) |
| Access rights display in web interface | ✗ | Optional |
| Full API access rights management | ✗ | Optional |
| Centreon integration | ✗ | Optional |
| Zabbix integration | ✗ | Optional |
| Vault integration | ✗ | Optional |
| iTop integration | Optional – beta | Optional |
| GLPI integration | ✗ | Optional |
| Slack integration | ✗ | Optional – beta |
Conclusion
RUDDER 5, puts the focus back on its most used features (and their documentation!) By improving them and putting them back at the centre of the RUDDER experience. The guarantee, for those who do not have the constraints of large teams and/or large and critical productions, is to maintain a simple infrastructure automation experience, whose key features are not polluted by rarely-used options intended for use-cases that are potentially never encountered. For IT teams with specific and less common problems, the plugin system can address individual issues individually through a model that has the dual advantage of being both fairer, and of promoting the RUDDER team’s development efforts.
And now?
While waiting for the release of RUDDER 5, you can familiarize yourself with RUDDER 4.3 by:
- Signing up to an online demo to discover the interface (this will not allow you to apply configuration)
- Using the Vagrant-based demonstration environment to easily test the configuration application in a real-world environment
- Installing RUDDER with the provided packages and following the installation documentation
- Asking any questions directly to RUDDER’s development team and participating in the RUDDER community via email, IRC or Twitter.
