Variables de instalación del componente OMLApp

En éste inciso, vamos a listar y explicar cada una de las variables implicadas en un despliegue de OMniLeads.

oml_infras_stage

Se refiere al proveedor de infraestructura implicado. La idea es aprovechar las APIs de los proveedores cloud para determinar cuestiones como parámetros de la red. Si vamos a instalar onpremise o en alguna nube que no está dentro del listado, asignar onpremise como valor para la variable.

Posibles valores: onpremise, aws, digitalocean, vultr, linode.

oml_app_release

Aquí se debe indicar qué release se desea desplegar.

Posibles valores: master, develop, release-X.X.X.

oml_tenant_name

Ésta variable, debe contener un nombre de referencia para asignar al despliegue. Típicamente se utiliza el nombre del ambiente/cliente. Está pensado para oferentes de CCaaS (Contact Center as a Service), entornos en donde se ejecuta una instancia de OMniLeads para cada suscriptor del servicio.

oml_callrec_device

Aquí debemos indicar a la aplicación, la ubicación de las grabaciones de las llamadas.

Posibles valores: s3-do, s3-aws, nfs, disk, local.

Hay opciones que están acotadas al escenario en donde los componentes ACD (asterisk) y OMLApp comparten el Linux host. En éste sentido, la opción local implica que las grabaciones sean guardadas en el dispositivo de bloque (partición o disco) que aloja la instalación de Linux. La otra opción es indicar disk en donde la idea es apuntar a un dispositivo de bloque o partición diferente a donde está instalado Linux, lo cual proporciona cierta robustez al dejar las grabaciones en una ubicación exclusiva y separada de la instalación.

Por otro lado, tenemos la obligación de utilizar un recurso compartido para almacenar grabaciones cuando los componentes ACD (Asterisk) y OMLApp (django/uwsgi) se ubican en instancias Linux independientes.

Aquí podemos usar el concepto de bucket en object storage DB o NFS. Las opciones s3-do o s3-aws, son para trabajar con bucket en la nube de DigitalOcean o AWS, respectivamente. Si bien el integrador que despliegue un cluster de OMniLeads podría tranquilamente utilizar cualquier otro object sStorage que permita montar el bucket en Linux utilizando fuse-s3 (https://github.com/s3fs-fuse/s3fs-fuse), debería proceder ejecutando una instalación con la opción local y luego ajustar manualmente la configuración necesaria para conseguir que las grabaciones se almacenen en dicho object storage.

Con respecto al uso de NFS para guardar las grabaciones, podemos utilizar cualquier herramienta que proporcione almacenamiento de red NFS.

s3_access_key, s3_secret_key, s3url y ast_bucket_name

Éstas variables sólamente son necesarias cuando se utiliza el object storage DB de DigitalOcean o AWS (a excepción de s3url que es sólo para DigitalOcean). Allí se debe indicar las claves para autenticarse en spaces, junto al URL y nombre del bucket que va a contener las grabaciones.

nfs_host

Ésta variable es necesaria asignar sólamente cuando se utiliza NFS como recurso de almacenamiento de grabaciones.

optoml_device

Aquí se indica el nombre del disco o partición exclusiva que se desea montar sobre el filesystem, para utilizar como directorio donde se instala la aplicación OMniLeads, es decir a donde se va a montar el path /opt/omnileads.

Posibles valores: NULL, /dev/….

Importante

Si no desea utilizar ningún dispositivo/partición, se debe colocar NULL.

pgsql_device

Aquí se indica el nombre del disco o partición exclusiva que se desea montar sobre el filesystem, para utilizar como directorio donde se ubica las bases de datos PostgreSQL, es decir a donde se va a montar el path /var/lib/pgsql.

El hecho de utilizar un dispositivo/partición aquí, tiene sentido si es que PostgreSQL va a convivir con OMLApp en el mismo Linux host.

Posibles valores: NULL, /dev/….

Importante

Si no desea utilizar ningún dispositivo/partición, se debe colocar NULL.

oml_nic

Aquí debemos indicar la interfaz de red sobre la que se levanta el puerto TCP 443 que va a procesar las solicitudes HTTPS.

Importante

Idealmente, se debe proporcionar una interfaz ubicada en una subnet privada y utilizar algún componente load balancer o proxy/firewall que conecte con la subnet pública, en el caso de necesitar habilitar acceso de usuarios desde Internet.

oml_ami_user y oml_ami_password

Éstas 2 variables, son para definir el usuario y password que utilizará OMLApp para conectarse a la API de Asterisk AMI.

Importante

Si estamos en un escenario donde Asterisk y OMLApp corren en Linux host independientes, entonces aquí debemos poner los valores utilizados para instalar el componente ACD (Asterisk).

oml_acd_host

Aquí indicamos la dirección de red del componente ACD (Asterisk), en el caso de que corra en un Linux host diferente a OMLApp.

Importante

En caso de estar compartiendo host OMLApp y ACD (Asterisk), se debe colocar explícitamente NULL.

oml_pgsql_host y oml_pgsql_port

Las 2 variables hacen referencia a la dirección de red y puerto en donde el componente PostgreSQL recibe las peticiones de OMLApp.

Importante

En caso de estar compartiendo host OMLApp y PostgreSQL, se debe colocar explícitamente NULL.

oml_pgsql_db, oml_pgsql_user y oml_pgsql_password

Las 3 variables tienen que ver con el nombre de la base de datos donde se crearán todas las tablas necesarias, junto al usuario y password que tendrá permitido interactuar con las mismas.

OMLApp utilizará éstas variables para interactuar con el motor PostgreSQL.

oml_pgsql_cloud

Ésta variable sirve para indicarle al instalador de OMLApp que instale la extensión PLPERL, por lo que sólamente hay que ponerla en «true» cuando el PostgreSQL-11 que vamos a utilizar como motor, es proporcionado llave en mano, es decir cuando (ya sea en un ambiente onpremise o cloud) el componente es instalado SIN utilizar el RPM que proporciona OMniLeads.

Posibles valores: true, false.

api_dialer_user y api_dialer_password

Aquí se definen los parámetros que OMLApp utilizará para autenticarse con la API de WombatDialer.

oml_dialer_host

En caso de desplegar WombatDialer sobre un Linux host dedicado, se debe indicar la dirección de red para que OMLApp pueda alcanzarlo.

Posibles valores: dirección_de_red, NULL.

oml_rtpengine_host, oml_kamailio_host, oml_redis_host, oml_websocket_host y oml_websocket_port

Ésta colección de variables hacen alusión al hecho de declarar la ubicación de los componentes relacionados. Cada uno de éstos componentes que estén alojados en un Linux host dedicado y aislado de OMLApp, deberán ser declarados con su dirección de red, y puerto (en caso de websocket).

Si los componentes conviven dentro del mismo host que OMLApp, entonces se deben declarar como NULL.

oml_extern_ip

En caso de estar en un ambiente en donde los componentes ACD (Asterisk) y RTPEngine conviven con OMLApp, entonces aquí se debe indicar la dirección de red pública que está afectando a nivel de NAT a nuestro despliegue.

Posibles valores: none, auto, X.X.X.X.

El valor none implica que no vamos a utilizar accesos desde Internet a la aplicación; si se configura como auto entonces la instalación intentará detectar la IP pública con la cual se está realizando NAT a los paquetes que salen a Internet; y finalmente también es viable declarar la dirección de red pública explícita (X.X.X.X).

oml_tz

Aquí se indica la zona horaria donde correrá la instancia de OMniLeads.

oml_app_sca

El tiempo de sesión (en segundos) para aplicar al login de usuario por HTTPS.

oml_app_ecctl

El tiempo de rotación de las credenciales efímeras con las que se autentica un usuario a nivel SIP over websocket contra Kamailio.

oml_app_login_fail_limit

La cantidad de intentos fallidos de ingresos HTTPS por parte de los usuarios, hasta ser bloqueados por Django-Defender.

oml_app_init_env

Éste parámetro se indica como true en caso de querer incializar la instancia de OMniLeads con registros en la DB (usuarios, troncales, campañas, etc.) de prueba.

oml_app_reset_admin_pass

Éste parámetro debe ir a true en una instalación fresca, ya que se encarga de indicar que se aplique un blanqueo de password para el usuario admin. Si estamos en un ambiente donde las actualizaciones se plantean como destrucción/creación de una instancia, entonces hay que tener en cuenta que debemos poner a false esta variable, para que no vuelva a resetear el password de admin.

oml_app_install_sngrep

En el caso de que Kamailio y/o Asterisk se ejecuten en el mismo Linux host que OMLApp, podemos setear éste parámetro en true para que el instalador despliegue la aplicación «sngrep» sobre la instancia.