Top 6 Docker Images for JMeter Users and Performance Testers

A good set of containers is equivalent to a Swiss Knife: a handy set of multiple tools ready for use. If you're an Apache JMeter™ and Docker user, it is useful to have a set of Docker images/containers available for performance testing. This article will recommend 6 Docker images (the elements that start the containers) that you should have in your set as a performance tester.

Installing these tools through Docker instead of directly onto your machine simplifies environment maintenance and enables system isolation, which increases security. To learn how to install Docker locally, check out this blog post.

Let's get started.

1. JMeter (non-GUI)

The JMeter image creates a non-GUI JMeter executor container. With the JMeter image, the user doesn't have to set up an environment (e.g. Java Virtual Machine and property files) and she/he can focus on creating a test script and test resources (e.g. data files). The JMeter image is light because it lacks JMeter additions, like a GUI, documentation and plugins (which you can add), making it a quick and easy solution for when you need to run JMeter.

I developed this JMeter image when writing the article series about Docker. This image has many features that make it flexible for testing projects with JMeter:

• Lightweight - 94Mb based on Alpine Linux and OpenJDK
• Supports Apache JMeter 4.0 - the latest JMeter version
• Plugins extensibility - you can dynamically add plugins to the container execution through Docker volume
• JMeter command line - the image does not filter any JMeter command arguments thus allowing multiple running modes
• Distributed mode - this image can be used to set up a container cluster in distributed mode.

Let's look at a few examples.

The following example command runs a container executing a jmx script. The jmx script must be on the same machine the container is executed on. After test completion, the container stops and leaves reports and log files on the execution machine.

export timestamp=$(date +%Y%m%d_%H%M%S) && \
export volume_path=<where files are on host> && \
export jmeter_path=/mnt/jmeter && \
docker run \
  --volume "${volume_path}":${jmeter_path} \
  jmeter \
  -n <any sequence of jmeter args> \
  -t ${jmeter_path}/<jmx_script> \
  -l ${jmeter_path}/tmp/result_${timestamp}.jtl \
  -j ${jmeter_path}/tmp/jmeter_${timestamp}.log

This second command executes a JMeter container as a client, passing the script to be executed. The "-R" argument passes the IP addresses of JMeter server instances.

docker run \
  --net $TEST_NET --ip $CLIENT_IP \
  -v "${volume_path}":${jmeter_path} \
  --rm \
  jmeter \
  -n -X \
  -Jclient.rmi.localport=7000 \
  -R $(echo $(printf ",%s" "${SERVER_IPS[@]}") | cut -c 2-) \
  -t ${jmeter_path}/<jmx_script> \
  -l ${jmeter_path}/client/result_${timestamp}.jtl \
  -j ${jmeter_path}/client/jmeter_${timestamp}.log

2. InfluxDB and Grafana

The InfluxDB and Grafana images provide an open source time-series database feature to collect structured data, and a powerful data analytics web tool. They can be used together or separately.

Each InfluxDB dataset contains several key-value pairs, consisting of the fieldset and a timestamp. InfluxDB has no external dependencies and provides a SQL-like language with built-in time-centric functions. This component can be adopted for collecting JMeter statistics.

The following command example executes an InfluxDB container into a custom Docker network.

docker run --rm \
      --name influxdb \
      -dit \
      --net $TIME_SERIES_NET \
      -e INFLUXDB_DB=db0 \
      -e INFLUXDB_ADMIN_ENABLED=true \
      -e INFLUXDB_ADMIN_USER=admin \
      -e INFLUXDB_ADMIN_PASSWORD=passw0rd \
      -e INFLUXDB_USER=grafana \
      -e INFLUXDB_USER_PASSWORD=dbpassw0rd \
      -v $INFLUXDB_VOLUME:/var/lib/influxdb \
      influxdb

• --rm automatically removes the container after conclusion, so no unnecessary container information is preserved during restart

• --name is the name of the running container, can be used as a domain name in the Docker network
• --dit runs the container in the background with a local shell, ready to be used like a remote ssh command line
• --net assigns a working virtualized network handled by Docker
• -e pass the environment variable to the recently created container. In this case we configured:
  • INFLUXDB_DB - local database name
  • INFLUXDB_ADMIN_ENABLED, INFLUXDB_ADMIN_USER and INFLUXDB_ADMIN_PASSWORD - configure the availability of the admin profile
  • INFLUXDB_USER and INFLUXDB_USER_PASSWORD - configure the standard user profile used by Grafana.
• -v assigns a logical volume on the hosting machine that persists on the container restart, by using this volume we can limit disk space to necessary data only

Grafana is a powerful tool for data analysis and exporting. Grafana is not directly connected to JMeter, but can be added to our process via Docker.

The following command executes a Grafana container:

docker run --rm \
      --name=grafana \
      -dit \
      --net $TIME_SERIES_NET \
      -p 3000:3000 \
      -e GF_SECURITY_ADMIN_PASSWORD =adminpassw0rd \
      -v $GRAFANA_VOLUME:/var/lib/grafana \
      grafana/grafana

• --rm automatically removes the container after conclusion, so no unnecessary container information is preserved during restart
• --name is the name of the running container, can be used as a domain name in the Docker network
• --dit runs the container in the background with a local shell, ready to be used like a remote ssh command line
• --net assigns a working virtualized network handled by Docker
• -p publishes the local container port to the host machine port, to export services externally with respect to the Docker machine
• -e passes the GF_SECURITY_ADMIN_PASSWORD that is the Grafana UI password
• -v assigns a logical volume on the hosting machine that persists on the container restart, by using this volume we can limit disk space to necessary data only

When this container is running we can proceed with Grafana configuration to assign InfluxDB executed before as Data Source.

Integration with JMeter is performed with Backend Listener that has specific implementation for InfluxDB. So during test execution JMeter uploads stats to InfluxDB and after testing with Grafana we can export reports as required.

3. Selenium

The Selenium image provides a ready to use solution to improve automated web browser testing. There isn't one single Selenium image but rather multiple images that cover different Selenium running modes (e.g. Selenium Hub, Selenium Node).

These images can be integrated with dockerized JMeter easily. To properly use these images with JMeter it's mandatory to:

• Install JMeter WebDriver plugins into a running JMeter installation
• Configure the JMeter script as RemoteWebDriver

The following command quickly creates a container ready to be used as a Selenium test endpoint (browser + driver). In this test, we chose the Selenium debug image so we can see the test execution with a VNC protocol.

docker run \
    -d -p ${port4Driver}:4444 -p ${port4VNC}:5900 \
    --shm-size=2g \
    selenium/standalone-chrome-debug:3.14.0-beryllium
#### OR	
docker run \
    -d -p ${port4Driver}:4444 -p ${port4VNC}:5900 \
    --shm-size=2g \
    selenium/standalone-firefox-debug:3.14.0-beryllium

4. Jenkins-CI

The Jenkins image integrates this popular build automation with an existing Docker-based infrastructure. The Jenkins image is supported by a wide community and receives regular updates and support. Jenkins-CI is executed as a server application that manages many different tasks. Regarding JMeter, Jenkins-CI can manage JMeter test script scheduling, execution and result history.

The following command runs a Jenkins-CI container.

• -d - detached mode
• -v mounts a volume from the host machine and preserves task configuration by container restart
• -p exports the port where Jenkins-CI UI is listening to the host machine

docker run \
  -d \
  -v ${jenkins_home}:/var/jenkins_home \
  -p 8080:8080 \
  jenkins/jenkins:lts

A configuration folder without a Docker volume does not survive after stopping the container. To save the Jenkins-CI config data (and maybe track it in a version control tool), configure a volume between the container and the host machine.

Jenkins-CI can manage JMeter execution in two ways:

• Running JMeter in the same container Jenkins-CI is running in, with the jmeter-performance-plugin
• Invoke remote command execution so another container can handle the JMeter execution

The only limit for executing JMeter in the same container with another tool is your own resources. Using an additional container can simplify resource handling and relative costs.

5. Taurus

The Taurus image runs open source Taurus, an automation-friendly wrapper for running JMeter, Gatling, Locust.io, Grinder, Selenium and more. This image includes all the necessary dependencies, allowing users to focus on testing, and it's regularly updated and supported.

The following command runs Taurus

• --rm deletes container data at execution end
• -v (first) mounts the Taurus script volume to the host machine, sharing the input script
• -v (second) mounts the Taurus artifacts volume to the host machine, sharing output artifacts.

docker run \
  --rm \
  -v ${scripts_directory}:/bzt-configs \
  -v ${artifacts_directory}:/tmp/artifacts \
  blazemeter/taurus

6. Registry Server

The Docker Registry Server is a local Docker image repository for storing images. It's a way to centralize frequently used Docker images as an artifacts library. You can quickly set up your working LAN, drastically reducing latency time when fetching images. This is an official Docker image, supported and documented as a standard Docker component. Updates are regular without the risk of an abandoned project.

The following command creates a running container ready to act as a registry of our working network.

• -p publishes the working port on the host machine
• --rm removes container information when it terminates
• -v links the volume with the local machine. The data stored is Docker images plus a configuration file
• --restart is used to modify the behavior of the container in case of termination. In our case, we apply a restart always policy
• --name - of the container

docker run -d --rm \
    -p 5000:5000 \
    -v $REGISTRY_VOLUME:/var/lib/registry \
    --restart=always \
    --name registry \
    registry:2

A configured container service provides a low latency repository server, making it possible to push and pull images when necessary.

This article discussed some of the most important Docker images for JMeter performance testing. After creating your JMX file, upload it to BlazeMeter and achieve scalability, advanced analytics, and collaboration abilities.