Configuration Basics ​

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:

1. 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.conf file and a set of environment variables.
2. 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 bondy.conf file.
3. 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:

To learn more about Multi-tenancy security configuration check the WAMP and HTTP references.

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.

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 existence 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.

File Location ​

The default file location depends on the installation method you've used as shown in the following table.

The location can be overridden using the BONDY_ETC_DIR environment variable.

File Syntax ​

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).

Value Datatypes ​

The following are the set of acceptable datatypes used in the documentation.

Example ​

nodename = bondy@127.0.0.1
distributed_cookie = bondy
security.allow_anonymous_user = off

Default values ​

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).

Variable Substitution ​

Within the bondy.conf file you can use the following variables which Bondy will substitute before running.

• platform_etc_dir

The following is an example of how to use variable substitution.

broker_bridge.config_file = $(platform_etc_dir)/bb_conf.json

User environment variable substitution ​

If you want to use environment variables in the bondy.conf you have to rename the file to bondy.conf.template.

During startup, Bondy considers all files with suffix .template for OS variable substitution 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 ${VAR_NAME}.

Notice the BONDY_* variables mentioned above will always be used by Bondy.

Example ​

nodename = ${BONDY_NODENAME}
distributed_cookie = bondy
security.allow_anonymous_user = off
security.config_file = ${BONDY_SECURITY_CONF_FILE}

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.

Temporary changing Open File Limits ​

Most operating systems can check and change the open-files limit for the current shell session using the ulimit command.

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

Permanently changing Open File Limits ​

To change the limit on a system-wide, permanent basis read the following sections.

bondy soft nofile 65536
bondy hard nofile 200000

session required pam_limits.so

soft nofile 65536
hard nofile 200000

UseLogin yes

ulimit -a

systemctl show docker

/etc/sysconfig/docker

OPTIONS=" — default-ulimit nofile=1024:4096"

OPTIONS="--default-ulimit nofile=2000000:2000000"

sudo systemctl restart docker

$ docker run --ulimit nofile=2000000:2000000