Containere RouterOS: Docker pe MikroTik

Rezumat MikroTik RouterOS v7 poate rula containere compatibile Docker direct pe router, astfel încât filtrarea DNS, agenții de monitorizare și serviciile mici de rețea să stea lângă planul de rutare în loc de pe o cutie separată. Acest ghid acoperă cerințele de hardware și arhitectură, activarea în siguranță a device-mode pentru container, construirea rețelei veth și bridge cu NAT, implementarea primului tău container și gestionarea containerelor pe o întreagă flotă. RouterOS 7.23 (mai 2026) a extins catalogul de aplicații container gata de utilizare, transformând acest lucru într-o opțiune practică deopotrivă pentru ISP-uri și pentru constructorii de laboratoare.

Ce Sunt Containerele pe MikroTik RouterOS?

Containerele pe MikroTik RouterOS sunt implementarea MikroTik a containerelor Linux, care permite unui dispozitiv RouterOS v7 să ruleze imagini de aplicații izolate, compatibile Docker, direct pe router. Ele funcționează cu imagini din Docker Hub, GCR, Quay și alte registre, iar deși RouterOS folosește propria sintaxă CLI în loc de comanda docker, comportamentul de bază este același — tragi o imagine, îi dai o rețea, montezi stocare și o rulezi. (Documentația MikroTik)

Pentru un ISP sau un laborator, asta înseamnă că serviciile mici, adiacente rețelei, pot fi co-localizate cu planul de rutare: un filtru DNS Pi-hole sau AdGuard, un agent de monitorizare, un reverse proxy sau o punte IoT. Versiunea stabilă RouterOS 7.23 din 25 mai 2026 a adăugat o listă lungă de aplicații gata de rulat — inclusiv paperless-ngx, nextcloud, lorawan-stack, birdnet-go și front-end-uri de management Docker precum portainer și dockge — alături de un nou comutator network-outgoing-access pentru a împiedica un container să inițieze trafic de ieșire. (Changelog RouterOS 7.23)

Cerințe și Hardware

Pachetul container este compatibil cu arhitecturile arm, arm64 și x86 și trebuie instalat înaintea oricărui alt lucru. Tragerea unei imagini la distanță necesită mult spațiu liber, așa că MikroTik recomandă stocare externă în loc de memoria flash internă a dispozitivului. (Documentația MikroTik)

Planifică medii externe pe USB, SATA sau NVMe, formatate cu un sistem de fișiere suportat de RouterOS. MikroTik sugerează un disc capabil de cel puțin 100 MB/s debit secvențial și 10K IOPS aleatorii — discurile mai lente fac extragerea imaginii dureros de lungă. Evită plasarea volumelor container pe stocarea încorporată, care este mică și se uzează sub tiparele de scriere ale containerelor. Dispozitivele cu memorie flash foarte limitată ar trebui să folosească imagini pre-construite pe discul atașat în loc să le tragă de la distanță.

Activează în Siguranță Device-Mode pentru Container

Containerele sunt dezactivate implicit și, pe bună dreptate, necesită acces fizic pentru a fi pornite. Activează funcția cu:

/system/device-mode/update container=yes

RouterOS așteaptă apoi să confirmi cu o apăsare a butonului de reset sau cu o repornire la rece. Această poartă de confirmare fizică este un control de securitate deliberat: odată ce modul container este activat, containerele pot fi adăugate, pornite și eliminate de la distanță, iar o imagine malițioasă poate deveni un punct de sprijin pe router. MikroTik este direct în privința asta — dacă dispozitivul tău RouterOS este compromis, containerele fac instalarea de software malițios trivială și nu există nicio garanție de securitate pentru imaginile terților.

Tratează routerul care găzduiește containere ca fiind exact la fel de sigur ca cea mai puțin de încredere imagine pe care o rulezi pe el. Implementează doar imagini în care ai încredere, păstrează dispozitivul în spatele unui firewall și consultă ghidul nostru de operațiuni de securitate pentru device-mode înainte de a activa acest lucru în producție.

Construiește Rețeaua de Containere

Containerele au nevoie de o interfață virtuală, un bridge și NAT pentru a ajunge la internet. Modelul de mai jos reflectă rețeaua de tip „bridge” din Docker. Mai întâi creează o interfață veth și un bridge care îi împărtășește adresa de 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

Un singur veth poate deservi multe containere, iar crearea de perechi veth/bridge suplimentare îți permite să izolezi grupuri de containere unele de altele. Dacă ești nou în bridging-ul RouterOS, tutorialul nostru de configurare bridge explică modelul de bază. În continuare, adaugă o regulă masquerade astfel încât traficul de ieșire al containerelor să fie tradus — vezi ghidul de configurare NAT pentru imaginea completă:

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

Implementează Primul Tău Container

Direcționează registry-ul și directorul temporar de extragere către discul tău extern, apoi adaugă imaginea. Exemplul Pi-hole de mai jos este cel canonic din documentația 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

Adăugarea containerului pornește descărcarea și extragerea, dar nu îl rulează. Verifică progresul cu /container/print și așteaptă până la status=stopped, apoi pornește-l:

/container/start pihole

În final, publică serviciul redirecționând un port de la router către adresa 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 răspunde acum pe IP-ul LAN al routerului. Rularea filtrării DNS în acest fel este o alternativă la blocklist-urile native ale RouterOS — dacă preferi varianta fără container, vezi tutorialul nostru RouterOS adlist.

Gestionează Containerele pe o Întreagă Flotă

Un singur container pe un singur router este ușor. Adevărata întrebare operațională pentru un ISP este consistența: aceeași imagine, aceeași schemă veth și NAT, același layout de stocare și aceleași limite start-on-boot și de memorie pe fiecare dispozitiv. RouterOS îți oferă primitivele — start-on-boot=yes supraviețuiește repornirilor, iar memory-high sau memory-max plafonează RAM-ul per container astfel încât un serviciu scăpat de sub control să nu poată înfometa planul de rutare:

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

Partea grea este să faci asta identic pe zeci sau sute de routere la distanță, apoi să dovedești că fiecare a revenit cu adevărat după o repornire — mai ales când dispozitivul stă în spatele CGNAT și nu poți pur și simplu să-i atingi IP-ul public.

Sfaturi

• Păstrează fiecare volum de container pe discul extern; niciodată pe NAND-ul intern.
• Folosește o pereche separată veth/bridge pentru a izola containerele neîncredere de cele de încredere.
• Setează memory-max pe orice nu ai încredere deplină pentru a păstra routerul reactiv.
• Pentru un mediu de testare curat înainte de a atinge producția, rulează aceleași imagini pe o instanță CHR virtualizată înainte de a le implementa pe routere fizice.

Fă Pasul Următor

Containerele transformă un router MikroTik într-o gazdă minusculă de aplicații, dar o flotă de astfel de gazde are nevoie de orchestrare. MKController creează șabloane pentru configurația RouterOS în mod central, le aplică pe fiecare dispozitiv din inventarul tău și urmărește abaterile astfel încât să vezi care router a divergit — iar prin NATCloud ajunge la dispozitivele din spatele CGNAT pentru a confirma că un container a repornit după mentenanță. Asta închide golul dintre configurarea manuală a unui singur container și operarea lor fiabilă pe o întreagă rețea ISP.

Începe perioada de probă gratuită MKController