In breve: un container su RouterOS è un modo per far girare un programma Linux impacchettato — un DNS, un proxy, un piccolo server — dentro il router, isolato dal resto del sistema. Non è una macchina virtuale e non è nemmeno un container “di sistema” tipo quelli di Proxmox: RouterOS esegue immagini Docker (OCI), condividendo il proprio kernel. In questa scheda mettiamo in fila le tre cose che confondono di più: cosa sono davvero, su quali apparati girano (dipende dalla CPU) e perché restano spenti finché non li sblocchi con una conferma fisica.

Container in una riga

Un container non porta con sé un sistema operativo intero: usa il kernel dell’apparato che lo ospita e aggiunge soltanto i file del programma. Il kernel lo tiene separato con due meccanismi del Linux sottostante: i namespace (decidono cosa vede — quali processi, quali interfacce, quali file) e i cgroup (decidono quanto può usare — CPU, memoria). È leggero proprio perché il kernel è uno solo, quello del router. Cosa un container riesca a vedere del router — e quanto cambia se lo avvii privileged — lo mostriamo a pacchetto nell’howto Container su MikroTik: cosa vedono del kernel.

Non è una VM — e non è LXC come Proxmox

Tre cose che si somigliano ma non sono la stessa:

  • Macchina virtuale (es. un CHR su un hypervisor): ha un kernel tutto suo e hardware emulato. Massimo isolamento, massimo peso.
  • Container di sistema (LXC), quelli di Proxmox: condividono il kernel dell’host ma contengono l’intero userland di una distro, con il loro init/systemd; ci entri e li tratti come una VM leggera e persistente.
  • Container applicativo (Docker/OCI), quelli di RouterOS: condividono il kernel e contengono una sola applicazione, impacchettata in un’immagine immutabile. Si configurano da fuori (variabili d’ambiente, cartelle montate, comando di avvio), non “ci si entra a vivere”.

Quindi la risposta alla domanda che fanno tutti: i container RouterOS sono come quelli Docker, non come gli LXC di Proxmox. Attenzione però: RouterOS non fa girare il demone Docker, né containerd, né LXC. Ha un motore minimale suo; prende in prestito da Docker solo il formato dell’immagine e i primitivi del kernel.

Le immagini sono Docker (OCI)

Un’immagine è il “pacchetto” del programma. Su RouterOS la ottieni in due modi:

  • Scaricandola da un registry (Docker Hub e simili): indichi il nome dell’immagine e il router se la tira giù, esattamente come farebbe un docker pull.
  • Importando un tar che hai costruito altrove con docker/podman/buildah ed esportato: utile quando il router non deve toccare Internet.

Due regole che fanno risparmiare tempo. Primo: l’immagine deve essere della stessa architettura della CPU del router (ci torniamo sotto); su Docker Hub lo gestisce il manifest multi-architettura, ma un’immagine solo-amd64 non partirà mai su un apparato ARM. Secondo: il container è immutabile ed effimero — se dentro scrive dati che vuoi conservare (configurazioni, database), quelle cartelle vanno montate fuori dall’immagine, su uno spazio persistente del router, altrimenti spariscono al riavvio del container.

Su quali apparati girano? Dipende dalla CPU

Qui sta la sorpresa più grande: non tutti gli apparati RouterOS reggono i container. Il discriminante è l’architettura della CPU, non la fascia o il prezzo.

  • Sì: ARM, ARM64 e x86 (quest’ultimo include il CHR virtuale). Qui il pacchetto container esiste.
  • No: la famiglia MIPS (mipsbe, mmips, smips) e le vecchie TILE/PPC. Su queste il pacchetto proprio non c’è.

Lo verifichi in un colpo solo, guardando il campo architecture-name:

/system resource print
     architecture-name: arm64
              cpu: ARM64
        free-memory: 812.4MiB
       total-memory: 1024.0MiB

Se leggi arm, arm64 o x86 sei a posto; se leggi mipsbe/smips/mmips, no. Oltre alla CPU contano due risorse pratiche spesso sottovalutate:

  • Spazio di archiviazione: l’immagine occupa megabyte, e molti apparati hanno una memoria flash minuscola. Spesso serve uno storage esterno (una chiavetta, un disco, un NVMe) dove tenere immagini e dati montati.
  • Memoria: un container piccolo (un resolver DNS) vive con poco, ma più roba ci metti più RAM serve. Guarda free-memory prima di esagerare.

Il lucchetto: device-mode

Anche quando l’architettura è giusta, i container partono spenti. RouterOS li protegge con il device-mode: la funzione container si accende solo con una conferma fisica sull’apparato (un tasto o un ciclo di alimentazione; su un CHR, un reset dall’hypervisor). È la stessa serratura che copre sniffer, bandwidth test e proxy, e serve a evitare che chi entra da remoto — anche con la password di amministratore — trasformi il router in una base d’attacco. Come si legge e come si cambia senza restare chiusi fuori è spiegato nella scheda Device-mode: il lucchetto fisico sulle funzioni pericolose.

Quando ha senso usarli

Un container è comodo quando vuoi un servizio Linux accanto al router senza aggiungere una macchina: un resolver con blocco pubblicità, un piccolo agente di monitoraggio, un tunnel, un server di test. Il vantaggio è la vicinanza alla rete e il peso ridotto; il limite è che resti su un apparato pensato per instradare, non per fare da server — quindi scegli immagini leggere, monta fuori i dati che contano, e tieni d’occhio memoria e spazio. Per il resto, è Linux: quello che gira in un container Docker altrove, con l’immagine della giusta architettura, gira anche qui.