Variables
This section addresses some advanced or discouraged usages of variables, or implementation details that can be relevant for debugging or integration purpose. If you want to learn about how variables are defined and used in Rudder, see Variables.
Technical implementation of Node properties
On the server, one or more properties files are written for each node in the
/var/rudder/share/<uuid>/rules/cfengine-community/properties.d/
directory.
This directory is then copied to each node by the agent with all other policy files.
In the agent, properties are made available in the node.<namespace>
container that contains the values.
Those values are read from
/var/rudder/cfengine-community/inputs/properties/*.json
. All files are taken
in order and override the previous ones - the last one wins.
The agent searches for optional properties files /var/rudder/local/properties.d/*.json
, and will define variables
or override existing properties.
Each file must contain at least 2 levels of JSON content, the first level is the namespace level and the second level is the key level.
The namespace name must be an ASCII name that doesn’t start with and must
match the following regex:
[a-zA-Z0-9][a-zA-Z0-9]*
For example:
{ "properties": { "datacenter": "Paris", "environment": "production", "customer": "Normation" } }
The merge is a first level merge done at the namespace level. This means that:
-
a key in a namespace is fully overridden by the same key in the same namespace in a later file.
-
a key in a namespace is never overridden by the same key in a different namespace
-
a key that is overridden never retains original data even if it is a data container itself
The result key is available in the node.<namespace>
data variable. A usage
example:
${node.properties[datacenter]}
To get the original data (for debug only) there is the
properties.property_<fileid>
variable. A usage example:
${properties.property__var_rudder_cfengine_community_inputs_properties_d_properties_json[properties][datacenter]}
← Man pages Plugin format →