Learn about the Bondy runtime configuration, the Bondy configuration file, its syntax, variable replacement and the required OS-specific configuration.
The complete behaviour of Bondy is defined by the combination of 3 types of "configuration" data:
- Bondy node runtime configuration, which controls things like network listeners, availability of optional services, security defaults, clustering and load regulation. This is mostly static configuration done by modifying the
bondy.conffile and a set of environment variables.
- Multi-tenancy security configuration, which controls the definition of realms and its security including user identities, authentication and authorizacion policies, Same Sign-on and Single Sign-on. This is done dynamically by via the Admin API. However, it can also be configured via the
- RPC and Pub/Sub configuration, a.k.a Control Plane, which defines the available RPC procedures–their invocation policies e.g. load balancing–and PubSub subscriptions and their respective routing information. This is dynamic configured by clients and maintained in the Registry via WAMP.
The following diagram shows the scopes and mechanism for managing each configuration type:
This refence documentation covers only the Bondy node runtime configuration using environment variables and the
As opposed to other application networking options i.e. Service Mesh, in which services are configured using a proprietary API e.g. Istio APIs and YAML for Kubernetes resources, Bondy RPC and Pub/Sub configuration is entirely managed by WAMP.
Bondy environment variables
Bondy will use the following environment variables to configure the node identity and the paths it uses to store data.
|Name of the Bondy node.|
|Erlang distribute cookie to be used to connect a remote shell to a Bondy node|
|The directory where the ||See File Location section below|
|The directory where Bondy will store its embedded database. Check the relevant requirements in the Operating System Configuration section below|
|The directory where Bondy will write any defined logs|
|The directly where Bondy will store any temporary data|
In previous version of Bondy these options where configured using the
bondy.conf file but that introduced certain issues with the configuration system.
The Bondy configuration file
Bondy configuration file, named
bondy.conf, is used to set a wide variety of node runtime configuration options.
During node startup, Bondy will check the existance of the file, parse it and validate its contents. In case of a syntax or validation error, Bondy will stop printing the reason to standard output.
If a configuration file is not found at the expected location, Bondy will create one using default values.
When deploying a Bondy cluster it is vital that the same
bondy.conf file is used with all nodes.
The default file location depends on the installation method you've used as shown in the following table.
|Installation method||Default Location|
|Official Docker image|
The location can be overriden using the
BONDY_ETC_DIR environment variable.
The file uses a sysctl-like syntax that looks like this:
# comment key = value
Note that blank lines are ignored, and whitespace before and after a key or value is ignored, although a value can contain whitespace within. Lines which begin with a
# are considered comments and ignored.
The documentation for each key defines the acceptable datatype and format for each value and the default value (if any).
The following are the set of acceptable datatypes used in the documentation.
|Any string. Although each token might add specific formatting rules via the documentation|
|Work pretty much like duration but with three differences.|
The units are
If not unit is specified, the value defaults to bytes
You can only use one unit.
Lowercase units (i.e.
|Equivalent to a boolean value|
|Durations are fixed intervals of time, the largest unit of which will be a one week. Anything larger will have to be expressed in terms of weeks, since larger units (month, year) are of variable duration. The following units are supported:|
You can use any combination of these.
|The IP datatype exists currently as an IP/Port combo|
|file and directory are effectively strings. In the future they could allow for included validators like valid path and exists. Some files may need to exist, some may not. some may need to be writable.|
For every option not provided by your configuration, Bondy might define a default value (check the default value for each key in each Configuration Reference section).
How options and their defaults are documented
Take the following snippet of the Node section as an example.
It defines the token
nodename which takes a
string value and defaults to
firstname.lastname@example.org. Notice the documentation will further specify which strings are acceptable.
Start a Bondy node without providing a configuration file and inspect the one generated by Bondy once the node has started. Bondy would have created the file using the default values. You can copy this file and use it as template to make your modifications.
When you are done copy your modified file to the expected location and start Bondy again.
bondy.conf file you can use the following variables which Bondy will substitute before running.
The following is an example of how to use variable substitution.
User environment variable substitution
If you want to use environment variables in the
bondy.conf you have to rename the file to
During startup, Bondy considers all files with suffix
.template for OS variable sustitution and if successful results in a new file of the same name stripped of the
.template suffix and where all environment variables have been replaced.
The syntax for environment variables is
BONDY_* variables mentioned above will always be used by Bondy.
Operating System Configuration
Configuring Open File Limits
Bondy can accumulate a large number of open file handles during operation. The creation of numerous data files is normal, and the storage backend performs periodic merges of data file collections to avoid accumulating file handles.
To accommodate this you should increase the open files limit on your system.
We recommend setting a soft limit of
65536 and a hard limit of
Temporary changing Open File Limits
Most operating systems can check and change the open-files limit for the current shell session using the
Start by checking the current open file limit values with:
ulimit -Hn # Hard limit ulimit -Sn # Soft limit
Set the limit by using:
ulimit -n 200000
The above configuration persists only for the duration of your shell session. To make the change permanent read the following section.
Permanently changing Open File Limits
To change the limit on a system-wide, permanent basis read the following sections.