RouterOS Containers: Docker на MikroTik

Сводка MikroTik RouterOS v7 может запускать container, совместимые с Docker, прямо на маршрутизаторе, поэтому фильтрация DNS, агенты мониторинга и небольшие сетевые сервисы располагаются рядом с плоскостью маршрутизации, а не на отдельной машине. Это руководство охватывает требования к оборудованию и архитектуре, безопасное включение device-mode для container, построение сети veth и bridge с NAT, развёртывание вашего первого container и управление container в масштабах парка устройств. RouterOS 7.23 (май 2026) расширил каталог готовых к запуску приложений container, сделав это практичным вариантом как для интернет-провайдеров, так и для сборщиков лабораторных стендов.

Что Такое Containers на MikroTik RouterOS?

Containers на MikroTik RouterOS — это реализация Linux-контейнеров от MikroTik, которая позволяет устройству RouterOS v7 запускать изолированные, совместимые с Docker образы приложений прямо на маршрутизаторе. Они работают с образами из Docker Hub, GCR, Quay и других реестров, и хотя RouterOS использует собственный синтаксис CLI вместо команды docker, базовое поведение то же самое — скачать образ, дать ему сеть, смонтировать хранилище и запустить его. (Документация MikroTik)

Для интернет-провайдера или лаборатории это означает, что небольшие сетевые сервисы можно разместить рядом с плоскостью маршрутизации: DNS-фильтр Pi-hole или AdGuard, агент мониторинга, обратный прокси или мост IoT. Стабильный релиз RouterOS 7.23 от 25 мая 2026 года добавил длинный список готовых к запуску приложений — включая paperless-ngx, nextcloud, lorawan-stack, birdnet-go и фронтенды управления Docker, такие как portainer и dockge, — наряду с новым переключателем network-outgoing-access, чтобы запретить container инициировать исходящий трафик. (Список изменений RouterOS 7.23)

Требования и Оборудование

Пакет container совместим с архитектурами arm, arm64 и x86 и должен быть установлен раньше всего остального. Скачивание удалённого образа требует много свободного места, поэтому MikroTik рекомендует внешнее хранилище вместо внутренней флеш-памяти устройства. (Документация MikroTik)

Запланируйте внешний носитель на USB, SATA или NVMe, отформатированный под файловую систему, поддерживаемую RouterOS. MikroTik советует диск, способный обеспечить как минимум 100 МБ/с последовательной пропускной способности и 10K случайных IOPS — более медленные диски делают распаковку образа мучительно долгой. Избегайте размещения томов container на встроенном хранилище, которое мало по объёму и изнашивается под нагрузкой записи container. Устройствам с очень ограниченной флеш-памятью следует использовать заранее собранные образы на подключённом диске вместо удалённого скачивания.

Безопасно Включите Device-Mode для Container

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

/system/device-mode/update container=yes

Затем RouterOS ждёт, пока вы подтвердите нажатием кнопки reset или холодной перезагрузкой. Этот барьер физического подтверждения — намеренный механизм безопасности: как только режим container включён, container можно добавлять, запускать и удалять удалённо, а вредоносный образ может стать точкой опоры на маршрутизаторе. MikroTik прямо говорит об этом — если ваше устройство RouterOS скомпрометировано, container делают тривиальной установку вредоносного ПО, и нет никаких гарантий безопасности для сторонних образов.

Считайте маршрутизатор, на котором размещены container, ровно настолько защищённым, насколько защищён наименее доверенный образ, который вы на нём запускаете. Разворачивайте только те образы, которым доверяете, держите устройство за фаерволом и ознакомьтесь с нашим руководством по операциям безопасности device-mode, прежде чем включать это в продакшене.

Постройте Сеть Container

Container нужны виртуальный интерфейс, bridge и NAT для доступа в интернет. Шаблон ниже повторяет сеть «bridge» в Docker. Сначала создайте интерфейс veth и bridge, который разделяет его адрес шлюза:

/interface/veth/add name=veth1 address=172.17.0.2/24 gateway=172.17.0.1
/interface/bridge/add name=containers
/ip/address/add address=172.17.0.1/24 interface=containers
/interface/bridge/port add bridge=containers interface=veth1

Один veth может обслуживать множество container, а создание дополнительных пар veth/bridge позволяет изолировать группы container друг от друга. Если вы новичок в bridging на RouterOS, наш учебник по настройке bridge объясняет базовую модель. Далее добавьте правило masquerade, чтобы исходящий трафик container транслировался — полную картину смотрите в руководстве по настройке NAT:

/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24

Разверните Ваш Первый Container

Направьте registry и временный каталог распаковки на ваш внешний диск, затем добавьте образ. Пример с Pi-hole ниже — канонический из документации MikroTik:

/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/tmp
/container/add remote-image=pihole/pihole interface=veth1 root-dir=disk1/images/pihole name=pihole logging=yes

Добавление container запускает загрузку и распаковку, но не запускает его. Проверьте прогресс через /container/print и дождитесь status=stopped, затем запустите:

/container/start pihole

Наконец, опубликуйте сервис, перенаправив порт с маршрутизатора на адрес veth:

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.88.1 dst-port=80 protocol=tcp to-addresses=172.17.0.2 to-ports=80

Pi-hole теперь отвечает на LAN-IP маршрутизатора. Запуск фильтрации DNS таким способом — это альтернатива встроенным блок-листам RouterOS; если вы предпочитаете путь без container, смотрите наш учебник по adlist в RouterOS.

Управляйте Container в Масштабах Парка Устройств

Один container на одном маршрутизаторе — это просто. Настоящий операционный вопрос для интернет-провайдера — это согласованность: тот же образ, та же схема veth и NAT, та же раскладка хранилища и те же лимиты start-on-boot и памяти на каждом устройстве. RouterOS даёт вам примитивы — start-on-boot=yes переживает перезагрузки, а memory-high или memory-max ограничивают ОЗУ на container, чтобы вышедший из-под контроля сервис не истощил плоскость маршрутизации:

/container/config/set memory-high=200M
/container/set pihole start-on-boot=yes

Сложность в том, чтобы сделать это одинаково на десятках или сотнях удалённых маршрутизаторов, а затем доказать, что каждый из них действительно поднялся после перезагрузки — особенно когда устройство находится за CGNAT и вы не можете просто достучаться до его публичного IP.

Советы

• Держите каждый том container на внешнем диске; никогда на внутренней NAND.
• Используйте отдельную пару veth/bridge, чтобы изолировать недоверенные container от доверенных.
• Задавайте memory-max для всего, чему вы не полностью доверяете, чтобы маршрутизатор оставался отзывчивым.
• Для чистого тестового стенда перед тем, как трогать продакшен, запускайте те же образы на виртуализированном экземпляре CHR, прежде чем разворачивать их на физических маршрутизаторах.

Сделайте Следующий Шаг

Container превращают маршрутизатор MikroTik в крошечный хост приложений, но парку таких хостов нужна оркестрация. MKController централизованно шаблонизирует конфигурацию RouterOS, применяет её к каждому устройству в вашем инвентаре и отслеживает дрейф, чтобы вы видели, какой маршрутизатор разошёлся, — а через NATCloud он достаёт устройства за CGNAT, чтобы подтвердить, что container перезапустился после обслуживания. Это закрывает разрыв между ручной настройкой одного container и надёжной их эксплуатацией во всей сети интернет-провайдера.

Начните бесплатный пробный период MKController