<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 14/03/2017 à 10:35, Janos
Mattyasovszky a écrit :<br>
</div>
<blockquote
cite="mid:1tK_FElbtgtwwATKdSOplz_7kDeZbO2_qcHqto4IN-WkErjNO_PNJz6AY3FB-GEetlyrHF7b7GngCJCeqVoWOBaSHvYMdiY_hjZvFkaE4qo=@matya.eu"
type="cite">
<div>Hi dear Rudder Community, <br>
</div>
<div><br>
</div>
<div><u>The Challenge:</u><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div><u>Possible solutions:</u><br>
</div>
<div><i><br>
</i></div>
<div><i>-- Simple --</i><br>
</div>
<div>Ability to "sync" the policy of one Rudder Root server to
another Root Server (via API)<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
</blockquote>
<br>
The most difficult thing here, is to link rules and propagate
groups.<br>
A group that is on server A may not be on server B so synchronizing
rules between A and B means reapplying then to a different group.<br>
Synchronizing groups can be complex too, the definition of a group
in one environment may mean nothing in another one and will produce
empty groups.<br>
<br>
<blockquote
cite="mid:1tK_FElbtgtwwATKdSOplz_7kDeZbO2_qcHqto4IN-WkErjNO_PNJz6AY3FB-GEetlyrHF7b7GngCJCeqVoWOBaSHvYMdiY_hjZvFkaE4qo=@matya.eu"
type="cite">
<div><br>
</div>
<div><br>
</div>
<div><i>-- Advanced --</i><i><br>
</i></div>
<div>Have a new type of Rudder-Installation, like a Rudder Policy
Master<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
</blockquote>
<br>
It is a very interesting idea. You would have to rethink how
promises are generated and have a specific communication channel
between the servers.<br>
<br>
I think I would call it a virtual server more than a master server,
because it doesn't serve any promise. And I would not allow it to
create groups, since only the real servers know which nodes exists
an why. But it should be able to aggregate the information
(including groups) from other servers to have compliance details.<br>
<br>
<blockquote
cite="mid:1tK_FElbtgtwwATKdSOplz_7kDeZbO2_qcHqto4IN-WkErjNO_PNJz6AY3FB-GEetlyrHF7b7GngCJCeqVoWOBaSHvYMdiY_hjZvFkaE4qo=@matya.eu"
type="cite">
<div> </div>
<div><br>
</div>
<div>Here is a very imaginary example list of what would be seen
in Policy Master:<br>
</div>
<div><br>
</div>
<div>Test LAB | 250 nodes | overall compliance: 98.5% |
policy version: 15156 latest built | nodes up-to-date with
current policy<br>
</div>
<div>Test Staging | 300 nodes | overall compliance: 99.8% |
policy version: 15156 latest built | rollout in progress, 60%
done<br>
</div>
<div>Test Canary | 56 nodes | overall compliance: 99.5% |
policy version: 15156 latest building | nodes up-to-date with
previous policy<br>
</div>
<div>Prod AWS EAST | 1517 nodes | overall compliance: 99.6% |
policy version: 15154 outdated built | nodes up-to-date with
outdated policy<br>
</div>
<div>Prod AZURE EU | 3114 nodes | overall compliance: 99.3% |
policy version: 15154 outdated built | nodes up-to-date with
outdated policy <br>
</div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
<div>This could be coupled with the previous idea of having Rudder
commence of a not-all-at-once Rollout of the policy.<br>
</div>
<div><br>
</div>
<div>Thanks for reading, <br>
</div>
<div><br>
</div>
<div>Best Regards,<br>
</div>
<div class="protonmail_signature_block ">
<div class="protonmail_signature_block-user ">
<div>Janos Mattyasovszky<br>
</div>
</div>
<div class="protonmail_signature_block-proton
protonmail_signature_block-empty"><br>
</div>
</div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rudder-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rudder-dev@lists.rudder-project.org">rudder-dev@lists.rudder-project.org</a>
<a class="moz-txt-link-freetext" href="http://www.rudder-project.org/mailman/listinfo/rudder-dev">http://www.rudder-project.org/mailman/listinfo/rudder-dev</a>
</pre>
</blockquote>
<br>
<p><br>
</p>
<div class="moz-signature">-- <br>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<style type="text/css">
<!--
a.redlink:link { color: #1782E6; }
a.redlink:visited { color: #1782E6; }
.sig { font-family: 'Century Gothic', CenturyGothic, AppleGothic, sans-serif; font-size: small; }
.sigsmall { font-family: 'Century Gothic', CenturyGothic, AppleGothic, sans-serif; font-size: x-small; }
-->
</style>
<table border="0" cellpadding="0" cellspacing="2" width="380">
<tbody>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td colspan="2"><b><img alt="Logo Normation"
src="cid:part3.CC06D125.64D983A1@normation.com"
align="left" height="50" hspace="10" width="50"> <span
class="sig">Benoît Peccatte</span></b><br>
<span class="sig"><i>Architecte</i></span><br>
<span class="sig"><a class="redlink"
href="http://www.normation.com">Normation</a></span> </td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td colspan="2"><span class="sigsmall"><b>87, Rue de
Turbigo, 75003 Paris, France</b></span></td>
</tr>
<tr>
<td><span class="sigsmall">Phone:</span></td>
<td><span class="sigsmall">+33 (0)1 85 08 48 96</span></td>
</tr>
<tr>
<td colspan="2">
<hr> </td>
</tr>
</tbody>
</table>
</div>
</body>
</html>