Instalar, actualizar y revertir Asterisk con Ansible

Desplegar una centralita Asterisk a mano significa compilar desde el código fuente, una docena de archivos de configuración, secretos que hay que generar en algún sitio y un firewall que es fácil configurar de forma que te quedes sin acceso por SSH. PearlPBX2 cubre todo ese camino con un único playbook de Ansible y tres scripts: install.sh, update.sh y rollback.sh.

El inicio más rápido: un solo comando

En un servidor limpio con Debian o Ubuntu basta con un comando ejecutado como root:

curl -fsSL https://pearlpbx2.com/quickstart-install.sh | sudo bash

El script clona el repositorio, ejecuta el instalador de Ansible sin hacer ninguna pregunta y termina creando un usuario administrador con una contraseña generada.

Si solo quieres ver el producto, hay una variante con Docker. Docker debe estar ya instalado:

curl -fsSL https://pearlpbx2.com/quickstart-docker.sh | bash

También clona el repositorio, genera un .env, levanta el stack con Docker Compose y crea un usuario administrador con una contraseña generada. En qué se diferencian ambas rutas en la práctica se explica en Instalación con Docker vs. install.sh. El resto de este artículo trata de lo que ocurre dentro de la primera.

Un playbook, nueve roles

install.sh ejecuta un playbook de nueve roles de Ansible: system, postgres, redis, asterisk, pearlpbx2, services, nginx, tftp, firewall. Cada rol se encarga de una parte del stack, así que la instalación es repetible y se lee como una secuencia de pasos comprensibles, no como un único script largo.

Un décimo rol, asterisk_update, no participa en la instalación. Solo lo usa update-asterisk.sh, del que se habla más abajo.

Qué hace install.sh

install.sh compila Asterisk 22 desde el código fuente (la versión está fijada en 22.11.0, no es «la última»), genera todos los secretos necesarios, configura las tareas cron y aplica las reglas de firewall de nftables. Compilar tarda entre 15 y 30 minutos según la CPU, y el script lo avisa al principio.

Las tareas cron que el instalador configura por sí mismo:

• copia de seguridad de la base de datos cada día a las 01:30;
• copia de seguridad de la configuración de Asterisk cada día a las 02:30;
• rotación de los logs de Asterisk;
• conversión de las grabaciones de llamadas a mp3 cada 15 minutos y una exportación diaria a las 03:00;
• monitorización del sistema cada 15 minutos;
• un informe diario por correo con las llamadas más largas a las 06:00, si hay destinatarios configurados.

Los indicadores --domain <fqdn> y --email <dirección> sirven para el certificado de Let’s Encrypt, del que se habla más abajo.

Sin pausas ni preguntas

El instalador es totalmente desatendido. Antes de aplicar las reglas de nftables detecta el puerto SSH con sshd -T, es decir, el valor en el que sshd escuchará realmente, teniendo en cuenta todos los archivos de sshd_config.d, y abre justo ese puerto. El puerto detectado queda registrado en el log y la instalación continúa sin pedir confirmación.

Esto importa cuando no hay terminal: ansible-pull, CI o cualquier script ya no se queda colgado en una pregunta interactiva. Lo único que queda tras la instalación es crear un administrador con ./manage.sh createsuperuser. El script quickstart lo hace por ti.

HTTPS y wss:// sin configuración manual

WebRTC necesita un certificado TLS válido. El rol de nginx lo obtiene automáticamente, en tres niveles, según lo que tenga el servidor:

1. Si se indica un dominio (--domain), un certificado de Let’s Encrypt mediante HTTP-01.
2. Si no hay dominio pero se detecta una dirección IPv4 pública, el certificado de corta duración de Let’s Encrypt para direcciones IP.
3. En cualquier otro caso, un certificado autofirmado como alternativa.

Para los dos primeros niveles, la renovación automática la gestiona el temporizador pearlpbx2-certbot-renew. No hay ningún paso manual de TLS.

update.sh

Actualizar PearlPBX2 son dos pasos. Primero actualizas el clon del repositorio:

git pull
sudo ./update.sh

update.sh no descarga nada por sí mismo. Despliega el commit que esté seleccionado en ese momento en el clon: sincroniza el código con el directorio de instalación, actualiza las dependencias de Python, aplica las migraciones, recopila los archivos estáticos y reinicia PearlPBX2 y los servicios auxiliares. Así las actualizaciones son reproducibles: sabes exactamente qué commit se pone en producción, porque lo elegiste tú.

Antes de migrar, el playbook guarda el estado de las migraciones aplicadas y añade una entrada al registro de despliegues, que después usa rollback.sh. update.sh solo actualiza la aplicación. No toca nginx, el firewall ni los datos iniciales, así que es seguro ejecutarlo en un sistema en producción.

update-asterisk.sh: actualizar Asterisk en el mismo sitio

Puedes cambiar la versión de Asterisk por separado de PearlPBX2. update-asterisk.sh actualiza un Asterisk ya instalado en el mismo servidor, sin reinstalar. Por defecto la versión de destino se toma de group_vars/all.yml, y puedes indicar otra con --version X.Y.Z.

El orden de los pasos está pensado para que todo lo que pueda fallar ocurra mientras el Asterisk antiguo sigue atendiendo llamadas:

1. Primero se hace una copia de seguridad de /etc/asterisk, de los binarios, módulos y cabeceras, y de /var/lib/asterisk.
2. La nueva versión se compila mientras Asterisk sigue atendiendo llamadas.
3. Después Asterisk se detiene de forma ordenada: el script espera a que terminen las llamadas activas (hasta 15 minutos por defecto, ajustable con --timeout; --no-wait lo detiene de inmediato).
4. Solo se instalan los binarios y los módulos. Las configuraciones, los sonidos, los logs y el spool no se tocan.
5. Se reinician Asterisk y los servicios conectados por AMI.

Este script también tiene su propia reversión: update-asterisk.sh --rollback restaura la versión anterior desde la copia de seguridad, y --list muestra el historial de actualizaciones. --restore-configs y --restore-sounds restauran además la configuración y los sonidos.

rollback.sh: el registro de estados de despliegue

Si una actualización sale mal, rollback.sh -n <número de pasos> devuelve el código, las migraciones de la base de datos y los servicios a un estado de despliegue anterior. El mecanismo mantiene un registro (el deploy-state ledger) de cada despliegue, así que revertir no es intentar «restaurar una copia de seguridad y esperar lo mejor», sino una operación controlada con un resultado conocido.

Lo que conviene saber sobre la reversión:

• rollback.sh --list muestra el historial de despliegues y no cambia nada. Antes de revertir puedes ver a qué commit volverás.
• El script te pide escribir yes para confirmar. La opción -y se salta la pregunta, por ejemplo en automatizaciones.
• El registro guarda los diez últimos despliegues, así que puedes retroceder como máximo diez pasos.
• Las migraciones se revierten primero, mientras los archivos de las migraciones nuevas siguen en disco: Django los necesita para calcular el camino de vuelta. Solo después el código vuelve al commit de destino.
• Si el clon del repositorio tiene cambios sin confirmar, la reversión se detiene y te explica por qué. De lo contrario, git checkout destruiría tu trabajo en silencio.
• Tras una reversión, se eliminan las entradas del registro más recientes que el commit de destino, porque ya no son puntos de retorno válidos.

Docker Compose para evaluación y CI

Para ver el producto rápido sin esperar a un despliegue completo con Ansible existe docker compose up: Django, Asterisk, PostgreSQL, Redis, FastAGI y el listener del dashboard. El demonio de devolución de llamadas se añade por separado con --profile callback, porque realiza llamadas salientes reales. Un archivo docker-compose aparte para las pruebas de integración ejecuta el directorio tests/integration contra un contenedor real de Asterisk 22 en CI, no contra mocks.

Dónde funciona el instalador automático

La ruta de Ansible (install.sh y el script quickstart para producción) está pensada para Debian y Ubuntu, las distribuciones admitidas para la instalación automatizada. Para evaluación, desarrollo o CI en cualquier otro sistema existe Docker Compose: el mismo stack, sin depender de una distribución concreta en el host.

Resumen

PearlPBX2 se instala con un solo comando o con un playbook de Ansible de nueve roles, sin pausas, obtiene por sí mismo su certificado HTTPS, se actualiza de forma controlada con update.sh y se revierte desde un registro de estados con rollback.sh -n. Asterisk se actualiza aparte con update-asterisk.sh. Para evaluación y CI existe Docker Compose con un Asterisk 22 real en un contenedor.