OMniLeads, Un Software de Contact Center para Docker

Por: Fabián Pignataro

Asumiendo el inminente camino de la industria hacia la adopción del paradigma planteado por el Cloud computing, pero conscientes al mismo tiempo del actual modelo de aplicaciones monolíticas que se ejecutan sobre servidores On-Premise y su gran cantidad de adeptos, OMniLeads apuesta por ser aplicación capaz de funcionar en ambos mundos.

En esta oportunidad nos vamos a centrar en OMniLeads corriendo como microservicios sobre contenedores Docker.

Siguiendo los pasos aquí plasmados cualquier integrador o aficionado vinculado al ecosistema de la telefonía IP & Contact Center (quien habitualmente administra plataformas basadas en Asterisk & GNU/Linux) podrá ser capaz de desplegar nuestra aplicación en un solo paso (o comando) gracias a la inmediatez, ligereza y eficiencia que proporciona la tecnología de contenedores.

Figura 1: OML & Docker

¿Qué es docker?

Docker es un proyecto de código abierto que llegó para optimizar la forma en que una aplicación se construye, empaqueta y distribuye, garantizando en todas estas etapas la independencia del sistema operativo subyacente, al abstraernos del entorno con estas unidades llamadas contenedores.

Docker permite construir aplicaciones mediante pequeñas imágenes (que generalmente contienen un componente del sistema) integradas entre sí, de manera tal que la aplicación pueda ser desplegada a partir de lanzar dichos contenedores como instancias «vivas» de cada una de las imágenes «binarias» mencionadas.

Podemos plantear a las imágenes de Docker como «binarios» instanciados a la hora de lanzar un contenedor, y al contenedor como el componente o servicio «en tiempo de ejecución». Sin entrar en demasiados detalles, estos conceptos son importantes a la hora de pensar en una aplicación basada en microservicios.

Para seguir indagando acerca de Docker, aquí algunos links:

Figura 2: Docker arch – figura original

¿Por qué Docker? En la actualidad es el principal vehículo de transporte de los componentes (microservicios) de una aplicación «Cloud Native», que a su vez se emparenta mucho con la cultura DevOps y los beneficios que proporciona para proyectos como el nuestro.

Por otro lado los orquestadores de contenedores de código abierto y con mayor cantidad de instancias en producción son muy compatibles con Docker. De hecho Kubernetes es el orquestador elegido por OMniLeads.

Docker y Omnileads, un camino de ida

OMniLeads adoptó Docker primero como una tecnología utilizada para facilitar a los desarrolladores los despliegues de sus entornos, luego pasó a ser parte de la integración continua y entrega continua (CI/CD) en conjunto con Gitlab dentro del proyecto. Esto nos permitió movernos con mayor «agilidad», mientras fuimos ganando eficiencia en cuestiones de automatización y testing integral de la app, finalmente y de manera inexorable comenzó a resonar el considerar los despliegues en producción de la mano de contenedores Docker.

OMniLeads mantiene las imágenes de cada componente disponibles en Docker-Hub y se distribuye como parte del repositorio un archivo «docker-compose» para ejecutar la aplicación.

Figura 3: DevOps Culture

Manos a la obra

Asumimos que el lector dispone tanto del «Docker-Engine» como de «docker-compose» en su estación de trabajo.

En caso contrario, instalar:

NOTA

Antes de avanzar aclaramos que todo lo expuesto a continuación, tiene garantías en cualquier host GNU/Linux que corra Docker-Engine. Sin embargo con el correr del tiempo, vamos a ir adicionando a esta guía, los pasos a seguir para que esto pueda ser ejecutado en MAC o Windows.

OMniLeads es un sistema complejo en el cual subyacen diferentes componentes:

  • Nginx
  • Django / Python
  • Asterisk
  • Kamailio
  • RTPEngine
  • Postgres
  • Redis
  • Dialer
  • Database Dialer
Figura 4: OML & Docker

En nuestro repositorio se encuentra todo lo necesario para ejecutar la aplicación bajo esta arquitectura, así que en el próximo paso nos vamos a descargar el repositorio del proyecto para luego posicionarnos dentro del subdirectorio «ominicontacto/deploy/docker».

git clone https://gitlab.com/omnileads/ominicontacto.git
cd ominicontacto/deploy/docker

Allí entonces contamos con la carpeta «prodenv» la cual debemos copiar y pegar en cualquier ubicación dentro del «docker-engine» host. Por ejemplo

cp -a ./prodenv ~/

Vamos a listar los archivos existentes inicialmente dentro de la carpeta mencionada con anterioridad:

  • El archivo oculto .env, donde residen las variables de entorno.
  • El archivo docker-compose.yml, donde se especifica cada micro-servicio con su contenedor parametrizado para implementarlo.
  • El archivo README.md con las indicaciones para levantar el entorno.
  • El archivo CONTRIBUTING.md para aquellos entusiastas dockerizados que deseen aportar sus conocimientos al proyecto.
Figura 5: prodenv folder

Variables de entorno

Antes de lanzar la ejecución del «docker-compose» que levanta el entorno (todos los contenedores), debemos establecer algunos parámetros del sistema dentro del archivo oculto «.env». En este archivo se configuran variables de entorno que serán utilizadas por los contenedores.

El archivo se encuentra documentado con comentarios, no obstante vamos a citar los principales parámetros a continuación:

Como podemos observar en la figura, se deben ajustar las variables:

  • DOCKER_HOSTNAME: es el nombre del host que está ejecutando el docker-engine.
  • RELEASE: es el release de OMniLeads que se desea desplegar
  • TZ: la zona horaria
  • DJANGO_PASS: es la contraseña del usuario admin de la aplicación.
Figura 6: env variables

Las otras variables que vamos a repasar son:

  • MYSQL_ROOT_PASS: la contraseña para el motor MySQL (necesario para el módulo Dialer)
  • PGPASSWORD: la contraseña del usuario «omnileads» de PostgreSQL
Figura 7: env variables

Una vez ajustadas las variables marcadas, estamos en condiciones de ejecutar el deploy de OMniLeads.

NOTA

Las direcciones IP citadas en el archivo, SOLAMENTE deben modificarse en caso de que su dirección de red (donde se ejecuta el docker-engine) coincida con el rango de las direcciones aquí citadas.

Deploy de la aplicación

Para ejecutar el despliegue de la aplicación debemos lanzar el comando «docker-compose» dentro de nuestro directorio «prodenv».

docker-compose up -d

Si es la primera vez que lo ejecutamos, se va a demorar un tiempo en descargar las imágenes de cada componente. Esto luce de la siguiente manera.

Figura 8: docker-compose up

Una vez finalizada la ejecución del comando (la opción -d nos permite recuperar la terminal), podemos ejecutar el comando «docker ps» y «docker images» para visibilizar que los contenedores están activos y sus imágenes disponibles.

Figura 9: docker ps
Figura 10: docker images

Listo para utilizar

Para acceder debemos apuntar con https al «hostname» del docker-engine y puerto 444 (si dejó el puerto por defecto en «.env»).

Figura 11: login

Ahora si, podemos continuar con la configuración inicial

NOTA

Es importante aclarar que el login de Agente en OMniLeads SI o SI tiene que ser accediendo a la aplicación mediante su hostname, NO utilizando la dirección IP. Por lo tanto si el hostname del docker-engine no lo resuelve nuestro DNS local, debemos cargar esta resolución en cada «archivo de hosts» de cada estación de agente. En este link se explica cómo llevarlo a cabo.

Conclusiones

El concepto de contenedor llegó para quedarse y solo veremos cómo cada vez más aplicaciones van a ir adoptando esta tecnología. Como proyecto apostamos por estar a la vanguardia y además invitamos a probar nuestra aplicación a partir de la simple ejecución de un comando «docker-compose up».Pueden seguir todas las novedades del proyecto en @OMniLeads_net.

Comparte este artículo con tus amigos