Автодеплой SIP-стека без ручной сборки: где Ansible, а где Docker

Автодеплой SIP-стека без ручной сборки: где Ansible, а где Docker

Для телефонной инфраструктуры опасно смешивать две задачи: конфигурацию узлов и запуск сервисов. Ansible должен ставить пакеты, рендерить шаблоны, раскладывать TLS-сертификаты, права, sysctl и firewall. Docker — поднимать изолированные компоненты: Kamailio, Asterisk, RTPengine, веб-панель, тестовые окружения. Если контейнер пытается управлять хостом, вы теряете предсказуемость.

Нормальный паттерн такой: образ собирается один раз, а параметры приезжают через переменные и mount-ы. В Ansible используйте шаблоны для docker-compose.yml, env-файлов и системных unit-файлов. Обязательно разделяйте сети: SIP-сигнализация отдельно, RTP отдельно, админка отдельно. Иначе ловите лишний NAT, странные one-way audio и неочевидные ACL.

Для Asterisk и Kamailio не тащите «универсальный» контейнер с кучей зависимостей. Лучше несколько узких сервисов, каждый с понятной ролью: прокси, медиа-реле, PBX, БД, очередь. Тогда rollback — это откат одного образа и одной переменной, а не ручной разбор всего стека. Логи и CDR сразу отправляйте наружу, не храните их только внутри контейнера.

Практика простая: Ansible описывает состояние хоста и конфигурацию, Docker — исполняет сервисы, а проверка после деплоя смотрит SIP OPTIONS, регистрацию и прохождение RTP. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.