Docker containers: the perfect technology for RPA robots’ auto-scaling

3 September, 2018

The dynamic scaling or auto-scaling of robots has become one of the most demanded functionalities in the RPA market of 2018, due to the need of companies to adapt to workloads quickly and in an unassisted way.

This requirement implies the acquisition of additional robot’ licenses (nodes, in the case of Jidoka) for supporting the planned or unforeseen workload, whose deployment can paradoxically delay the work execution, as it requires installation and configuration tasks for the new nodes, operating system, virtualization, etc.

At Jidoka, aware of our customers’ concerns, we have addressed the inclusion of functionalities for auto-scaled robots using the latest available technology: the management of nodes via containers.

But, before continuing, what is a container?

The best answer is likely found in the documentation of the reference Open Source container tool: Docker.

A simple answer could be that a container is an instance of an image. In this context, an image is a package including all the necessary software (also the operating system) for a service or a set of services to be executed. Therefore, an image is the definition of the included software, and a container is the concrete instantiation of an image.

We could compare a container with a virtual machine, they are similar in terms of how they start/stop, being easily manageable. On the other hand, they are different in terms of how they are administrated, since containers are especially easy to monitor as they are oriented to give a very specific service or services. There are other differences: containers are much lighter in terms of resources, which allows encapsulating the services to be managed more easily.

Jidoka integrates in the platform a container management to control the lifecycle of the connected nodes. Recall that Jidoka nodes are physical or virtual machines including the software the robots require to use. Robots are executed in the nodes, so the processing capacity is directly proportional to the number of nodes available online, as they are the robotic work force.

By controlling the nodes’ lifecycle from the console, we can make them activate or deactivate depending on the workload, and therefore offer real-time auto-scaling functionality.

Use Case

We propose a simple scenario to show the utility of container management from the Jidoka console: we want the system to automatically start the nodes needed to process the queued executions of robots, without human intervention; after these robots’ execution, we want the system to turn off the nodes.

Jidoka node Docker container

Before looking at the configuration applied in the console to solve the use case, we have to prepare a node in a Docker container.

Jidoka robots can be run in Linux environments (a big difference from the rest of RPA vendors), so we have used a very well-known container in Linux environments, that includes a minimal version of Ubuntu Desktop with VNC and Firefox. This image can be found in the Docker hub here. Its repository is dorowu / ubuntu-desktop-lxde-vnc

To the image, which can be obtained from the repository, we have added the installation of the Oracle JDK and Google Chrome. The Oracle JDK is necessary for the Jidoka agent execution. The Jidoka node is a Java program, so strictly speaking, only a JRE is necessary, thus it could be the OpenJDK or any other. Additionally, we have installed Google Chrome to test with different browsers, remember that the image has Mozilla Firefox pre-installed.

Since Docker containers do not persist information between executions, the directory where the agent resides, as well as the support files and trace files, are configured as a volume on the host, so these resources can be accessed even if the container is stopped.

Configuration of actions in Jidoka

The first thing to do in the console, is to configure an action in response to the event “ROBOT_SCHEDULE_WITHOUT_NODE”. This event is generated when a robot execution is queued, and it does not start in the time frame that we have configured, usually because there is no compatible node available. This margin can be 1 minute, 30 minutes, 1 hour, 2 hours, etc., depending on how quickly we want the system to react to such circumstance.

The action to configure in this case would be CONTAINER_NODE_START. This action determines the node to start depending on the offline nodes compatibility, as long as they are configured in a container. Then, after the action execution in response to the ROBOT_SCHEDULE_WITHOUT_NODE event, we would have a node on, and the robot running.

Additionally, and to turn the node off after ending the execution, we configure a CONTAINER_SELECTED_NODE_STOP action in response to the ROBOT_END event.

With this action, when the robot finishes its execution, the platform will turn off the node where it was executed.

In a simplified way, the events sequence is the following:

  1. The execution of a robot is queued. As there are no available nodes, the execution is on hold
  2. The time configured for the ROBOT_SCHEDULE_WITHOUT_NODE event passes, causing the event to be generated
  3. The CONTAINER_NODE_START action is executed in response to the previous event, causing a Docker container that includes the Jidoka agent to start
  4. The agent connects to the console
  5. The robot is executed in the just started node
  6. The ROBOT_END event is generated when the robot’s execution finishes
  7. The CONTAINER_SELECTED_NODE_STOP action stops the Docker container

This exercise can be done using several concurrent executions in as many nodes, so no change in the configuration would be necessary.

The following video shows a complete execution, where:

  • The nodes are disconnected
  • Two executions of the same robot are launched
  • The system generates the event indicating a robot has been queued for more than 1 minute (ROBOT_SCHEDULE_WITHOUT_NODE)
  • The system automatically starts the two nodes, and each one executes one of the processes.

We have included at the end of the video an example of a node’ manual stop by the administrator, another functionality added to the console (in addition to the launch).


As you can see, with only one action configured, the Jidoka platform can operate a robot even if no online node is available.

The functionality of auto-scaling integrated into the Jidoka console, allows our customers to easily respond to work peaks in a 100% BaaS (Bot as a Service) model.

Subscribe to our newsletter

You will be informed about the latest innovations and news

I have read and accept the Privacy PolicyLegal Details

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.