Backups, Restores, Upgrades y Rollbacks
Última actualización
Última actualización
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:
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.
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:
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:
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:
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:
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:
A partir de alli, el próximo paso es actualizar el archivo inventory.yml (correspondiente al tenant) con la versión "target". Por ejemplo, "2.X.X" en la captura debajo:
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.
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.
Con el inventory.yml modificado, es posible entonces volver a la versión previa al cambio:
Para mayor información, sugerimos visitar la documentación expuesta en el .
