Встановлення, оновлення й rollback Asterisk через Ansible

Розгортання Asterisk PBX вручну означає компіляцію з джерел, десяток конфігураційних файлів, секрети, які треба десь згенерувати, і фаєрвол, який легко налаштувати так, що втратиш доступ по SSH. PearlPBX2 закриває весь цей шлях одним Ansible-плейбуком і трьома скриптами: install.sh, update.sh, rollback.sh.

Найшвидший старт: одна команда

На чистому сервері з Debian або Ubuntu достатньо однієї команди від імені root:

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

Скрипт клонує репозиторій, запускає Ansible-інсталятор без жодних запитань і в кінці створює адміністратора зі згенерованим паролем.

Якщо потрібно лише подивитися продукт, є Docker-варіант. Docker має бути вже встановлений:

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

Він теж клонує репозиторій, генерує .env, піднімає стек через Docker Compose і створює адміністратора зі згенерованим паролем. Чим ці два шляхи відрізняються на практиці, розібрано в статті Чим Docker-встановлення відрізняється від install.sh. Нижче йдеться про те, що відбувається всередині першого варіанта.

Один плейбук, дев’ять ролей

install.sh запускає плейбук із дев’яти Ansible-ролей: system, postgres, redis, asterisk, pearlpbx2, services, nginx, tftp, firewall. Кожна роль відповідає за свою частину стеку, тож встановлення відтворюване й читається як послідовність зрозумілих кроків, а не один суцільний скрипт.

Десята роль, asterisk_update, в установці не бере участі: її використовує лише update-asterisk.sh, про який нижче.

Що робить install.sh

install.sh компілює Asterisk 22 із джерел (версія зафіксована як 22.11.0, а не «остання»), генерує всі потрібні секрети, налаштовує cron-задачі й застосовує правила фаєрвола nftables. Компіляція займає 15–30 хвилин залежно від процесора, про що скрипт попереджає на початку.

Cron-задачі, які інсталятор ставить сам:

бекап бази даних щодня о 01:30;
бекап конфігурації Asterisk щодня о 02:30;
ротація логів Asterisk;
конвертація записів розмов у mp3 кожні 15 хвилин і щоденне вивантаження о 03:00;
моніторинг системи кожні 15 хвилин;
щоденний email-звіт про найдовші дзвінки о 06:00, якщо в налаштуваннях вказані отримувачі.

Прапори --domain <fqdn> і --email <адреса> потрібні для сертифіката Let’s Encrypt, про що нижче.

Без пауз і запитань

Інсталятор повністю автономний. Перед застосуванням правил nftables він визначає SSH-порт командою sshd -T, тобто бере значення, на якому sshd справді слухатиме, з урахуванням усіх файлів у sshd_config.d, і відкриває саме його. Знайдений порт потрапляє в лог, а установка йде далі без підтвердження.

Це важливо для запуску без термінала: ansible-pull, CI або будь-який скрипт більше не зависають на інтерактивному запитанні. Єдине, що лишається після установки, це створити адміністратора командою ./manage.sh createsuperuser. Quickstart-скрипт робить це сам.

HTTPS і wss:// без ручного налаштування

Щоб WebRTC працював, потрібен коректний TLS-сертифікат. Nginx-роль отримує його автоматично, у три рівні, залежно від того, що є на сервері:

Якщо вказано домен (--domain), сертифікат Let’s Encrypt через HTTP-01.
Якщо домену немає, але виявлено публічну IPv4-адресу, короткоживучий сертифікат Let’s Encrypt для IP-адреси.
В інших випадках самопідписаний сертифікат як запасний варіант.

Для перших двох рівнів автоматичне поновлення налаштовується таймером pearlpbx2-certbot-renew. Ручний крок із TLS не потрібен.

update.sh

Оновлення PearlPBX2 складається з двох кроків. Спершу ви оновлюєте клон репозиторію:

git pull
sudo ./update.sh

update.sh сам нічого не завантажує. Він розгортає той коміт, який зараз відкритий у клоні: синхронізує код у каталог установки, оновлює Python-залежності, застосовує міграції, збирає статику й перезапускає PearlPBX2 та допоміжні сервіси. Тому оновлення завжди відтворюване: ви точно знаєте, який коміт піде в роботу, бо самі його вибрали.

Перед міграціями плейбук записує стан застосованих міграцій і додає запис у журнал деплоїв, який потім використовує rollback.sh. update.sh оновлює лише застосунок: nginx, фаєрвол і початкові дані він не чіпає, тож його безпечно запускати на робочій системі.

update-asterisk.sh: оновлення Asterisk на місці

Версію Asterisk можна змінити окремо від самого PearlPBX2. update-asterisk.sh оновлює вже встановлений Asterisk на тому ж сервері, без нової установки. За замовчуванням цільова версія береться з group_vars/all.yml, а іншу можна вказати прапором --version X.Y.Z.

Порядок кроків підібраний так, щоб усе, що може зламатися, відбувалося, поки старий Asterisk ще приймає дзвінки:

Спершу робиться резервна копія /etc/asterisk, бінарників, модулів і заголовків та /var/lib/asterisk.
Нова версія компілюється, поки Asterisk продовжує обслуговувати дзвінки.
Далі Asterisk зупиняється м’яко: скрипт чекає, поки завершаться активні розмови (до 15 хвилин за замовчуванням, змінюється через --timeout; --no-wait зупиняє одразу).
Встановлюються лише бінарники й модулі. Конфігурації, звуки, логи й spool не чіпаються.
Asterisk і сервіси, підключені через AMI, перезапускаються.

Для цього скрипта теж є відкат: update-asterisk.sh --rollback повертає попередню версію з резервної копії, а --list показує історію оновлень. Опції --restore-configs і --restore-sounds повертають додатково конфігурацію та звуки.

rollback.sh: журнал станів деплою

Якщо оновлення пішло не так, rollback.sh -n <кількість кроків> відкочує код, міграції бази даних і сервіси до попереднього стану деплою. Механізм тримає журнал (deploy-state ledger) для кожного розгортання, тож відкат не є спробою «відновити з бекапу і сподіватись», а керованою операцією з відомим результатом.

Що корисно знати про відкат:

rollback.sh --list показує історію деплоїв і нічого не змінює. Перед відкатом можна побачити, на який коміт ви потрапите.
Скрипт просить набрати yes для підтвердження. Прапор -y пропускає запитання, наприклад для автоматизації.
Журнал зберігає десять останніх розгортань, тож назад можна піти не більше ніж на десять кроків.
Міграції відкочуються першими, поки на диску ще лежать файли нових міграцій: Django потрібні саме вони, щоб порахувати шлях назад. Лише потім код повертається на потрібний коміт.
Якщо в каталозі з клоном репозиторію є незакомічені зміни, відкат зупиняється з поясненням. Інакше git checkout мовчки знищив би вашу роботу.
Після відкату записи журналу новіші за цільовий коміт видаляються, бо вони більше не є валідними точками повернення.

Docker Compose для оцінки й CI

Для швидкої оцінки продукту без чекання на повне Ansible-розгортання є docker compose up: Django, Asterisk, PostgreSQL, Redis, FastAGI і слухач дашборда. Демон зворотних дзвінків додається окремо через --profile callback, бо він робить справжні вихідні дзвінки. Окремий docker-compose файл для інтеграційних тестів запускає каталог tests/integration проти справжнього контейнера Asterisk 22 у CI, а не проти моків.

Де саме працює автоматичний інсталятор

Ansible-шлях (install.sh і quickstart-скрипт для продакшна) орієнтований на Debian і Ubuntu, заявлені цільові дистрибутиви автоматизованого встановлення. Для оцінки, розробки чи CI на будь-якій іншій системі є Docker Compose, той самий стек, тільки без залежності від конкретного дистрибутива хоста.

Підсумок

PearlPBX2 ставиться однією командою або одним Ansible-плейбуком із дев’яти ролей без жодних пауз, сам отримує HTTPS-сертифікат, оновлюється керовано через update.sh і відкочується за журналом станів через rollback.sh -n. Asterisk оновлюється окремо через update-asterisk.sh. Для оцінки й CI є Docker Compose зі справжнім Asterisk 22 у контейнері.