In this example we will be splitting clusters into primary and secondary nodes.
Having a way to not take down both sides of a HA cluster is a basic requirement for sysadmins, but can be tricky to express in configuration management.
There are multiple ways to gather this info.
Your cluster software knows it - usually it'd be right in the configuration.
You might have a strict naming convention, i.e. one that makes all even systems a cluster primary and all odd ones a secondary. That doesn't have a high benefit on a technical level, but is very easy to 'hash' in a human brain, meaning you can easily identify those nodes in a list, no matter if it contains 10 or 1000 cluster pairs.
Your CMDB might also know it. If it was designed to help you, this information might be found there.
I'll go with an easy example, we use the naming convention and split using regex for odd (primary) and even (secondary) systems.
We can already do this inside rudder using dynamic groups, but for the sake of example I'm now pushing this info from outside Rudder using the API.
(This could be an awk oneliner, but even after so many years it doesn't come freely for my brain. Please look at the example instead of the tuning opportunities :-) )
If you look at the "Properties" page of the node information, you will find this information has been added, meaning Rudder's internal LDAP backend is now aware of this additional information.
Accordingly, we can now start matching on this information.
To catch all nodes that have the cluster property add all -> select test for is defined
To catch all primary nodes -> select test for Name=Value and set it to (in the righthand field) cluster-role=primary
As easy as that.
One Caveat: Pushing a single attribute via API does not trigger a dynamic group update on it's own. For performance reasons you should either trigger an update after adding a bulk of settings or wait out the next update.
If you suppose you have some non-shitty, structured infrastructure database...
- A python-readable excel file
- A json or yml juggernaut
- A real CMDB
- Or even some kind of shell script...
Then you'll be able to use this feature to let Rudder know about your org's intents for a system. On a process level, this is miles away from having a hardcoded list of systems. Instead you'd assign an "application" property to each system, telling Rudder about the main use for this systems.
I happily use this to set up one-application-per service environments, which allows for easy decommissioning and separates misbehaving applications to protect the innocent.
- Server is used by department A
- Server's application admins are from team C