RouterOS Containers: Docker på MikroTik

Sammanfattning MikroTik RouterOS v7 kan köra Docker-kompatibla container direkt på routern, så att DNS-filtrering, övervakningsagenter och små nätverkstjänster lever bredvid routingplanet i stället för på en separat box. Den här guiden täcker hårdvaru- och arkitekturkraven, hur du aktiverar container device-mode säkert, hur du bygger veth- och bridge-nätverk med NAT, hur du distribuerar din första container och hur du hanterar container över en hel flotta. RouterOS 7.23 (maj 2026) utökade katalogen av färdiga container-appar, vilket gör detta till ett praktiskt alternativ för både ISP:er och labbbyggare.

Vad Är Containers på MikroTik RouterOS?

Containers på MikroTik RouterOS är MikroTiks implementering av Linux-container som låter en RouterOS v7-enhet köra isolerade, Docker-kompatibla applikations-images direkt på routern. De fungerar med images från Docker Hub, GCR, Quay och andra registries, och även om RouterOS använder sin egen CLI-syntax i stället för docker-kommandot är det underliggande beteendet detsamma — hämta en image, ge den ett nätverk, montera lagring och kör den. (MikroTik-dokumentation)

För en ISP eller ett labb innebär detta att små nätverksnära tjänster kan placeras tillsammans med routingplanet: ett Pi-hole- eller AdGuard-DNS-filter, en övervakningsagent, en reverse proxy eller en IoT-bridge. Den stabila utgåvan RouterOS 7.23 den 25 maj 2026 lade till en lång lista med färdiga appar — inklusive paperless-ngx, nextcloud, lorawan-stack, birdnet-go och Docker-hanteringsgränssnitt som portainer och dockge — tillsammans med en ny network-outgoing-access-brytare som blockerar en container från att initiera utgående trafik. (RouterOS 7.23-changelog)

Krav och Hårdvara

Container-paketet är kompatibelt med arkitekturerna arm, arm64 och x86, och det måste installeras före allt annat. Att hämta en fjärr-image kräver mycket ledigt utrymme, så MikroTik rekommenderar extern lagring snarare än enhetens interna flashminne. (MikroTik-dokumentation)

Planera för externa media på USB, SATA eller NVMe, formaterade med ett filsystem som RouterOS stödjer. MikroTik föreslår en disk som klarar minst 100 MB/s sekventiell genomströmning och 10K slumpmässiga IOPS — långsammare diskar gör uppackningen av images plågsamt lång. Undvik att placera container-volymer på den inbyggda lagringen, som är liten och slits ut under skrivmönstren från container. Enheter med mycket begränsat flashminne bör använda förbyggda images på den anslutna disken i stället för att hämta på distans.

Aktivera Container Device-Mode Säkert

Container är inaktiverade som standard och kräver, av goda skäl, fysisk åtkomst för att slås på. Aktivera funktionen med:

/system/device-mode/update container=yes

RouterOS väntar sedan på att du bekräftar med en tryckning på reset-knappen eller en kallstart. Denna grind med fysisk bekräftelse är en medveten säkerhetskontroll: när containerläget väl är på kan container läggas till, startas och tas bort på distans, och en skadlig image kan bli ett fotfäste på routern. MikroTik är tydlig med detta — om din RouterOS-enhet är komprometterad gör container det trivialt att installera skadlig programvara, och det finns ingen säkerhetsgaranti för images från tredje part.

Behandla routern som värdar container som exakt lika säker som den minst betrodda image du kör på den. Distribuera bara images du litar på, håll enheten bakom en brandvägg och läs vår guide för säker drift av device-mode innan du aktiverar detta i produktion.

Bygg Container-Nätverket

Container behöver ett virtuellt interface, en bridge och NAT för att nå internet. Mönstret nedan speglar “bridge”-nätverk i Docker. Skapa först ett veth-interface och en bridge som delar dess gateway-adress:

/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

Ett veth kan betjäna många container, och genom att skapa ytterligare veth/bridge-par kan du isolera grupper av container från varandra. Om du är ny på RouterOS-bridging förklarar vår handledning för bridge-konfiguration den underliggande modellen. Lägg sedan till en masquerade-regel så att utgående container-trafik översätts — se guiden för NAT-konfiguration för hela bilden:

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

Distribuera Din Första Container

Peka registry och den temporära uppackningskatalogen mot din externa disk och lägg sedan till imagen. Pi-hole-exemplet nedan är det kanoniska från MikroTiks dokumentation:

/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

Att lägga till containern startar nedladdningen och uppackningen men kör den inte. Kontrollera förloppet med /container/print och vänta tills status=stopped, starta den sedan:

/container/start pihole

Publicera slutligen tjänsten genom att vidarebefordra en port från routern till 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 svarar nu på routerns LAN-IP. Att köra DNS-filtrering på det här sättet är ett alternativ till RouterOS native blockeringslistor — om du föredrar vägen utan container, se vår RouterOS adlist-handledning.

Hantera Containers Över En Flotta

En enda container på en router är enkel. Den verkliga driftfrågan för en ISP är konsekvens: samma image, samma veth- och NAT-schema, samma lagringslayout och samma start-on-boot- och minnesgränser på varje enhet. RouterOS ger dig primitiverna — start-on-boot=yes överlever omstarter, och memory-high eller memory-max begränsar RAM per container så att en skenande tjänst inte kan svälta ut routingplanet:

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

Den svåra delen är att göra detta identiskt över dussintals eller hundratals fjärrouter och sedan bevisa att var och en faktiskt kom upp igen efter en omstart — särskilt när enheten sitter bakom CGNAT och du inte enkelt kan nå dess publika IP.

Tips

• Håll varje container-volym på den externa disken; aldrig på intern NAND.
• Använd ett separat veth/bridge-par för att isolera obetrodda container från betrodda.
• Sätt memory-max på allt du inte helt litar på för att hålla routern responsiv.
• För en ren testmiljö innan du rör produktionen, kör samma images på en virtualiserad CHR-instans innan du distribuerar till fysiska router.

Ta Nästa Steg

Container förvandlar en MikroTik-router till en liten applikationsvärd, men en flotta av sådana värdar behöver orkestrering. MKController mallar RouterOS-konfiguration centralt, tillämpar den på varje enhet i ditt bestånd och spårar drift så att du kan se vilken router som avvek — och via NATCloud når det enheter bakom CGNAT för att bekräfta att en container startade om efter underhåll. Det stänger gapet mellan att konfigurera en container för hand och att driva dem tillförlitligt över ett helt ISP-nätverk.

Starta din kostnadsfria MKController-testperiod