RouterOS Containers: Docker на MikroTik

Стислий огляд MikroTik RouterOS v7 може запускати сумісні з Docker container безпосередньо на маршрутизаторі, тож фільтрація 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