Asterisk Deployment

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, se debe 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

So, once we have the script, we go to work on the variables, removing comments and setting their values ​​inside the script. We are going to list and explain each of these variables that should be set before running the script.

Installation Variables

  • 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í debemos indicar qué versión del componente se desea desplegar. Para ello, se deberá revisar el archivo .gitmodules de la versión de OMniLeads que se desee desplegar, y tomar el parámetro branch del componente, como valor de ésta variable.

  • oml_nat_ipaddr: En el caso que Asterisk necesite salir hacia un destino/proveedor en la nube, con una IP pública particular como IP externa (external_media_address), se puede setear dicha IP en éste campo. Si se deje en NULL, la IP pública será auto-detectada.

  • oml_tz: Se indica aquí la zona horaria de la instancia.

  • 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 generando la suscripción al Websocket-Python para aprovisionamiento de los archivos de configuración (etc/asterisk).

  • oml_redis_host: The network address of the Linux instance hosting the Redis component. Asterisk’s dialplan relies on AGIs and queries to Redis when applying the business rules on each call.

  • oml_pgsql_host and oml_pgsql_port: Network address and port for establishing connections to PostgreSQL.

  • oml_pgsql_db, oml_pgsql_user and oml_pgsql_password: Here we quote 3 parameters, which are the name of the database that will host all the necessary tables, the user and the password allowed to access that database.

  • oml_pgsql_ssl: Éste valor sirve para setear ODBC en modo SSL. Por defecto y para PSQL interno, dejarlo en NULL. Posibles valores: NULL, true.

  • oml_pgsql_cloud: Éste valor se debe setear en true si PostgreSQL corre en un cluster cloud. Por defecto y para PSQL interno, dejarlo en NULL. Posibles valores: NULL, true.

  • oml_ami_user and oml_ami_password: These 2 variables allow us to define the username and password that OMLApp will use to connect to the Asterisk AMI API.

  • oml_callrec_device: Here we should indicate to the application, the location of call recordings.

    Being in a scenario where Asterisk (ACD) runs on a Linux host, while the OMLApp component is on another host, we are OBLIGED to have the recordings stored in a network device that can be accessed by OMLApp.

    So we have 2 possibilities: S3 object storage or NFS.

    Here we can use the concept of bucket in object storage DB or NFS. The options s3-do or s3-aws, are available to work with bucket in the cloud from DigitalOcean or AWS, respectively. While the integrator that deploy a cluster of OMniLeads I could use any other storage object that allows the bucket to be mounted on Linux using fuse-s3 (https://github.com/s3fs-fuse/s3fs-fuse), it should proceed by running an install with the local option and then adjust manually the necessary settings to get the recordings stored in that object storage.

    Regarding the use of NFS to save the recordings, we can use any tool that provides NFS network storage.

    Posible Values: s3-do, s3-aws, nfs.

  • nfs_host: This variable is necessary to be assigned only when uses NFS as a storage resource for recordings.

  • s3_access_key, s3_secret_key, s3url y s3_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 deben indicar las claves para autenticarse en spaces, junto al URL y nombre del bucket que va a contener las grabaciones.

Con respecto a las variables implicadas para un despliegue en Alta Disponibilidad (HA), las mismas vienen comentadas por defecto. En caso de desplegar en HA, se deberán descomentar y completar:

  • oml_deploy_ha: En caso de desplegar un cluster de Asterisk, se debe indicar true.
  • oml_ha_rol: Se indica si el nodo Asterisk a desplegar va a ser main o backup.
  • oml_ha_vip: Se indica la dirección de red de la VIP sobre la cual se levantará el servicio.
  • oml_ha_vip_nic: Se indica la interfaz de red sobre la cual se levantá la VIP.
  • oml_ha_tenant: Se indica el nombre del tenant.
  • oml_ha_email: Se introduce un e-mail para notificación de failovers.

Installation Execution

Note

When installing Asterisk as an isolated component of OMLApp, we need to make sure we are going to use some kind of network storage for recordings, since otherwise, access to recordings will be unfeasible from search view.

We should work with S3 object storage or NFS.

_images/install_asterisk_callrec.png

Recordings stored on resource from Asterisk and accessed from OMLApp

Finally, we can launch the script first-boot-instaler.sh. This can be done as user_data of a cloud instance, through some command line utility to manage the infrastructure, or directly copying the file to the destination Linux host and launching the execution of it.

Una vez ejecutado el script y finalizado el deploy, debemos comprobar que el componente se encuentra operativo, lanzando el siguiente comando:

systemctl status asterisk
_images/install_asterisk_status.png