O
O
Omnileads Docs
Español
Hacer una pregunta…
K
Links

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:
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
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_version: 1.33.0
websockets_version: 230204.01
nginx_version: 230215.01
kamailio_version: 230204.01
asterisk_version: 230204.01
fastagi_version: 230204.01
rtpengine_version: 230204.01
postgres_version: 230204.01
redis_version: 230204.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_version: stable-190112.01
websockets_version: 190112.01
nginx_version: 190112.01
kamailio_version: 190112.01
asterisk_version: 190112.01
rtpengine_version: 190112.01
postgres_version: 190112.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.
Última actualización 1mo ago