Deploying Axual

Instance, cluster and client level services

Before to dive into the details of the Axual CLI (Command Line Interface) and its configuration, it is good to explain the different levels we see for the platform services. When we talk about services that together form Axual, we use the terms Instance level, Cluster level, Client level and Management Level regularly. The different levels form either a logical of physical segregation that is either needed for security or availability purposes. You will also find the separation of these levels in the configuration files and the Axual CLI commands.

Instance Level

Every tenant has at least 1 instance, e.g. "tenant-prod" in which all instance level services are running. Typically, tenants have 2 instances, DTA (Development, Test, Acceptance) and PROD (Production). Instance level services are:

  • Discovery API

  • Distribution

  • Schema registry

  • Instance API

Cluster Level

All services that are bound to a cluster are considered cluster level services. Those services are not related to any tenant or instance. Cluster level services are:

  • Broker

  • Cluster API

  • Cluster Browse

  • Distributor

  • Exhibitor

Client Level

Client services like Connect are not bound to specific cluster they are running on, they behave like true Kafka Clients. Those service will be connected to other Kafka Clusters than the one they’re running on as they get the configuration from Discovery API. Client services are:

  • REST Proxy

  • Connect

Management Level

Management Level services are on top of all other services Cluster Level, Instance Level and Client Level . Management level services themselves are not related to any tenant or any instance and are used to manage Cluster Level and Instance Level services. Management services are:

  • Management UI

  • Management API

  • Keycloak (If applicable)

  • Stream Browse

  • Operation Manager

Performing a deployment of Axual

All services of Axual Platform have been dockerized. As for any generic Docker container, deployments poses some complexity on passing the correct environmental variables and network / persistence setup (port mapping, volume mapping). The Axual CLI (previously known as Platform Deploy) is designed to bootstrap the configuration for a particular setup, and deploy the platform as a whole.

For any deployment scenario the following components are needed:

  • Deployment configuration: this includes not only configuration parameters of the different components, but also files that are needed by the different components, such as .jks files (keystores). See Setting up configuration

  • Deployment functionality: this is covered by the Using Axual CLI

Deploying in different scenarios using axual-deploy

Setting up configuration

In order to perform a deployment:

  1. a host needs to be prepared for deployment, meaning it needs a NODENAME, CONFDIR and access to the Axual CLI, see Preparing a host for deployment

  2. configuration for all the Instance, Cluster and Client services needs to be prepared, see Configuring a Deployment

Preparing a host for deployment

Deployment using Axual CLI is done on a per-host basis. By default, it will look for a file, in the home directory of the user which is logged in. The file contains a unique name of the node within a cluster, NODENAME, as well as a reference to the configuration directory, CONFDIR used for deployment. How this configuration is done, is explained in Configuring a Deployment.

An example ~/ file is shown below:


You can see in the example above that worker-1 is the unique name of this particular host. It is referred to in configuration files, that can be found in CONFDIR.

Configuring a Deployment

Assuming the deployment configuration of the Axual Platform setup for your organization is stored in a folder (backed by Git), configuration needs to be organized in directories for Clusters and Tenants


This directory holds subdirectories for any Cluster in a particular setup. This means in a 2 cluster setup, there will be 2 subdirectories. Every cluster directory holds a single configuration file per cluster service (e.g. broker, distributor), as well as a file and a hosts file, for example:

└── cluster_x
    ├── ca
    │   ├── AxualDummyRootCA2018.cer
    │   └── AxualRootCA2018.cer
    ├── configuration
    │   └── alertmanager-config.yml
    ├── hosts
Cluster node configuration:

The file is an important file in any cluster setup. It holds information on which services are started on which nodes within a cluster, as well as other cluster-wide configuration. In the example below you see that in this 1 node cluster, there are 4 cluster services to be started, namely exhibitor, broker, cluster-api and distributor, 5 instance services and 3 management services. Services will be started in the order they are mentioned in this file.

# Name of the cluster

# Cluster, instance and management services for this cluster

# Please note INTERCLUSTER_ADVERTISED and APP_ADVERTISED are used for advertised url construction of broker only. All other components need to maintain their advertised urls separately.

# Monitoring configuration: the prometheus running on which cluster should scrape the JMX and prometheus endpoints of the components running on THIS cluster

# Cluster level configuration: which monitoring services should run on EVERY node of this cluster

# Advanced configuration, used by Discovery API

The formatting of the variable name for the other cluster nodes follows the following pattern: NODE<NUMBER>_<CLUSTER|INSTANCE|MGMT>_SERVICES=<NODENAME>:<SERVICE_X>,<SERVICE_Y>,<SERVICE_Z>

Cluster service configuration: <service>.sh

Every cluster service has its configuration stored in a file matching the service name, ending with .sh. See below for an example (shortened) Cluster API configuration:


# Port at which the web-server is hosted on the host machine

# Port at which the web-server is advertised (if, for instance, the webserver is behind a load balancer or a proxy)

# URL at which other components will find Cluster-API. Useful to use when behind a load balancer or a proxy.


Note that all configuration variables start with CLUSTERAPI_ and are all in uppercase.

Hosts configuration: hosts

The hosts file is used by some cluster services for the resolution of IP addresses assigned to those services. It is passed to every docker container with the --add-hosts option. See below an example hosts file:   


This directory holds subdirectories for any Tenant in a particar setup, as well as its Instances.

Within a tenant’s context, multiple instances might be defined. For every instance, a directory can be found under the tenant subdirectory. Every instance directory holds a single configuration file per instance service (e.g. Instance API, Discovery API), as well as an file, for example:

├── instances
│   └── OTA
│       ├──
│       ├── ca
│       │   ├── AxualDummyRootCA2018.cer
│       │   ├── AxualRootCA2018.cer
│       │   └── DigiCert-High-Assurance-EV-Root-CA.cer
│       ├──
│       ├──
│       ├──
│       ├──
│       ├──
│       └──
Tenant configuration:

The file contains 2 configuration variables that are deprecated, and will be deleted in the future.

# Non-functional variable. It exists because platform-deploy has a 'get_tenant_name' function.
# It may be used in the future for logging purposes, but at the moment it's completely unused.

# Needed by Discovery API for compatibility with older client-library versions
# The /v2 endpoint returns the system name in the response body.
Instance configuration:

The contains configuration settings that apply to all instance services.

# Note: the following properties apply to all instance-services in this instance, as well as all docker containers running on the clusters this instance spans

#  The name of this instance. It's used for:
#  - naming distribution connect-jobs
#  - part of the name of every topic owned by this instance,
#   for brokers whose cluster-api use the instance name in the topic naming convention
#  - discovery api uses it as "discovery.environment" property

# The name of the cluster which runs management services, like Prometheus, Management API and Management UI
# that should be managing this instance.

# The name of the cluster which sund client services, like Connect, which should run as part of this instande.
Instance service configuration: <service>.sh

Every cluster service has its configuration stored in a file matching the service name, ending with .sh. See below for an example (shortened) Discovery API configuration:


# Discovery API is behind an instance-load-balancer.
# This is the HOSTNAME (no protocol / port) of theSelf-Se load balancer.
# This load balancer should do just forwarding, the Discovery API itself handles SSL

# The value for the "server.ssl.enabled-protocols" config in the discovery-api.
# If this property is missing or empty, the default is "TLSv1.2"
# There was no documentation to back up prefixing protocols with the plus sign, but
# practice shows it's needed in order to support all of them at once.

# Instance-level defined ports are comma separated pairs of "cluster-name,port"

# The port at which the discovery API load balancers are available per cluster, be it SSL or not.


Note that all configuration variables start with DISCOVERYAPI_ and are in uppercase.

Using Axual CLI

For every new version of the platform a new Axual CLI is released, as can be seen in the release notes. This is because depending on what functionality has been introduced, deployment functionality or configuration options might have changed as well.

Refer to Using Axual CLI for more information on how to use the CLI.