RouterOS Containers: Docker su MikroTik

Riepilogo MikroTik RouterOS v7 può eseguire container compatibili con Docker direttamente sul router, così che il filtraggio DNS, gli agenti di monitoraggio e i piccoli servizi di rete risiedano accanto al piano di routing anziché su una macchina separata. Questa guida copre i requisiti hardware e architetturali, l’attivazione sicura del device-mode container, la costruzione della rete veth e bridge con NAT, la distribuzione del tuo primo container e la gestione dei container su un intero parco dispositivi. RouterOS 7.23 (maggio 2026) ha ampliato il catalogo di app container pronte all’uso, rendendolo un’opzione pratica sia per gli ISP sia per chi costruisce laboratori.

Cosa Sono i Container su MikroTik RouterOS?

I container su MikroTik RouterOS sono l’implementazione MikroTik dei container Linux che permette a un dispositivo RouterOS v7 di eseguire immagini applicative isolate e compatibili con Docker direttamente sul router. Funzionano con immagini da Docker Hub, GCR, Quay e altri registry e, sebbene RouterOS usi la propria sintassi CLI invece del comando docker, il comportamento di fondo è lo stesso — scarica un’immagine, assegnale una rete, monta lo storage ed eseguila. (Documentazione MikroTik)

Per un ISP o un laboratorio, questo significa che piccoli servizi vicini alla rete possono essere collocati insieme al piano di routing: un filtro DNS Pi-hole o AdGuard, un agente di monitoraggio, un reverse proxy o un bridge IoT. La release stabile RouterOS 7.23 del 25 maggio 2026 ha aggiunto un lungo elenco di app pronte all’uso — tra cui paperless-ngx, nextcloud, lorawan-stack, birdnet-go e front-end di gestione Docker come portainer e dockge — insieme a un nuovo interruttore network-outgoing-access per impedire a un container di avviare traffico in uscita. (Changelog RouterOS 7.23)

Requisiti e Hardware

Il pacchetto container è compatibile con le architetture arm, arm64 e x86 e deve essere installato prima di ogni altra cosa. Scaricare un’immagine remota richiede molto spazio libero, quindi MikroTik raccomanda uno storage esterno piuttosto che la memoria flash interna del dispositivo. (Documentazione MikroTik)

Prevedi supporti esterni su USB, SATA o NVMe, formattati con un filesystem supportato da RouterOS. MikroTik suggerisce un disco capace di almeno 100 MB/s di throughput sequenziale e 10K IOPS casuali — dischi più lenti rendono l’estrazione dell’immagine penosamente lunga. Evita di posizionare i volumi dei container sullo storage integrato, che è piccolo e si usura sotto i pattern di scrittura dei container. I dispositivi con flash molto limitata dovrebbero usare immagini pre-costruite sul disco collegato invece di scaricarle da remoto.

Attivare in Sicurezza il Device-Mode Container

I container sono disattivati per impostazione predefinita e, per buoni motivi, richiedono l’accesso fisico per essere abilitati. Attiva la funzione con:

/system/device-mode/update container=yes

RouterOS attende quindi che confermi con la pressione del pulsante reset o un riavvio a freddo. Questo varco di conferma fisica è un controllo di sicurezza deliberato: una volta attiva la modalità container, i container possono essere aggiunti, avviati e rimossi da remoto, e un’immagine malevola può diventare un punto d’appoggio sul router. MikroTik è esplicito al riguardo — se il tuo dispositivo RouterOS è compromesso, i container rendono banale installare software malevolo, e non c’è alcuna garanzia di sicurezza per le immagini di terze parti.

Tratta il router che ospita i container come esattamente sicuro quanto l’immagine meno affidabile che vi esegui. Distribuisci solo immagini di cui ti fidi, mantieni il dispositivo dietro firewall e leggi la nostra guida alle operazioni di sicurezza del device-mode prima di attivarlo in produzione.

Costruire la Rete dei Container

I container hanno bisogno di un’interfaccia virtuale, di un bridge e di NAT per raggiungere internet. Lo schema seguente rispecchia la rete “bridge” in Docker. Crea prima un’interfaccia veth e un bridge che ne condivide l’indirizzo 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 solo veth può servire molti container, e creare ulteriori coppie veth/bridge consente di isolare gruppi di container tra loro. Se sei alle prime armi con il bridging di RouterOS, il nostro tutorial sulla configurazione del bridge spiega il modello sottostante. Successivamente, aggiungi una regola masquerade affinché il traffico in uscita dei container venga tradotto — consulta la guida alla configurazione NAT per il quadro completo:

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

Distribuisci il Tuo Primo Container

Punta il registry e la directory temporanea di estrazione sul tuo disco esterno, poi aggiungi l’immagine. L’esempio Pi-hole qui sotto è quello canonico della documentazione 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

L’aggiunta del container avvia il download e l’estrazione ma non lo esegue. Controlla l’avanzamento con /container/print e attendi fino a status=stopped, poi avvialo:

/container/start pihole

Infine, pubblica il servizio inoltrando una porta dal router all’indirizzo 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 ora risponde sull’IP LAN del router. Eseguire il filtraggio DNS in questo modo è un’alternativa alle blocklist native di RouterOS — se preferisci la strada senza container, consulta il nostro tutorial sulle adlist di RouterOS.

Gestire i Container su un Parco Dispositivi

Un singolo container su un router è facile. La vera questione operativa per un ISP è la coerenza: la stessa immagine, lo stesso schema veth e NAT, lo stesso layout di storage e gli stessi limiti start-on-boot e di memoria su ogni dispositivo. RouterOS ti dà le primitive — start-on-boot=yes sopravvive ai riavvii, e memory-high o memory-max limitano la RAM per container affinché un servizio fuori controllo non affami il piano di routing:

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

La parte difficile è farlo in modo identico su decine o centinaia di router remoti, e poi dimostrare che ciascuno è effettivamente tornato attivo dopo un riavvio — soprattutto quando il dispositivo si trova dietro CGNAT e non puoi semplicemente raggiungere il suo IP pubblico.

Consigli

• Mantieni ogni volume dei container sul disco esterno; mai sul NAND interno.
• Usa una coppia veth/bridge separata per isolare i container non affidabili da quelli affidabili.
• Imposta memory-max su tutto ciò di cui non ti fidi pienamente per mantenere il router reattivo.
• Per un banco di prova pulito prima di toccare la produzione, esegui le stesse immagini su un’istanza CHR virtualizzata prima di distribuirle sui router fisici.

Fai il Prossimo Passo

I container trasformano un router MikroTik in un piccolo host applicativo, ma un parco di questi host ha bisogno di orchestrazione. MKController crea template della configurazione RouterOS in modo centralizzato, li applica a ogni dispositivo del tuo inventario e traccia la deriva, così puoi vedere quale router è divergente — e tramite NATCloud raggiunge i dispositivi dietro CGNAT per confermare che un container è ripartito dopo la manutenzione. Questo colma il divario tra configurare un container a mano e gestirli in modo affidabile su un’intera rete ISP.

Inizia la tua prova gratuita di MKController