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). All nodes are by default used as workers.

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 communiate 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 listen at 127.0.0.1 before starting to use the API with mtls. See Cluster Security for information of how to setup MTLS. The default value for this is true

docker.mtls=false

In cases where you have a very limited bandwidth or where you need to use a larger docker image, you may experience timeouts when the container is about to be started. In this case you can adjust the timeout time, using the below parameter. Default value is 5. The reason why this value is not a higher one (or unlimited) is because you probably want to be notified that something is wrong after a certain amount of time. If you are still experiencing problems with this even after adjusing the timeout value, try to manually pull the image from the server you are trying to instruct, simply by using the command docker pull (image)

docker.image-pull-timeout-minutes=10