Deploy del componente Asterisk

Como es sabido, Asterisk implementa un script de fisrt_boot_installer.tpl, que puede ser invocado utilizando tecnología de provisioning o bien ser ejecutado manualmente con una previa parametrización de las variables implicadas.

Para obtener nuestro script, lanzar el siguiente comando:

curl https://gitlab.com/omnileads/omlacd/-/raw/master/deploy/first_boot_installer.tpl?inline=false > first_boot_installer.sh && chmod +x first_boot_installer.sh

Entonces, una vez que contamos con el script, pasamos a trabajar las variables, quitando comentarios y configurando sus valores dentro del propio script. Vamos a listar y explicar cada una de éstas variables que deben ser ajustadas antes de ejecutar el script.

Variables de instalación

  • 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_acd_release: Aquí se debe indicar qué release se desea desplegar.

  • 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_app_host: La dirección de red del Linux host que aloja el componente OMLApp. Ésto es necesario para realizar la conexión hacia Nginx y así terminar genrando la suscripción al Websocket-Python para aprovisionamiento de los archivos de configuración (etc/asterisk).

  • oml_redis_host: La dirección de red del Linux host que aloja el componente Redis. El dialplan de Asterisk se apoya en AGIs y consultas a Redis a la hora de aplicar las reglas de negocio sobre cada llamada.

  • oml_pgsql_host y oml_pgsql_port: Dirección de red y puerto para establecer conexiones a PostgreSQL.

  • oml_pgsql_db, oml_pgsql_user y oml_pgsql_password: Aquí citamos 3 parámetros vinculados entre sí, que son el nombre de la base de datos que va a alojar todas las tablas necesarias, el usuario y el password admitido para acceder a dicha base de datos.

  • 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.

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

    Al estar en un escenario donde Asterisk (ACD) corre sobre un Linux host exclusivo, mientras que el componente OMLApp se encuentra en otro host, estamos OBLIGADOS a que las grabaciones sean almacenadas en un dispositivo de red que pueda ser accedido por OMLApp.

    Por lo tanto, tenemos 2 posibilidades: S3 object storage o NFS.

    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 storage 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.

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

  • s3_access_key, s3_secret_key, s3url y ast_bucket_name: Éstas variables solamente 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.

Ejecución de la instalación

Nota

Al instalar Asterisk como componente aislado de OMLApp, debemos asegurarnos de que vamos a utilizar algún tipo de almacenamiento de red para las grabaciones, ya que de lo contrario, será inviable el acceso a las grabaciones desde la vista de búsqueda.

Debemos trabajar con S3 object storage o NFS.

_images/install_asterisk_callrec.png

Grabaciones almacenadas en recurso desde Asterisk y accedido desde OMLApp

Finalmente, podemos lanzar nuestro script first-boot-instaler.sh. Ésto lo podemos hacer como user_data de una instancia cloud, a través de alguna utilidad de línea de comandos para administrar la infraestructura, o bien directamente copiando el archivo hacia el Linux host destino y lanzando la ejecución del mismo.

Para comprobar que el componente se encuentra operativo, debemos lanzar el siguiente comando y observar la siguiente salida:

systemctl status asterisk
_images/install_asterisk_status.png