Running tests with containerized agents

If you already have a local workbench, instead of installing the agents on different machines and locations, you can just deploy the containerized agents to generate the load.

Before you begin

You must have configured Docker container as per the instructions in the Configuring Docker containers topic.

About this task

Typically, when the agents are installed, you specify the workbench host name and port number to establish the connection with the workbench. If you use containerized agents, they are already installed. Therefore, you specify the connection information during the run.
Note: You cannot update the container images from version 9.2.1 to version To use v9.2.1.1 image, you must first uninstall the v9.2.1 image. To uninstall the image, use these commands:
  1. Stop the container by running
    docker stop "CONTAINER  ID"
  2. Uninstall the image by running
    docker rmi -f "image ID"


  1. Start the container instance of the agent:
    $ docker run -dit –-rm -e MASTER_NAME=WorkbenchIP imageName:imageVersion
    Table 1. Description of parameters
    Command Description
    -dit Specifies that the agent container runs in the background.
    --rm Specifies to clean up the container and remove the file system when the container exits.
    MASTER_NAME Specifies the IP or host name of the workbench.
    MASTER_PORT Specifies the port number of the workbench. If you use the default port number of 7080, this command is optional.
    imageName:imageVersion Specifies the name and version of the image.
  2. On your workbench, use the Agent Status button to verify the two container agents are polling the workbench.
    Status of the agents
    Note: The agent host names should match the IDs of the containers running in Docker. Make a note of the IP address of each agent since they will be used when creating the agent locations.
  3. In the schedule editor, create a new location test asset for each container agent so that the selected User Group runs on two agent locations.
  4. Run the schedule. The deployment step could result in the schedule remaining in the “Launching” state for several minutes.