RouterOS контейнери: Docker на MikroTik

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

Какво Представляват Контейнерите на MikroTik RouterOS?

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

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

Изисквания и Хардуер

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

Планирайте външен носител на USB, SATA или NVMe, форматиран с файлова система, която RouterOS поддържа. MikroTik предлага диск, способен на поне 100 MB/s последователна пропускателна способност и 10K произволни IOPS — по-бавните дискове правят разопаковането на образите мъчително дълго. Избягвайте поставянето на контейнерни томове на вградено хранилище, което е малко и се износва при контейнерните модели на запис. Устройствата с много ограничена флаш памет трябва да използват предварително изградени образи на прикачения диск вместо да теглят отдалечено.

Активирайте Контейнерния Device-Mode Безопасно

Контейнерите са изключени по подразбиране и, с основателна причина, изискват физически достъп за включване. Активирайте функцията с:

/system/device-mode/update container=yes

След това RouterOS изчаква да потвърдите с натискане на reset бутона или студено рестартиране. Тази бариера за физическо потвърждение е умишлен контрол за сигурност: щом контейнерният режим е включен, контейнери могат да се добавят, стартират и премахват отдалечено, а зловреден образ може да се превърне в опорна точка на рутера. MikroTik е директна за това — ако вашето RouterOS устройство е компрометирано, контейнерите правят инсталирането на зловреден софтуер тривиално, и няма гаранция за сигурността на образи от трети страни.

Третирайте рутера, хостващ контейнери, точно толкова сигурен, колкото е най-малко доверяваният образ, който изпълнявате на него. Внедрявайте само образи, на които имате доверие, дръжте устройството зад защитна стена и прегледайте нашето ръководство за операции по сигурността на device-mode, преди да активирате това в продукция.

Изградете Контейнерната Мрежа

Контейнерите се нуждаят от виртуален интерфейс, bridge и NAT, за да достигнат интернет. Шаблонът по-долу отразява “bridge” мрежата в Docker. Първо създайте veth интерфейс и bridge, който споделя неговия gateway адрес:

/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 може да обслужва много контейнери, а създаването на допълнителни veth/bridge двойки ви позволява да изолирате групи контейнери една от друга. Ако сте нови в RouterOS bridging, нашето ръководство за конфигурация на bridge обяснява основния модел. След това добавете masquerade правило, така че изходящият контейнерен трафик да се транслира — вижте ръководството за конфигурация на NAT за пълната картина:

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

Внедрете Първия Си Контейнер

Насочете 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/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 — ако предпочитате маршрута без контейнер, вижте нашето ръководство за adlist в RouterOS.

Управлявайте Контейнери в Цял Флот

Един контейнер на един рутер е лесен. Истинският оперативен въпрос за интернет доставчик е консистентността: същият образ, същата veth и NAT схема, същото оформление на хранилището и същите start-on-boot и лимити за памет на всяко устройство. RouterOS ви дава примитивите — start-on-boot=yes оцелява при рестартиране, а memory-high или memory-max ограничават RAM на контейнер, така че излязла извън контрол услуга да не може да изтощи рутиращата равнина:

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

Трудната част е да направите това идентично на десетки или стотици отдалечени рутери, после да докажете, че всеки от тях наистина се е възстановил след рестартиране — особено когато устройството е зад CGNAT и не можете просто да достигнете публичния му IP.

Съвети

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

Направете Следващата Стъпка

Контейнерите превръщат един MikroTik рутер в малък хост за приложения, но флот от такива хостове се нуждае от оркестрация. MKController шаблонизира конфигурацията на RouterOS централно, прилага я към всяко устройство в инвентара ви и проследява отклоненията, така че да виждате кой рутер се е отклонил — а чрез NATCloud достига устройства зад CGNAT, за да потвърди, че контейнер се е рестартирал след поддръжка. Това затваря пропастта между ръчното конфигуриране на един контейнер и надеждното им опериране в цяла мрежа на интернет доставчик.

Започнете безплатния си пробен период с MKController