RouterOS-containere: Docker på MikroTik

Sammendrag MikroTik RouterOS v7 kan kjøre Docker-kompatible containere direkte på ruteren, slik at DNS-filtrering, overvåkingsagenter og små nettverkstjenester ligger ved siden av ruteplanet i stedet for på en egen boks. Denne guiden dekker maskinvare- og arkitekturkravene, sikker aktivering av container device-mode, oppbygging av veth- og bridge-nettverk med NAT, distribusjon av din første container, og forvaltning av containere på tvers av en flåte. RouterOS 7.23 (mai 2026) utvidet katalogen over kjøreklare container-apper, noe som gjør dette til et praktisk alternativ for både ISP-er og laboratoriebyggere.

Hva Er Containere på MikroTik RouterOS?

Containere på MikroTik RouterOS er MikroTiks implementering av Linux-containere som lar en RouterOS v7-enhet kjøre isolerte, Docker-kompatible applikasjonsimager direkte på ruteren. De fungerer med imager fra Docker Hub, GCR, Quay og andre registre, og selv om RouterOS bruker sin egen CLI-syntaks i stedet for docker-kommandoen, er den underliggende oppførselen den samme — hent et image, gi det et nettverk, monter lagring og kjør det. (MikroTik-dokumentasjon)

For en ISP eller et laboratorium betyr dette at små nettverksnære tjenester kan samlokaliseres med ruteplanet: et Pi-hole- eller AdGuard-DNS-filter, en overvåkingsagent, en reverse proxy eller en IoT-bro. Den stabile utgivelsen RouterOS 7.23 den 25. mai 2026 la til en lang liste med kjøreklare apper — inkludert paperless-ngx, nextcloud, lorawan-stack, birdnet-go og Docker-administrasjonsgrensesnitt som portainer og dockge — sammen med en ny network-outgoing-access-bryter som blokkerer en container fra å starte utgående trafikk. (RouterOS 7.23-endringslogg)

Krav og Maskinvare

Container-pakken er kompatibel med arm-, arm64- og x86-arkitekturer, og den må installeres før alt annet. Å hente et eksternt image krever mye ledig plass, så MikroTik anbefaler ekstern lagring fremfor enhetens interne flash. (MikroTik-dokumentasjon)

Planlegg for eksterne medier via USB, SATA eller NVMe, formatert med et filsystem RouterOS støtter. MikroTik foreslår en disk som klarer minst 100 MB/s sekvensiell gjennomstrømming og 10K tilfeldige IOPS — tregere disker gjør utpakkingen av imager smertefullt lang. Unngå å plassere container-volumer på innebygd lagring, som er liten og slites ut under containernes skrivemønstre. Enheter med svært begrenset flash bør bruke ferdigbygde imager på den tilkoblede disken i stedet for å hente dem eksternt.

Aktiver Container Device-Mode Trygt

Containere er deaktivert som standard og krever, med god grunn, fysisk tilgang for å slås på. Aktiver funksjonen med:

/system/device-mode/update container=yes

RouterOS venter deretter på at du bekrefter med et trykk på reset-knappen eller en kaldstart. Denne fysiske bekreftelsesporten er en bevisst sikkerhetskontroll: når containermodus er på, kan containere legges til, startes og fjernes eksternt, og et ondsinnet image kan bli et fotfeste på ruteren. MikroTik er klar på dette — hvis RouterOS-enheten din er kompromittert, gjør containere det trivielt å installere ondsinnet programvare, og det finnes ingen sikkerhetsgaranti for tredjeparts-imager.

Behandle ruteren som er vert for containere som nøyaktig like sikker som det minst betrodde imaget du kjører på den. Distribuer bare imager du stoler på, hold enheten bak en brannmur, og les vår guide for sikker drift av device-mode før du aktiverer dette i produksjon.

Bygg Containernettverket

Containere trenger et virtuelt grensesnitt, en bridge og NAT for å nå internett. Mønsteret nedenfor speiler “bridge”-nettverk i Docker. Opprett først et veth-grensesnitt og en bridge som deler gateway-adressen:

/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

Én veth kan betjene mange containere, og oppretting av flere veth/bridge-par lar deg isolere grupper av containere fra hverandre. Hvis du er ny i RouterOS-bridging, forklarer vår veiledning for bridge-konfigurasjon den underliggende modellen. Legg deretter til en masquerade-regel slik at utgående containertrafikk oversettes — se NAT-konfigurasjonsguiden for hele bildet:

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

Distribuer Din Første Container

Pek registeret og den midlertidige utpakkingsmappen mot den eksterne disken, og legg deretter til imaget. Pi-hole-eksempelet nedenfor er det kanoniske fra MikroTiks dokumentasjon:

/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

Å legge til containeren starter nedlastingen og utpakkingen, men kjører den ikke. Sjekk fremdriften med /container/print og vent til status=stopped, og start den deretter:

/container/start pihole

Publiser til slutt tjenesten ved å videresende en port fra ruteren til veth-adressen:

/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 svarer nå på ruterens LAN-IP. Å kjøre DNS-filtrering på denne måten er et alternativ til RouterOS’ innebygde blokkeringslister — hvis du foretrekker veien uten container, se vår RouterOS adlist-veiledning.

Forvalt Containere på Tvers av en Flåte

En enkelt container på én ruter er enkelt. Det virkelige driftsspørsmålet for en ISP er konsistens: samme image, samme veth- og NAT-oppsett, samme lagringslayout, og de samme start-on-boot- og minnegrensene på hver enhet. RouterOS gir deg byggesteinene — start-on-boot=yes overlever omstarter, og memory-high eller memory-max begrenser RAM per container slik at en tjeneste som løper løpsk ikke sulter ut ruteplanet:

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

Det vanskelige er å gjøre dette identisk på tvers av dusinvis eller hundrevis av eksterne rutere, og deretter bevise at hver enkelt faktisk kom opp igjen etter en omstart — særlig når enheten sitter bak CGNAT og du ikke bare kan nå dens offentlige IP.

Tips

• Hold hvert containervolum på den eksterne disken; aldri på intern NAND.
• Bruk et separat veth/bridge-par for å isolere ikke-betrodde containere fra betrodde.
• Sett memory-max på alt du ikke fullt ut stoler på, for å holde ruteren responsiv.
• For et rent testmiljø før du rører produksjon, kjør de samme imagene på en virtualisert CHR-instans før du distribuerer til fysiske rutere.

Ta Neste Steg

Containere gjør en MikroTik-ruter til en liten applikasjonsvert, men en flåte av slike verter trenger orkestrering. MKController maler RouterOS-konfigurasjon sentralt, bruker den på hver enhet i inventaret ditt, og sporer avvik slik at du kan se hvilken ruter som avvek — og gjennom NATCloud når den enheter bak CGNAT for å bekrefte at en container startet på nytt etter vedlikehold. Det lukker gapet mellom å konfigurere én container for hånd og å drifte dem pålitelig på tvers av et helt ISP-nettverk.

Start din gratis MKController-prøveperiode