Configuration

The cluster configuration is done through the Loadcoder configuration file. Loadcoder will by default look for loadcoder.conf. This can be changed using the jvm argument loadcoder.configuration:

-Dloadcoder.configuration=myconfig.conf

In some situation (depending on how the infrastructure and network looks like), it may be needed two have more than one configuration file. One to use from your workstation, and one that will be used from inside the Loadcoder conainer in the cluster. In this case you set the loadcoder.configuration argument in the test.sh file where the test execution command is executed.

Below configuration file contains examples for all parameters that will be needed to configure a distributed cluster

loadcoder.conf

################## CONTAINERS #########################
# Ports:
# .server.port is the port that the running application inside the container listens at.
#    This setting should only be used if the actual applications port is changed.
#
# .exposed.server.port is the port that the container will expose to the outside mapped
#    to the server port. 
#
# .port is the port that connecting clients will use.
#    The port configurations will default to each others values in the order they are
#    stated above from bottom and up. If the .port is not present it will default
#    to .exposed.server.port and so on. If .server.port is not present, the last default option
#    will be the port specified in class com.loadcoder.cluster.clients.docker.MasterContainers
#
# .host will be host or ip value where the container can be reached by clients
#  either outside or inside the cluster
#
# .internal.host will be used by clients only running inside the cluster. If not present,
#    these clients will first default back to the masters internal host, and finally
#    to the master host 

influxdb.image=influxdb:1.7.10
influxdb.exposed.port=4000
influxdb.internal.host=inxflux-host

grafana.image=grafana/grafana:5.4.3
grafana.host=grafanahost

loadship.image=loadcoderhub/loadcoder:1.0.0
loadship.port=5000

loadcoder.image=loadcoderhub/loadcoder:1.0.0


################ INFRASTRUCTURE ################
# Node with id = 1 will be the Master
cluster.masternode=1

# The Master node with id: 1
node.1.host=masterhost
node.1.dockerapi.port=2375
node.2.internal.host=masterhost-internal

# Worker node with id: 2
node.2.host=workerhost

node.2.dockerapi.port=2375

# hostip entries will turn upp in /etc/hosts as host IP mappings
# If the master hostname can't be found in DNS, it is a good
# idea to state that hostname here.
# You can add as many hosts as you like.
hostip.masterhost=192.168.1.104
hostip.webapptotest=192.168.1.105

Additional configuration

The configuration below will only be needed is certain cases

All nodes (including the Master) will default act as Workers. You can configure to inactivate them as Workers by setting the use-as-worker parameter to false. This will be recommended for the Master node if you have other nodes to use, as the Master already executes the Master Containers (Grafana, InfluxDB and Loadship)

node.1.use-as-worker=false

The containers in the cluster will default have its time adjusted to UTC. You can set the timezone of the containers by setting the parameter below. Set this to the Time zone you belong to according the the IANA Time Zone Database. You can also check the available option at your Master or Worker machine under /usr/share/zoneinfo/

cluster.timezone=Europe/Stockholm

If you for some reason need to change the name of the Loadcoder container (from default value loadcoder) you can do this with:

cluster.id=alternative_id

Loadcoder can also setup the package repository Jfrog Artifactory at the Master Node. If you want to break up your testcode into different projects and packages, you will need a repository to deploy to and download from. If you already have repository where all packages are managed, you will probably not need this.

artifactory.image=docker.bintray.io/jfrog/artifactory-oss:latest

Take caution before using below parameter. It is possible to communication with the Docker API without a secure connection. This can be useful for example if you need to setup a cluster at your own Workstation. Be confident that your Docker API is configured to lisen to 127.0.0.1 before starting to use the API with mtls. See Cluster Security for information of how to setup MTLS.

docker.mtls=false
docker.mtls=false