Contenidors RouterOS: Docker a MikroTik

Resum MikroTik RouterOS v7 pot executar contenidors compatibles amb Docker directament al router, de manera que el filtratge DNS, els agents de monitoratge i els petits serveis de xarxa conviuen al costat del pla d’encaminament en comptes d’en una caixa separada. Aquesta guia cobreix els requisits de maquinari i arquitectura, l’activació segura del device-mode de contenidors, la construcció de la xarxa veth i bridge amb NAT, el desplegament del teu primer contenidor i la gestió de contenidors en una flota. RouterOS 7.23 (maig de 2026) ha ampliat el catàleg d’aplicacions de contenidors a punt per executar, fet que el converteix en una opció pràctica tant per a ISPs com per a constructors de laboratori.

Què Són els Contenidors a MikroTik RouterOS?

Els contenidors a MikroTik RouterOS són la implementació de MikroTik dels contenidors de Linux que permet a un dispositiu amb RouterOS v7 executar imatges d’aplicacions aïllades i compatibles amb Docker directament al router. Funcionen amb imatges de Docker Hub, GCR, Quay i altres registres, i tot i que RouterOS utilitza la seva pròpia sintaxi de CLI en lloc de l’ordre docker, el comportament subjacent és el mateix: baixa una imatge, dona-li una xarxa, munta emmagatzematge i executa-la. (Documentació de MikroTik)

Per a un ISP o un laboratori, això significa que petits serveis adjacents a la xarxa es poden col·locar juntament amb el pla d’encaminament: un filtre DNS de Pi-hole o AdGuard, un agent de monitoratge, un reverse proxy o un pont IoT. La versió estable RouterOS 7.23 del 25 de maig de 2026 va afegir una llarga llista d’aplicacions a punt per executar —incloent-hi paperless-ngx, nextcloud, lorawan-stack, birdnet-go i interfícies de gestió de Docker com portainer i dockge— juntament amb un nou commutador network-outgoing-access per bloquejar que un contenidor iniciï trànsit de sortida. (Registre de canvis de RouterOS 7.23)

Requisits i Maquinari

El paquet container és compatible amb les arquitectures arm, arm64 i x86, i s’ha d’instal·lar abans de qualsevol altra cosa. Baixar una imatge remota necessita molt d’espai lliure, de manera que MikroTik recomana emmagatzematge extern en lloc de la memòria flash interna del dispositiu. (Documentació de MikroTik)

Planifica mitjans externs en USB, SATA o NVMe, formatats amb un sistema de fitxers que RouterOS admeti. MikroTik suggereix un disc capaç d’almenys 100 MB/s de rendiment seqüencial i 10K IOPS aleatòries: els discos més lents fan que l’extracció d’imatges sigui dolorosament llarga. Evita col·locar volums de contenidors a l’emmagatzematge integrat, que és petit i es desgasta amb els patrons d’escriptura dels contenidors. Els dispositius amb molt poca memòria flash haurien d’utilitzar imatges precompilades al disc connectat en lloc de baixar-les remotament.

Activa el Device-Mode de Contenidors amb Seguretat

Els contenidors estan desactivats per defecte i, amb bona raó, requereixen accés físic per activar-los. Activa la funció amb:

/system/device-mode/update container=yes

Aleshores RouterOS espera que confirmis amb una pulsació del botó reset o un reinici en fred. Aquesta barrera de confirmació física és un control de seguretat deliberat: un cop el mode contenidor està activat, els contenidors es poden afegir, iniciar i eliminar remotament, i una imatge maliciosa pot convertir-se en un punt de suport al router. MikroTik és contundent sobre això: si el teu dispositiu RouterOS està compromès, els contenidors fan que instal·lar programari maliciós sigui trivial, i no hi ha cap garantia de seguretat per a les imatges de tercers.

Tracta el router que allotja contenidors exactament tan segur com la imatge menys fiable que hi executes. Desplega només imatges en què confiïs, mantén el dispositiu protegit per tallafocs i revisa la nostra guia d’operacions de seguretat del device-mode abans d’activar-ho en producció.

Construeix la Xarxa de Contenidors

Els contenidors necessiten una interfície virtual, un bridge i NAT per arribar a internet. El patró següent reflecteix la xarxa “bridge” de Docker. Primer crea una interfície veth i un bridge que comparteixi la seva adreça de passarel·la:

/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

Una sola veth pot servir molts contenidors, i crear parells veth/bridge addicionals et permet aïllar grups de contenidors entre si. Si ets nou en el bridging de RouterOS, el nostre tutorial de configuració de bridge explica el model subjacent. A continuació, afegeix una regla masquerade perquè el trànsit de sortida dels contenidors es tradueixi —consulta la guia de configuració de NAT per a la imatge completa:

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

Desplega el Teu Primer Contenidor

Apunta el registry i el directori temporal d’extracció al teu disc extern, i després afegeix la imatge. L’exemple de Pi-hole següent és el canònic de la documentació de 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

Afegir el contenidor inicia la baixada i l’extracció però no l’executa. Comprova el progrés amb /container/print i espera fins a status=stopped, i després inicia’l:

/container/start pihole

Finalment, publica el servei reenviant un port del router cap a l’adreça 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 ara respon a la IP de la LAN del router. Executar el filtratge DNS d’aquesta manera és una alternativa a les llistes de bloqueig natives de RouterOS: si prefereixes la via sense contenidor, consulta el nostre tutorial d’adlist de RouterOS.

Gestiona Contenidors en una Flota

Un sol contenidor en un router és fàcil. La veritable qüestió operativa per a un ISP és la consistència: la mateixa imatge, el mateix esquema de veth i NAT, la mateixa disposició d’emmagatzematge i els mateixos límits de start-on-boot i de memòria a cada dispositiu. RouterOS et dona les primitives —start-on-boot=yes sobreviu als reinicis, i memory-high o memory-max limiten la RAM per contenidor perquè un servei descontrolat no pugui afamar el pla d’encaminament:

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

La part difícil és fer-ho de manera idèntica en desenes o centenars de routers remots, i després demostrar que cadascun ha tornat realment a engegar-se després d’un reinici —especialment quan el dispositiu és darrere de CGNAT i no pots simplement arribar a la seva IP pública.

Consells

• Mantén cada volum de contenidor al disc extern; mai a la NAND interna.
• Utilitza un parell veth/bridge separat per aïllar els contenidors no fiables dels fiables.
• Estableix memory-max a qualsevol cosa de la qual no et fiïs del tot per mantenir el router responsiu.
• Per a un banc de proves net abans de tocar la producció, executa les mateixes imatges en una instància CHR virtualitzada abans de desplegar-les a routers físics.

Fes el Següent Pas

Els contenidors converteixen un router MikroTik en un petit amfitrió d’aplicacions, però una flota d’aquests amfitrions necessita orquestració. MKController crea plantilles de la configuració de RouterOS de manera centralitzada, l’aplica a cada dispositiu del teu inventari i fa seguiment de les desviacions perquè puguis veure quin router ha divergit —i mitjançant NATCloud arriba a dispositius darrere de CGNAT per confirmar que un contenidor s’ha reiniciat després del manteniment. Això tanca la bretxa entre configurar un contenidor a mà i operar-los de manera fiable en tota una xarxa d’ISP.

Inicia la teva prova gratuïta de MKController