Обидві команди дають один і той самий PearlPBX2 — ту саму адмінку, ті самі черги, той самий дашборд. Різниця не в продукті, а в усьому, що навколо нього: TLS, бекапи, фаєрвол, крон і те, як медіа-трафік дістається до вашого телефона.
Дві команди
# Пісочниця в Docker — клонує в ./PearlPBX2
curl -fsSL https://pearlpbx2.com/quickstart-docker.sh | bash
# Production-встановлення — клонує в /opt/PearlPBX2
curl -fsSL https://pearlpbx2.com/quickstart-install.sh | sudo bashПерша займає стільки, скільки Docker тягтиме образи. Друга — 15–30 хвилин, бо Asterisk 22 збирається з джерел. Обидві наприкінці друкують логін і згенерований пароль адміністратора.
Що насправді ставить кожен шлях
quickstart-install.sh — це обгортка над Ansible. Дев’ять ролей ставлять PostgreSQL, Redis, Asterisk 22, nginx із
TLS, systemd-юніти для сервісів, правила nftables і крон. Встановлення
повністю автономне: воно визначає SSH-порт і записує його в лог перед застосуванням правил фаєрвола, без
підтвердження.
quickstart-docker.sh перевіряє, що Docker і Compose v2 на місці, генерує .env і піднімає стек: Django,
andrius/asterisk:22, PostgreSQL 17, Redis 7, FastAGI і dashboard-listener. Django слухає порт 8000 без nginx і без
TLS, у режимі DEVMODE=Development. Asterisk отримує опубліковані порти 5060/udp, 5060/tcp, 10000-10099/udp
і 8088/tcp у bridge-мережі. Демо-дані вже засіяні: користувачі 201–210, ехо-тест 130, IVR 140, черги 141 і 142.
SIP, NAT і чому це залежить від вашої ОС
Тут проходить головна лінія розлому, і вона не про PearlPBX2, а про те, як влаштований сам Docker на різних системах.
На Linux мережа контейнерів — звичайний інтерфейс на хості. Підмережа 172.x маршрутизована, софтфон на тій самій
машині достукається до Asterisk і напряму, і через опубліковані порти.
На macOS і Windows Docker Desktop тримає контейнери у прихованій Linux-VM. Підмережі контейнерів з хоста не видно
взагалі — працює лише те, що опубліковано на localhost. Сигналізація SIP через це проходить, порт 5060
опублікований. А от медіа ламається в класичний спосіб: Asterisk кладе в SDP ту адресу, яку бачить у себе, тобто
адресу контейнера, і софтфон намагається слати RTP у нікуди.
Лікується це тим самим, чим і будь-який NAT перед Asterisk: у транспорті PJSIP задати external_media_address і
external_signaling_address на адресу, до якої клієнт справді достукається, і покластися на симетричний RTP, щоб
Asterisk відповідав туди, звідки прийшли пакети. Тобто «SIP у Docker на ноутбуці» — це не «не працює», а «потребує
тих самих налаштувань NAT, що й будь-яка інсталяція за роутером».
Побічний ефект, про який варто знати заздалегідь: сотня опублікованих UDP-портів під RTP на Docker Desktop помітно
сповільнює docker compose up.
Чому WebRTC поводиться інакше
WebRTC у цю пастку не потрапляє, і саме тому Docker-пісочниця добре підходить, щоб показати браузерні дзвінки.
Браузер не покладається на адресу з SDP так само сліпо: він збирає ICE-кандидатів, шле медіа першим, а Asterisk відповідає на адресу, з якої пакети прийшли. Зовнішню адресу вручну задавати не доводиться. До того ж медіа в WebRTC зашифроване завжди — DTLS-SRTP не можна «забути ввімкнути», це вимога специфікації.
Одне уточнення: compose публікує порт 8088, а це ws, не wss. На localhost цього достатньо, бо браузери вважають
localhost безпечним контекстом і дають доступ до мікрофона. Щойно ви захочете зайти з іншої машини, знадобиться
WSS-транспорт і справжній сертифікат — тобто те, що production-шлях налаштовує сам.
Чого в Docker немає взагалі: крон
Це найменш очевидна відмінність і водночас та, яку найдорожче виявити через півроку. Ansible ставить сім періодичних задач, у Docker-стеку немає жодної:
- Бекап PostgreSQL — щодня о 01:30.
- Бекап
/etc/asterisk— щодня о 02:30. - Конвертація записів wav → mp3 — кожні 15 хвилин.
- Вивантаження mp3 — щодня о 03:00.
- Моніторинг системи — кожні 15 хвилин.
- Ротація логів Asterisk — щодня.
- Поштовий звіт про найдовші дзвінки — щодня о 06:00, якщо задані отримувачі.
На практиці це означає, що в пісочниці записи розмов лишаються у wav і диск росте лінійно від кількості дзвінків, бекапів бази немає, а логи Asterisk ніхто не підрізає. Для тижневого тесту це не має значення. Для системи, якою хтось користується щодня, — має.
Дрібніші відмінності, які все одно варто знати
- Таймзона. Ansible виставляє
Europe/Kyiv, контейнери за замовчуванням у UTC — це видно в CDR і звітах. - Демон зворотних дзвінків у Docker вимкнений за замовчуванням: він робить справжні вихідні дзвінки, тому
вмикається окремо через
--profile callback. - Дані живуть у named volumes.
docker compose downїх зберігає,down -vстирає все, включно з базою. - Оновлюватись і відкочуватись нічим:
update.shіrollback.sh -nспираються на журнал розгортань, якого в Docker-шляху просто немає.
Що обрати
Подивитись, як воно виглядає, зібрати схему дзвінків, показати WebRTC колезі, погратися з dialplan — Docker. Він для цього й зроблений, і працює на будь-якій ОС.
Приймати справжні дзвінки, зберігати записи, спати спокійно — install.sh на чистій Debian або Ubuntu. Різниця не
в самому PearlPBX2, а в тому, що навколо нього хтось має стежити за бекапами, диском і сертифікатами. У
production-шляху це вже налаштовано.