🇪🇸
Omnileads Docs
ComunidadForo
Español
Español
  • 👶Introducción a OMniLeads
    • Características Generales de OMniLeads
    • Arquitectura y componentes
  • 🚀Instalación de OMniLeads
    • Deploy utilizando Docker
      • Deploy en Docker-Destkop
      • Deploy en Docker para VPS Cloud o VM
      • Deploy en Docker para VPS Cloud o VM con Bucket Externo
    • Deploy utilizando Ansible
      • Deploy en AIO (All-In-One)
      • Deploy en AIT (All-In-Three)
      • Deploy en HA (High Availability)
      • Backups, Restores, Upgrades y Rollbacks
      • Migración desde CentOS7
    • OMniLeads Enterprise
    • Deploy en Entornos de Desarrollo
    • First Login
    • Certificados TLS/SSL
    • Monitoreo y Observabilidad
    • Consideraciones de Seguridad
  • ⚙️Configuración inicial
  • 🪪Autenticación LDAP
  • 🎞️Video Llamadas (Pro)
    • Configuración Inicial
    • Wordpress Plugin
    • Webphone Demo
    • Embebiendo el Webphone
  • 🎯CX Survey (Pro)
    • Reportería
  • 📈Reportes Premium (Pro)
    • Reportes de Actividad
    • Analizando Resultados
  • 🔊Text To Speech - TTS (Pro)
  • ☎️Configuración del Canal de Voz
    • Parámetros generales del SIP trunk
  • 🆗Configuración del Canal de Whatsapp (Pro)
    • OMniLeads y GupShup
    • Dar de Alta Whatsapp Business en GupShup
    • Plantillas de Mensajes y Grupos Horarios
    • Proveedores
    • Lineas
  • 🚧Wallboard for Business (Pro)
    • Creación de un Wallboard
    • Agregando Widgets y Páginas "realtime"
    • Explorando Widgets y Métricas
  • 📤Mensajes Masivos (Pro)
    • Creación de Envios
    • Campañas de Turnos
    • Exportación de Resultados
  • 💬Campañas de Contacto
    • Campaña Entrante
      • Enrutamiento de llamadas entrantes
      • Derivación de llamadas entrantes desde la PBX hacia OMniLeads
      • Enrutamiento condicionado por rango de tiempo
      • IVR - Interactive Voice Response
      • Identificación de llamada entrante
      • Ejecución de dialplan personalizado
    • Campaña Manual
    • Campaña Preview
    • Campaña Dialer
    • Campaña de Whatsapp
  • 🎧Manual de agente
    • Login Logout
    • Llamadas manuales desde listado de contactos
    • Llamadas preview
    • Llamadas en dialer
    • Llamadas entrantes
    • Llamadas entre agentes
    • Listado de Contactos
    • Mensajes de Whatsapp
  • 🛑Métricas, grabaciones y supervisión
    • Grabaciones
    • Reportes de campañas entrantes
    • Reportes de campañas salientes
    • Reporte general de llamadas
    • Reportes de agente
    • Reportes de Whatsapp
    • Reportes de Conversaciones
    • Supervisión
  • 📊Auditoría de gestiones
  • ☎️Integración entre OMniLeads y PBXs
  • 🛠️Gestiones del administrador IT
  • 🧩Integración con CRM
    • Interacción desde OMniLeads hacia el CRM
    • Interacción desde el CRM hacia OMniLeads
  • 🔐Consideraciones sobre seguridad
  • 📌OMniLeads RESTful API
    • API de sesión de Agente en Asterisk
  • 🗒️Release Notes
  • ❤️Comunidad
  • 🎇Acerca De
Con tecnología de GitBook
En esta página
  • Realizando un Backup
  • Realizando un Recovery
  • Realizando un Upgrade
  • Realizando un Rollback
  1. Instalación de OMniLeads
  2. Deploy utilizando Ansible

Backups, Restores, Upgrades y Rollbacks

Última actualización hace 1 mes

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 fetch all
git pull origin main
git checkout release-2.3.1

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:

omnileads_img: docker.io/omnileads/omlapp:250201.01
asterisk_img: docker.io/omnileads/asterisk:250102.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

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
Docker
Logo