Мультимаунт: как это устроено в Icecast и у нас

Если вы когда-либо пытались запустить интернет-радио на Linux с помощью классической связки Icecast + Liquidsoap, то знаете: чем больше у вас жанров, тем сложнее архитектура. Желание сделать отдельный поток для рока, поп-музыки и джаза оборачивается не просто строчками в конфиге, а целым зоопарком процессов.

Многие администраторы попадают в ловушку «масштабирования вручную». Кажется, что Icecast из коробки готов отдавать сотни потоков, но реальность такова, что мультимаунт — это родная фишка только для сервера, но не для источника. Давайте разберем, почему классический подход заставляет плодить сущности и как мы переосмыслили эту задачу в нашем решении DIY Радио.

Мультимаунт в Icecast: Красота в админке и хаос в процессах

С точки зрения Icecast, мультимаунт выглядит элегантно. В веб-интерфейсе администратора вы видите аккуратный список: /rock, /pop, /jazz. У каждой точки своя статистика, свои слушатели. Кажется, что это единый механизм, но под капотом скрывается жестокая реальность.

1. Каждый маунт требует своего «говорящего» (Source Client): Icecast — это всего лишь ретранслятор. Он не умеет сам брать файлы из папки /rock и превращать их в поток. Для каждой точки монтирования вам нужно поднимать отдельный экземпляр источника. Два маунта — два Liquidsoap (или ezstream), десять маунтов — десять процессов.
2. Дрессировка конфигов: Каждый источник требует своего конфигурационного файла. Для Liquidsoap это означает, что вам придется писать отдельный .liq скрипт для каждого жанра, вручную указывая путь к плейлисту, настройки транскодинга и параметры подключения к серверу.
3. Точки отказа: Если у вас 10 потоков, у вас 10 потенциальных точек отказа. Сбой одного процесса Liquidsoap (например, из-за битого файла в плейлисте) не уронит Icecast, но он уронит конкретный маунт. Слушатели рок-канала останутся в тишине, пока вы не зайдете на сервер и не выполните systemctl restart liquidsoap@rock.

Мультимаунт в нашем решении: Один двигатель для всех дорог

Мы пошли другим путем. Вместо того чтобы запускать оркестр из источников, мы создали единое приложение на Go, которое само управляет мультимаунтом на уровне горутин. Это как если бы у вас был один мощный диджей, который одновременно крутит пластинки в трех залах, а не три разных диджея, каждый со своим проигрывателем.

Вся магия заключается в конфигурации. Вам не нужно писать десять скриптов. Достаточно одного конфигурационного файла, где перечислены ваши маунты:

[mount /rock]
tracks_dir = ./data/rock/tracks

[mount /pop]
tracks_dir = ./data/pop/tracks

[mount /jazz]
tracks_dir = ./data/jazz/tracks

Что происходит внутри? Приложение читает этот конфиг и для каждого маунта порождает собственную горутину (легковесный поток выполнения). Каждая горутина получает:

• Свой плеер (управление очередью треков).
• Свой энкодер (вы сами решаете, будет ли рок в 320kbps, а джаз в 128kbps).
• Свою рекламу и джинглы (файлы подгружаются из папки конкретного маунта).

При этом все они живут внутри одного Go-процесса. Это радикально упрощает мониторинг: вам не нужно следить за десятью сервисами в systemd, достаточно одного.

Итог: Элегантность против «костылей»

Icecast предлагает мультимаунт как фичу, и для своего времени это было революционно. Но реальность современного вещания требует гибкости. Классический стек превращает добавление нового потока в полноценную DevOps-задачу: скопировать конфиг, отредактировать пути, создать новый systemd-юнит, проверить, не конфликтуют ли порты источников.

Наш подход — это отказ от философии «один сервер + куча костылей вокруг». Добавить новый маунт:

• Не нужно писать новый скрипт на Liquidsoap.
• Не нужно настраивать отдельный демон.
• Достаточно дописать три строки в конфиг и положить музыку в соответствующую папку.

Вы получаете ту же надежность, что и у проверенного Icecast (ведь наш серверный движок использует те же сетевые протоколы), но с человеческим лицом. Один процесс, горутины, общая инфраструктура и полный контроль над каждым маунтом из единого центра.