RouterOS Containers: Docker på MikroTik

Resumé MikroTik RouterOS v7 kan køre Docker-kompatible containere direkte på routeren, så DNS-filtrering, overvågningsagenter og små netværkstjenester lever ved siden af routing-planet i stedet for på en separat enhed. Denne guide dækker krav til hardware og arkitektur, sikker aktivering af container-device-mode, opbygning af veth- og bridge-netværk med NAT, udrulning af din første container og administration af containere på tværs af en flåde. RouterOS 7.23 (maj 2026) udvidede kataloget over klar-til-brug containerapps, hvilket gør dette til en praktisk mulighed for både ISP’er og lab-byggere.

Hvad Er Containere på MikroTik RouterOS?

Containere på MikroTik RouterOS er MikroTiks implementering af Linux-containere, der lader en RouterOS v7-enhed køre isolerede, Docker-kompatible applikations-images direkte på routeren. De fungerer med images fra Docker Hub, GCR, Quay og andre registries, og selvom RouterOS bruger sin egen CLI-syntaks i stedet for docker-kommandoen, er den underliggende adfærd den samme — træk et image, giv det et netværk, montér lager og kør det. (MikroTik-dokumentation)

For en ISP eller et lab betyder det, at små netværksnære tjenester kan placeres sammen med routing-planet: et Pi-hole- eller AdGuard-DNS-filter, en overvågningsagent, en reverse proxy eller en IoT-bridge. Den stabile udgivelse RouterOS 7.23 den 25. maj 2026 tilføjede en lang liste af klar-til-brug apps — herunder paperless-ngx, nextcloud, lorawan-stack, birdnet-go og Docker-administrationsfrontends som portainer og dockge — sammen med en ny network-outgoing-access-kontakt, der blokerer en container fra at indlede udgående trafik. (RouterOS 7.23-changelog)

Krav og Hardware

Container-pakken er kompatibel med arkitekturerne arm, arm64 og x86, og den skal installeres før alt andet. At trække et eksternt image kræver meget ledig plads, så MikroTik anbefaler eksternt lager frem for enhedens interne flash. (MikroTik-dokumentation)

Planlæg eksterne medier via USB, SATA eller NVMe, formateret med et filsystem, som RouterOS understøtter. MikroTik foreslår en disk, der kan klare mindst 100 MB/s sekventiel gennemstrømning og 10K tilfældige IOPS — langsommere diske gør udpakning af images pinefuldt langsom. Undgå at placere containervolumener på det indbyggede lager, der er lille og slides under containeres skrivemønstre. Enheder med meget begrænset flash bør bruge forhåndsbyggede images på den tilsluttede disk i stedet for at trække eksternt.

Aktivér Container-Device-Mode Sikkert

Containere er deaktiveret som standard og kræver med god grund fysisk adgang for at blive tændt. Aktivér funktionen med:

/system/device-mode/update container=yes

RouterOS venter derefter på, at du bekræfter med et tryk på reset-knappen eller en kold genstart. Denne port for fysisk bekræftelse er en bevidst sikkerhedskontrol: når containertilstand er aktiveret, kan containere tilføjes, startes og fjernes eksternt, og et ondsindet image kan blive et fodfæste på routeren. MikroTik er ligefrem omkring dette — hvis din RouterOS-enhed kompromitteres, gør containere det trivielt at installere ondsindet software, og der er ingen sikkerhedsgaranti for tredjeparts-images.

Behandl routeren, der hoster containere, som præcis lige så sikker som det mindst betroede image, du kører på den. Udrul kun images, du har tillid til, hold enheden bag en firewall, og læs vores guide til sikker drift af device-mode, før du aktiverer dette i produktion.

Byg Containernetværket

Containere har brug for en virtuel grænseflade, en bridge og NAT for at nå internettet. Mønstret nedenfor afspejler “bridge”-netværk i Docker. Opret først en veth-grænseflade og en bridge, der deler dens gateway-adresse:

/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 oprettelse af yderligere veth/bridge-par lader dig isolere grupper af containere fra hinanden. Hvis du er ny inden for RouterOS-bridging, forklarer vores tutorial om bridge-konfiguration den underliggende model. Tilføj derefter en masquerade-regel, så udgående containertrafik oversættes — se guiden til NAT-konfiguration for det fulde billede:

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

Udrul Din Første Container

Peg registry og den midlertidige udpakningsmappe mod din eksterne disk, og tilføj derefter imaget. Pi-hole-eksemplet nedenfor er det kanoniske fra 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

At tilføje containeren starter download og udpakning, men kører den ikke. Tjek fremskridt med /container/print, og vent til status=stopped, og start den derefter:

/container/start pihole

Publicér til sidst tjenesten ved at videresende en port fra routeren 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 nu på routerens LAN-IP. At køre DNS-filtrering på denne måde er et alternativ til RouterOS’ indbyggede blokeringslister — hvis du foretrækker vejen uden container, så se vores RouterOS-adlist-tutorial.

Administrér Containere på Tværs af en Flåde

En enkelt container på én router er let. Det egentlige driftsspørgsmål for en ISP er konsistens: samme image, samme veth- og NAT-skema, samme lagerlayout og samme start-on-boot- og hukommelsesgrænser på hver enhed. RouterOS giver dig primitiverne — start-on-boot=yes overlever genstarter, og memory-high eller memory-max begrænser RAM pr. container, så en løbsk tjeneste ikke kan udsulte routing-planet:

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

Den svære del er at gøre dette identisk på tværs af dusinvis eller hundredvis af fjernrouterne og derefter bevise, at hver enkelt faktisk kom op igen efter en genstart — især når enheden sidder bag CGNAT, og du ikke bare kan nå dens offentlige IP.

Tips

• Hold hver containervolumen på den eksterne disk; aldrig på den interne NAND.
• Brug et separat veth/bridge-par til at isolere ikke-betroede containere fra betroede.
• Sæt memory-max på alt, du ikke fuldt ud har tillid til, for at holde routeren responsiv.
• For et rent testmiljø, før du rører produktionen, kør de samme images på en virtualiseret CHR-instans, før du udruller til fysiske routere.

Tag Det Næste Skridt

Containere forvandler en MikroTik-router til en lille applikationsvært, men en flåde af sådanne værter har brug for orkestrering. MKController skabeloniserer RouterOS-konfiguration centralt, anvender den på hver enhed i dit inventar og sporer drift, så du kan se, hvilken router der afveg — og gennem NATCloud når den enheder bag CGNAT for at bekræfte, at en container genstartede efter vedligeholdelse. Det lukker hullet mellem at konfigurere én container i hånden og at drive dem pålideligt på tværs af et helt ISP-netværk.

Start din gratis MKController-prøveperiode