[rudder-users] Link separate Rudder Installations

[Janos Mattyasovszky]

Hi dear Rudder Community,

The Challenge:
After a certain size or having different departments / security requirements, it might be a valid topic of having different teams managing a given subset of your servers. Currently a Role-Based separation is not implemented inside Rudder, and some cases it is also required to have physical separation. OTOH, from a top-level overview, you'd want to have the same base rules being applied to your machines (like security hardening and other standardization) and the best would be to get back an over-all compliance report of these basic rules.

We have currently the Relay-construct, which helps you to get around network / bandwidth limitations and helps a lot to balance the load/stress that many thousands of nodes would generate otherwise on one policy server. However, there is currently no proper way to connect stand alone Rudder Root servers to work together in a kind of master-slave role.

Possible solutions:


-- Simple --
Ability to "sync" the policy of one Rudder Root server to another Root Server (via API)

This would allow you to export all items used in the Rules via API and import it via the other Server's API. This would also enable you to have a Staging environment, where you develop and test your Rules outside anything important to you (sandbox/lab env), if you think you are ready, you put all your stuff over to a Staging environment, where you do an initial Rollout to a subset of your "more important" nodes, like some Real-Life test systems or Canary hosts, and if nothing breaks, you can use that well-defined set of rules to put that in your n*Prod environment.


-- Advanced --

Have a new type of Rudder-Installation, like a Rudder Policy Master

This brings in a whole new concept of managing Rules. It would mostly look like a "regular" WebGUI you use today, but you do not use this to connect end-nodes to, it can only hook up Rudder Root Servers as "Slave" servers. You could then use it to create Rules, Directives, Groups, but would not have any node-policy generated on. You would use it to define a base set of Rules, that would be signed and sync'ed to any slave root server, which would then use that (Dynamic groups would pick up any Server that is entitled to receive that Policy) to generate it's end-node Policy, maybe also in addition to any locally defined Policy. The "slave root servers" would then aggregate the "central Rules"-Related compliance and report it to the Policy Master, on which you'd have a similar report to what you currently have on a regular Rule, but that would be not based on per-node, but on "per-Root-Server" with focus on the policy being propagated.

Here is a very imaginary example list of what would be seen in Policy Master:

Test LAB | 250 nodes | overall compliance: 98.5% | policy version: 15156 latest built | nodes up-to-date with current policy
Test Staging | 300 nodes | overall compliance: 99.8% | policy version: 15156 latest built | rollout in progress, 60% done
Test Canary | 56 nodes | overall compliance: 99.5% | policy version: 15156 latest building | nodes up-to-date with previous policy
Prod AWS EAST | 1517 nodes | overall compliance: 99.6% | policy version: 15154 outdated built | nodes up-to-date with outdated policy
Prod AZURE EU | 3114 nodes | overall compliance: 99.3% | policy version: 15154 outdated built | nodes up-to-date with outdated policy

From this list you could see how to create different "failure domains" that can operate independently, but you could still have an overall control of the base policy, and then you could delegate like your Microsoft-Devs the control to the Azure-Enviroment, the other DevOps Team to the AWS env and so on, and you could test your policy stuff on Lab/Staging, and put it on the Canary Hosts (which would include one from each different environment) before it would be released for Production.

This could be coupled with the previous idea of having Rudder commence of a not-all-at-once Rollout of the policy.

Thanks for reading,

Best Regards,


Janos Mattyasovszky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-users/attachments/20170314/f7207c6e/attachment-0001.html>