Backups, Restores, Upgrades y Rollbacks

Realizando un Backup

Los archivos de backup involucran por un lado, archivos de configuración personalizados de Asterisk (/etc/asterisk/custom). Por otro lado, se efectúa un respaldo de la Base de Datos Relacional de Postgres.

Para correr un backup, se debe ejecutar el siguiente script:

./deploy.sh --action=backup --tenant=<tenant-folder>

Dicho respaldo es depositado en el Bucket asociado a la instancia durante su proceso de despliegue. Recordemos que los escenarios expuestos permiten incorporar MinIO como bucket por default, o bien sumar soluciones populares de Cloud Providers orientadas a Object Storage, como Spaces (Digital Ocean) o S3 (Amazon).

Dentro del bucket, se observará una carpeta de backup con un archivo .sql precedido por el timestamp de ejecución (marca de tiempo). A su vez, otro directorio contará con los respaldos de Asterisk correspondientes.

Realizando un Recovery

Frente a un escenario de Disaster, es posible proceder a un Fresh Install de una instancia productiva y aplicar una acción de restauración de información desde un backup (Recovery).

Para que ésto suceda de manera efectiva, debemos modificar los últimos dos parámetros del inventory.yml correspondiente a nuestra carpeta de tenants. Ésto último es necesario para indicar que el bucket no maneja certificados confiables, y para configurar el timestamp del backup a restaurar:

restore_file_timestamp: 1681215859 

De esta manera, ejecutando el siguiente script con la action "restore", se procederá a reinstaurar el backup tomado en el paso previo sobre la nueva instancia desplegada y contar asi con un ambiente recuperado:

./deploy.sh --action=restore --tenant=<tenant-folder>

Realizando un Upgrade

El Equipo de OMniLeads construye imágenes de todos los componentes que conforman su arquitectura (builds). Los mismos están hosteados en Docker Hub en el siguiente enlace:

Docker

Es importante diferenciar el Repositorio principal de Aplicación (Web) del resto de los repositorios de componentes (asterisk, rtpengine, kamailio, nginx, websockets y postgres).

La Web App utiliza una semántica de definición de releases que implica RC (releases candidatos) y STABLE (releases aptos para ambientes productivos), como se observa a continuación:

pre-release-X.Y.Z
X.Y.Z

Sin embargo, el resto de los componentes utilizan semánticas de fechas seguidas por el número de versión de dicho release, por ejemplo:

230204.01

Cada vez que un release de WebApp es liberado, el mismo se disponibiliza por medio de una imágen en el registro de containers (Container Registry). A su vez el archivo el archivo Releases-Notes.md en la raiz del repositorio es actualizado para contemplar un correcto "mapping" entre las versiones de los componentes y la versión del Release de aplicación.

Por lo tanto, para aplicar actualizaciones de manera correcta es importante "traernos" los últimos cambios correspondientes a la rama estable. Ésto lo logramos con el siguiente comando:

git pull origin main
git checkout release-1.33.3

A partir de alli, el próximo paso es actualizar el archivo inventory.yml (correspondiente al tenant) con la versión "target". Por ejemplo, "1.33.0" en la captura debajo:

omnileads_img: docker.io/omnileads/omlapp:240201.01
asterisk_img: docker.io/omnileads/asterisk:240102.01
fastagi_img: docker.io/omnileads/fastagi:240104.01
astami_img: docker.io/omnileads/astami:231230.01
nginx_img: docker.io/omnileads/nginx:240105.01
websockets_img: docker.io/omnileads/websockets:231125.01
kamailio_img: docker.io/omnileads/kamailio:231125.01
rtpengine_img: docker.io/omnileads/rtpengine:231125.01
redis_img: docker.io/omnileads/redis:231125.01

Por último, procedemos a ejecutar el script con la acción "upgrade" a los efectos de proceder a la actualización del/de el/los componente/s en cuestión.

./deploy.sh --action=upgrade --tenant=<tenant_folder>

Realizando un Rollback

El uso de Contenedores en OMniLeads permite ejecutar procedimientos de rollbacks de manera rápida y segura. De esta manera podemos recuperar las versiones previas a la actualización en caso la misma no haya generado resultados satisfactorios.

omnileads_img: docker.io/omnileads/omlapp:240117.01
asterisk_img: docker.io/omnileads/asterisk:240102.01
fastagi_img: docker.io/omnileads/fastagi:240104.01
astami_img: docker.io/omnileads/astami:231230.01
nginx_img: docker.io/omnileads/nginx:240105.01
websockets_img: docker.io/omnileads/websockets:231125.01
kamailio_img: docker.io/omnileads/kamailio:231125.01
rtpengine_img: docker.io/omnileads/rtpengine:231125.01
redis_img: docker.io/omnileads/redis:231125.01

Con el inventory.yml modificado, es posible entonces volver a la versión previa al cambio:

./deploy.sh --action=upgrade --tenant=tenant_name_folder

Para mayor información, sugerimos visitar la documentación expuesta en el repositorio oficial del proyecto.