Contenedores Docker: la tecnología perfecta para el auto-escalado de robots RPA

Comparativas de fabricantes RPA: ¿Coches o aviones?
29/06/2018
Jidoka abre oficina en Londres impulsada por su expansión internacional
13/09/2018
Mostrar todo

Contenedores Docker: la tecnología perfecta para el auto-escalado de robots RPA

El escalado dinámico o auto-escalado de robots se ha convertido en una de las funcionalidades más demandadas en el mercado de RPA de 2018, debido a la necesidad de las empresas de adaptarse a picos de trabajo de forma rápida y desasistida.

Esta necesidad supone la adquisición de licencias adicionales de robots (nodos, en el caso de Jidoka) que den servicio a esta carga de trabajo (planificada o imprevista), cuyo despliegue puede derivar paradójicamente en demoras en la ejecución del trabajo, al requerir de tareas de instalación y configuración de los nuevos nodos, sistema operativo, virtualización, etc.

En Jidoka, conscientes de las inquietudes de nuestros clientes, hemos abordado la inclusión de funcionalidades para el auto-escalado de robots utilizando la última tecnología disponible: la gestión de nodos vía contenedores.

Pero, antes de seguir ¿qué es un contenedor?

La mejor respuesta se encuentra probablemente en la documentación de la herramienta de referencia en contenedores Open Source: Docker.

Una respuesta sencilla podría ser que un contenedor es una instancia de una imagen. En este contexto, una imagen es un paquete que incluye todo el software necesario (también el sistema operativo) para que un servicio o un conjunto de servicios se ejecute. Por tanto, una imagen es la definición del software incluido, y un contenedor es la instanciación concreta de una imagen.

Podríamos comparar un contenedor con una máquina virtual, son similares desde el punto de vista de su inicio y parada, al poder ser gestionados con facilidad. Por otra parte, son distintos desde el punto de vista de la administración, ya que los contenedores son especialmente fáciles de monitorizar al estar orientados a dar un servicio o servicios muy concretos. Existen otras diferencias: los contenedores son mucho más ligeros en términos de recursos, lo que permite encapsular los servicios a gestionar más fácilmente.

Jidoka integra la gestión de contenedores para controlar el ciclo de vida de los nodos conectados a la plataforma. Recordemos que los nodos Jidoka son máquinas físicas o virtuales que incluyen el software que los robots necesitan utilizar. Es en los nodos donde realmente se ejecutan los robots, siendo la capacidad de proceso directamente proporcional al número de nodos online, ya que son la fuerza de trabajo robotizada.

Al controlar el ciclo de vida de los nodos desde la consola, podemos hacer que se activen o desactiven en función de la carga de trabajo y por lo tanto ofrecer funcionalidad en tiempo real de auto-escalado.

Caso de uso

Para mostrar la utilidad de la gestión de contenedores desde la consola Jidoka, vamos a plantear un escenario sencillo: Queremos que nuestro sistema, sin intervención humana, inicie automáticamente los nodos necesarios para procesar las ejecuciones encoladas de robots; tras la ejecución de estos robots, queremos que el sistema apague los nodos.

Contenedor Docker de nodo Jidoka

Antes de ver la configuración a aplicar en la consola para resolver el caso de uso, debemos preparar un nodo en un contenedor Docker.

Los robots Jidoka se pueden ejecutar en entornos Linux (una gran diferencia con respecto a la gran mayoría de los fabricantes), por lo que hemos utilizado un contenedor muy popular en entornos Linux que incluye una versión mínima de Ubuntu Desktop con VNC y Firefox. Esta imagen se puede encontrar en el hub de Docker aquí, su repositorio es dorowu/ubuntu-desktop-lxde-vnc.

A la imagen, que se puede obtener del repositorio, le hemos añadido la instalación del JDK de Oracle y de Google Chrome. El JDK de Oracle es necesario para la ejecución del agente Jidoka, que es un programa Java, aunque estrictamente hablando solo es necesario un JRE, por lo que podría ser el de OpenJDK o cualquier otro. Adicionalmente, se ha instalado Google Chrome para hacer pruebas con distintos navegadores, recordemos que la imagen ya tiene preinstalado Mozilla Firefox.

Como los contenedores Docker no persisten información entre ejecuciones, el directorio donde reside el agente, los ficheros de soporte y los ficheros de traza se configuran como un volumen en el host, de forma que pueda accederse a estos recursos aunque el contenedor esté parado.

Configuración de acciones en Jidoka

Lo primero a hacer en la consola es configurar una acción como respuesta a un evento del tipo ROBOT_SCHEDULE_WITHOUT_NODE. Este evento se genera cuando se encola una ejecución de un robot y ésta no se inicia en el margen temporal que hayamos configurado, habitualmente porque no hay ningún nodo compatible disponible. Este margen puede ser de 1 minuto, 30 minutos, 1 hora, 2 horas, etc., en función de lo rápido que queramos que el sistema reaccione a tal circunstancia.

La acción a configurar en este caso sería CONTAINER_NODE_START. Esta acción determina el nodo a iniciar en función de la compatibilidad de los nodos offline, siempre y cuando estén configurados en un contenedor. Por lo tanto, tras la ejecución de la acción a respuesta del evento ROBOT_SCHEDULE_WITHOUT_NODE, ya tendríamos un nodo encendido y ejecutando el robot.

Adicionalmente, y con objeto de que tras la finalización de la ejecución el nodo se apague, configuramos una acción CONTAINER_SELECTED_NODE_STOP como respuesta al evento ROBOT_END.

Con esta acción, cuando el robot termine su ejecución, la plataforma apagará el nodo donde se ejecutó.

De forma esquemática la secuencia de acontecimientos es la siguiente:

  1. Se encola la ejecución de un robot. Al no haber nodos disponibles, la ejecución queda en espera
  2. Transcurre el tiempo configurado para el evento ROBOT_SCHEDULE_WITHOUT_NODE, lo que provoca que se genere dicho evento
  3. La acción CONTAINER_NODE_START se ejecuta como respuesta al evento anterior, haciendo que se inicie un contenedor Docker que incluye el agente Jidoka
  4. El agente se conecta a la consola
  5. Se ejecuta el robot en el nodo recién iniciado
  6. Se genera el evento ROBOT_END al terminar la ejecución del robot
  7. La acción CONTAINER_SELECTED_NODE_STOP detiene el contenedor Docker

Este ejercicio se puede realizar utilizando varias ejecuciones concurrentes en otros tantos nodos, por lo que no sería necesario ningún cambio en la configuración.

Podéis ver el siguiente vídeo de una ejecución completa, donde:

  • Inicialmente los nodos se encuentran desconectados
  • Se lanzan dos ejecuciones de un mismo robot
  • El sistema genera el evento que indica que un robot lleva más de 1 minuto encolado (ROBOT_SCHEDULE_WITHOUT_NODE)
  • El sistema arranca de forma automática los dos nodos y cada uno ejecuta uno de los procesos

Hemos incluido al final del video la parada manual de un nodo por parte del administrador, que es otra funcionalidad añadida a la consola (además del arranque).

Conclusión

Como podéis apreciar, con solo una acción configurada, la plataforma puede ejecutar un robot aunque no haya ningún nodo online disponible.

La funcionalidad de auto-escalado integrada en la consola Jidoka, permite fácilmente a nuestros clientes atender picos de trabajo en un modelo 100% BaaS: Bot as a Service.

Juan Manuel Reina Morales
Juan Manuel Reina Morales
CTO de Jidoka. Socio fundador de Novayre, empresa tecnológica apasionada por la innovación software y la automatización. "La verdad está en el código".

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *