RouterOS-containers: Docker op MikroTik

Samenvatting MikroTik RouterOS v7 kan Docker-compatibele containers rechtstreeks op de router draaien, zodat DNS-filtering, monitoringagents en kleine netwerkdiensten naast het routingvlak draaien in plaats van op een aparte machine. Deze gids behandelt de hardware- en architectuurvereisten, het veilig inschakelen van container device-mode, het opbouwen van veth- en bridge-netwerken met NAT, het implementeren van je eerste container en het beheren van containers over een hele vloot. RouterOS 7.23 (mei 2026) breidde de catalogus van kant-en-klare container-apps uit, waardoor dit een praktische optie wordt voor zowel ISP’s als labbouwers.

Wat Zijn Containers op MikroTik RouterOS?

Containers op MikroTik RouterOS zijn MikroTiks implementatie van Linux-containers waarmee een RouterOS v7-apparaat geïsoleerde, Docker-compatibele applicatie-images rechtstreeks op de router kan draaien. Ze werken met images van Docker Hub, GCR, Quay en andere registries, en hoewel RouterOS zijn eigen CLI-syntaxis gebruikt in plaats van het docker-commando, is het onderliggende gedrag hetzelfde — haal een image op, geef het een netwerk, koppel opslag aan en draai het. (MikroTik-documentatie)

Voor een ISP of een lab betekent dit dat kleine netwerknabije diensten naast het routingvlak kunnen worden geplaatst: een Pi-hole- of AdGuard-DNS-filter, een monitoringagent, een reverse proxy of een IoT-bridge. De stabiele release RouterOS 7.23 van 25 mei 2026 voegde een lange lijst kant-en-klare apps toe — waaronder paperless-ngx, nextcloud, lorawan-stack, birdnet-go en Docker-beheerfront-ends zoals portainer en dockge — naast een nieuwe network-outgoing-access-schakelaar om een container te blokkeren van het initiëren van uitgaand verkeer. (RouterOS 7.23-changelog)

Vereisten en Hardware

Het container-pakket is compatibel met de arm-, arm64- en x86-architecturen en moet vóór al het andere worden geïnstalleerd. Het ophalen van een remote image vereist veel vrije ruimte, dus MikroTik raadt externe opslag aan in plaats van het interne flash-geheugen van het apparaat. (MikroTik-documentatie)

Plan externe media via USB, SATA of NVMe, geformatteerd met een bestandssysteem dat RouterOS ondersteunt. MikroTik adviseert een schijf die ten minste 100 MB/s sequentiële doorvoer en 10K willekeurige IOPS aankan — tragere schijven maken het uitpakken van images pijnlijk lang. Plaats containervolumes niet op ingebouwde opslag, die klein is en slijt onder de schrijfpatronen van containers. Apparaten met zeer beperkte flash moeten vooraf gebouwde images op de aangesloten schijf gebruiken in plaats van ze op afstand op te halen.

Schakel Container Device-Mode Veilig In

Containers zijn standaard uitgeschakeld en vereisen, met goede reden, fysieke toegang om ingeschakeld te worden. Schakel de functie in met:

/system/device-mode/update container=yes

RouterOS wacht vervolgens tot je bevestigt met een druk op de reset-knop of een koude herstart. Deze poort van fysieke bevestiging is een bewuste beveiligingsmaatregel: zodra de containermodus aan staat, kunnen containers op afstand worden toegevoegd, gestart en verwijderd, en kan een kwaadaardig image een steunpunt op de router worden. MikroTik is hier duidelijk over — als je RouterOS-apparaat is gecompromitteerd, maken containers het triviaal om kwaadaardige software te installeren, en er is geen beveiligingsgarantie voor images van derden.

Behandel de router die containers host als precies zo veilig als het minst vertrouwde image dat je erop draait. Implementeer alleen images die je vertrouwt, houd het apparaat achter een firewall en lees onze gids voor veilige device-mode-operatie voordat je dit in productie inschakelt.

Bouw het Containernetwerk

Containers hebben een virtuele interface, een bridge en NAT nodig om het internet te bereiken. Het onderstaande patroon weerspiegelt “bridge”-netwerken in Docker. Maak eerst een veth-interface en een bridge die het gateway-adres deelt:

/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

Eén veth kan veel containers bedienen, en het aanmaken van extra veth/bridge-paren laat je groepen containers van elkaar isoleren. Als je nieuw bent met RouterOS-bridging, legt onze tutorial voor bridge-configuratie het onderliggende model uit. Voeg vervolgens een masquerade-regel toe zodat uitgaand containerverkeer wordt vertaald — zie de NAT-configuratiegids voor het volledige beeld:

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

Implementeer Je Eerste Container

Wijs de registry en de tijdelijke uitpakmap naar je externe schijf en voeg vervolgens het image toe. Het onderstaande Pi-hole-voorbeeld is het canonieke voorbeeld uit de documentatie van 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

Het toevoegen van de container start de download en het uitpakken, maar draait hem niet. Controleer de voortgang met /container/print en wacht tot status=stopped, en start hem dan:

/container/start pihole

Publiceer ten slotte de dienst door een poort van de router naar het veth-adres door te sturen:

/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 antwoordt nu op het LAN-IP van de router. DNS-filtering op deze manier draaien is een alternatief voor de native blokkeerlijsten van RouterOS — als je liever de route zonder container neemt, zie onze RouterOS adlist-tutorial.

Beheer Containers over een Vloot

Eén container op één router is eenvoudig. De echte operationele vraag voor een ISP is consistentie: hetzelfde image, hetzelfde veth- en NAT-schema, dezelfde opslagindeling en dezelfde start-on-boot- en geheugenlimieten op elk apparaat. RouterOS geeft je de bouwstenen — start-on-boot=yes overleeft herstarts, en memory-high of memory-max begrenzen het RAM per container zodat een op hol geslagen dienst het routingvlak niet uithongert:

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

Het moeilijke is om dit identiek te doen over tientallen of honderden externe routers, en vervolgens te bewijzen dat elke afzonderlijke router na een herstart daadwerkelijk weer opkwam — vooral wanneer het apparaat achter CGNAT zit en je niet simpelweg het publieke IP kunt bereiken.

Tips

• Houd elk containervolume op de externe schijf; nooit op intern NAND.
• Gebruik een apart veth/bridge-paar om niet-vertrouwde containers van vertrouwde te isoleren.
• Stel memory-max in op alles wat je niet volledig vertrouwt om de router responsief te houden.
• Voor een schone testomgeving voordat je productie aanraakt, draai dezelfde images op een gevirtualiseerde CHR-instantie voordat je naar fysieke routers implementeert.

Zet de Volgende Stap

Containers maken van een MikroTik-router een kleine applicatiehost, maar een vloot van zulke hosts heeft orkestratie nodig. MKController maakt centraal sjablonen van de RouterOS-configuratie, past ze toe op elk apparaat in je inventaris en volgt drift zodat je kunt zien welke router afweek — en via NATCloud bereikt het apparaten achter CGNAT om te bevestigen dat een container na onderhoud opnieuw is gestart. Dat dicht het gat tussen het handmatig configureren van één container en het betrouwbaar beheren ervan over een heel ISP-netwerk.

Start je gratis MKController-proefperiode