RouterOS Containers: Docker en MikroTik

Resumen MikroTik RouterOS v7 puede ejecutar containers compatibles con Docker directamente en el router, de modo que el filtrado de DNS, los agentes de monitoreo y los pequeños servicios de red conviven junto al plano de enrutamiento en lugar de en un equipo aparte. Esta guía cubre los requisitos de hardware y arquitectura, cómo activar el device-mode de container de forma segura, construir la red veth y bridge con NAT, desplegar tu primer container y gestionar containers en una flota. RouterOS 7.23 (mayo de 2026) amplió el catálogo de apps de container listas para usar, convirtiéndolo en una opción práctica tanto para ISPs como para quienes montan laboratorios.

¿Qué Son los Containers en MikroTik RouterOS?

Los containers en MikroTik RouterOS son la implementación de containers Linux de MikroTik que permite a un dispositivo RouterOS v7 ejecutar imágenes de aplicación aisladas y compatibles con Docker directamente en el router. Funcionan con imágenes de Docker Hub, GCR, Quay y otros registries y, aunque RouterOS usa su propia sintaxis de CLI en lugar del comando docker, el comportamiento de fondo es el mismo: descargar una imagen, darle una red, montar almacenamiento y ejecutarla. (Documentación de MikroTik)

Para un ISP o un laboratorio, esto significa que pequeños servicios cercanos a la red pueden ubicarse junto al plano de enrutamiento: un filtro de DNS Pi-hole o AdGuard, un agente de monitoreo, un proxy inverso o un puente de IoT. La versión estable RouterOS 7.23, del 25 de mayo de 2026, añadió una larga lista de apps listas para usar —incluyendo paperless-ngx, nextcloud, lorawan-stack, birdnet-go y front-ends de gestión de Docker como portainer y dockge— junto con un nuevo switch network-outgoing-access para impedir que un container inicie tráfico saliente. (Changelog de RouterOS 7.23)

Requisitos y Hardware

El paquete container es compatible con las arquitecturas arm, arm64 y x86, y debe instalarse antes que cualquier otra cosa. Descargar una imagen remota necesita mucho espacio libre, por eso MikroTik recomienda almacenamiento externo en lugar del flash interno del dispositivo. (Documentación de MikroTik)

Planifica medios externos en USB, SATA o NVMe, formateados con un sistema de archivos compatible con RouterOS. MikroTik sugiere un disco capaz de al menos 100 MB/s de throughput secuencial y 10K IOPS aleatorios; los discos más lentos hacen que la extracción de la imagen sea dolorosamente larga. Evita colocar volúmenes de container en el almacenamiento interno, que es pequeño y se desgasta bajo los patrones de escritura de los containers. Los dispositivos con flash muy limitada deberían usar imágenes preconstruidas en el disco conectado en lugar de descargarlas de forma remota.

Activa el Device-Mode de Container de Forma Segura

Los containers están desactivados por defecto y, con buena razón, requieren acceso físico para encenderse. Activa la función con:

/system/device-mode/update container=yes

RouterOS espera entonces que confirmes con una pulsación del botón de reset o un arranque en frío. Esta puerta de confirmación física es un control de seguridad deliberado: una vez que el modo container está activo, los containers pueden añadirse, iniciarse y eliminarse de forma remota, y una imagen maliciosa puede convertirse en un punto de apoyo en el router. MikroTik es directa al respecto: si tu dispositivo RouterOS se ve comprometido, los containers hacen trivial instalar software malicioso, y no hay garantía de seguridad para las imágenes de terceros.

Trata al router que aloja containers como exactamente tan seguro como la imagen menos confiable que ejecutas en él. Despliega solo imágenes en las que confíes, mantén el dispositivo protegido por firewall y revisa nuestra guía de operaciones de seguridad del device-mode antes de activar esto en producción.

Construye la Red del Container

Los containers necesitan una interfaz virtual, un bridge y NAT para alcanzar internet. El patrón siguiente refleja la red “bridge” de Docker. Primero crea una interfaz veth y un bridge que comparta su dirección 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

Una veth puede servir a muchos containers, y crear pares veth/bridge adicionales te permite aislar grupos de containers entre sí. Si eres nuevo en el bridging de RouterOS, nuestro tutorial de configuración de bridge explica el modelo subyacente. A continuación, añade una regla de masquerade para que el tráfico saliente del container se traduzca; consulta la guía de configuración de NAT para el panorama completo:

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

Despliega Tu Primer Container

Apunta el registry y el directorio temporal de extracción a tu disco externo y luego añade la imagen. El ejemplo de Pi-hole siguiente es el canónico de la documentación 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

Añadir el container inicia la descarga y la extracción, pero no lo ejecuta. Comprueba el progreso con /container/print y espera hasta status=stopped, luego inícialo:

/container/start pihole

Por último, publica el servicio reenviando un puerto del router a la dirección 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 ahora responde en la IP de la LAN del router. Ejecutar el filtrado de DNS de esta forma es una alternativa a las blocklists nativas de RouterOS; si prefieres la vía sin container, consulta nuestro tutorial de adlist de RouterOS.

Gestiona Containers en una Flota

Un solo container en un router es fácil. La verdadera cuestión operativa para un ISP es la consistencia: la misma imagen, el mismo esquema de veth y NAT, la misma disposición de almacenamiento y los mismos límites de start-on-boot y de memoria en cada dispositivo. RouterOS te da las primitivas: start-on-boot=yes sobrevive a los reinicios, y memory-high o memory-max limitan la RAM por container para que un servicio descontrolado no agote el plano de enrutamiento:

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

Lo difícil es hacer esto de forma idéntica en decenas o cientos de routers remotos y luego demostrar que cada uno realmente volvió a arrancar tras un reinicio, especialmente cuando el dispositivo está detrás de CGNAT y no puedes simplemente alcanzar su IP pública.

Consejos

• Mantén todo volumen de container en el disco externo; nunca en la NAND interna.
• Usa un par veth/bridge separado para aislar los containers no confiables de los confiables.
• Define memory-max en todo aquello en lo que no confíes plenamente para mantener el router receptivo.
• Para un banco de pruebas limpio antes de tocar producción, ejecuta las mismas imágenes en una instancia CHR virtualizada antes de desplegarlas en routers físicos.

Da el Siguiente Paso

Los containers convierten un router MikroTik en un diminuto host de aplicaciones, pero una flota de esos hosts necesita orquestación. MKController plantilla la configuración de RouterOS de forma centralizada, la aplica a cada dispositivo de tu inventario y rastrea la deriva para que veas qué router divergió, y a través de NATCloud alcanza dispositivos detrás de CGNAT para confirmar que un container se reinició tras el mantenimiento. Eso cierra la brecha entre configurar un container a mano y operarlos de forma fiable en toda una red de ISP.

Comienza tu prueba gratuita de MKController