Instalación de OMniLeads¶
Antes de avanzar con la instalación, se recomienda leer y entender (Arquitectura y componentes).
Como se ha descripto en la sección de arquitectura, cada componente cuenta con un script de instalación potencialmente utilizable como provisioner en el momento de creación de la máquina virtual Linux que alojará al componente en cuestión. También, es viable ejecutarlo en modo self-hosted a la hora de desplegar el componente sobre un Linux host, es decir vertiendo el contenido de first_boot_installer.tpl sobre el bash-script ubicado en la virtual machine a desplegar, ajustando las variables y finalmente lanzando la ejecución del mismo.
Por lo tanto, tenemos distintas formas de llegar al objetivo de instalar OMniLeads, algunas totalmente automatizadas, y otras dentro de un esquema bien tradicional basado en el hecho de ejecutar un script de instalación manualmente.
Nota
Las distribuciones Linux sobre las cuales se garantiza compatibilidad son CentOS7-Minimal y Amazon Linux 2.
A continuación, se plantean diferentes escenarios correspondientes a formatos desplegables.
Deploy de OMniLeads sobre Bare-Metal o Virtual Machine Linux¶
OMniLeads puede correr como una aplicación tradicional, desplegando una instalación de todos los componentes sobre un único host. A éste tipo de instalación, la llamamos OMniLeads AIO (All In One).
También, podemos separar los componentes de manera tal que puedan ser ejecutados como servicios aislados corriendo sobre hosts dedicados. Ésto significa que podemos separar componentes sobre hosts dedicados con el fin de pararnos sobre una operación más robusta y resiliente, ya que entre otras ventajas, permite aislar/resguardar información como grabaciones de llamadas, base de datos, etc. Al mismo tiempo, es más eficiente para la gestión de actualizaciones y monitoreo de la aplicación.
La propuesta de las aplicaciones web modernas orientadas a aprovechar la sencillez que implica obtener una instancia Linux limpia (vía web o API) y aprovisionar la misma con un componente o servicio, implica considerar la idea de componentes aislados sobre instancias Linux que interactúan (networking) con otros servicios, distribuidos en otras instancias, conformando un cluster de componentes OMniLeads. De ésta manera, queda cada componente sobre un Linux host con su stack de networking, gestor de paquetes, memoria, CPU, kernel, etc., lo cual nos ayuda a la hora de redimensionar la infraestructura para escalar, efectuar troubleshooting o diagnóstico sobre la operación, efectuar un monitoreo orientado a servicios, entre varias ventajas más.
Nota
Es moneda corriente que los proveedores de infraestructura cloud a la hora de cobrar el arrendamiento de recursos, nos cobren los mismo por mantener N instancias con M recursos, que mantener una sola gran instancia instancia con NxM recursos.
En esta sección, cubrimos la instalación más convencional: Ejecución del deploy sobre instancias Linux.
Deploy de OMniLeads basado en Terraform¶
A partir de la versión 1.16, es posible utilizar Terraform para desplegar OMniLeads sobre algunas nubes concretas que se irán incrementando con el pasar del tiempo y el aporte de la comunidad.
Para quienes no estén familiarizados con Terraform y estén interesados en conocer, dejamos el enlace a su documentación. Terraform nos permite codificar un despliegue. En términos de Terraform, podemos definir un despliegue de OMniLeads, como el siguiente conjunto de acciones:
- Configuración de networking de la infraestructura.
- Creación de maquinas virtuales, clusters de DB, balanceadores de carga.
- Deploy de OMnileads y sus componentes sobre las máquinas virtuales.
- Aplicación de la configuración de seguridad.
- Generación de certificados SSL y URL de acceso para los usuarios.
Por lo tanto, usted puede simplemente configurar un archivo de variables y luego lanzar un comando (terraform apply), y en cuestión de minutos contar con un despliegue de OMniLeads «as a Service», listo para que nuestros usuarios puedan comenzar a operar desde cualquier punto geográfico.
Nota
El deploy de los componentes Jitsi Meet, WombatDialer y MySQL, es configurable de acuerdo a las necesidades de la operación sobre campañas predictivas y/o campañas de video atención.
El enfoque de desplegar en nube de infraestructura, nos permite automatizar completamente la generación de un suscriptor al servicio de Contact Center en la nube.
A continuación, el listado de nubes públicas soportadas: