RouterOS Containers: Docker auf MikroTik

Zusammenfassung MikroTik RouterOS v7 kann Docker-kompatible container direkt auf dem Router ausführen, sodass DNS-Filterung, Monitoring-Agenten und kleine Netzwerkdienste neben der Routing-Ebene leben statt auf einer separaten Box. Dieser Leitfaden behandelt die Hardware- und Architekturanforderungen, das sichere Aktivieren des Container-Device-Mode, den Aufbau des veth- und Bridge-Netzwerks mit NAT, das Bereitstellen Ihres ersten container und das Verwalten von container über eine ganze Flotte. RouterOS 7.23 (Mai 2026) hat den Katalog einsatzbereiter container-Apps erweitert und macht dies zu einer praktischen Option für ISPs und Laborbauer gleichermaßen.

Was Sind Containers auf MikroTik RouterOS?

Containers auf MikroTik RouterOS sind MikroTiks Implementierung von Linux-Containern, die es einem RouterOS-v7-Gerät erlaubt, isolierte, Docker-kompatible Anwendungs-Images direkt auf dem Router auszuführen. Sie arbeiten mit Images aus Docker Hub, GCR, Quay und anderen Registries, und obwohl RouterOS statt des docker-Befehls eine eigene CLI-Syntax verwendet, ist das zugrunde liegende Verhalten dasselbe — ein Image ziehen, ihm ein Netzwerk geben, Speicher einhängen und es ausführen. (MikroTik-Dokumentation)

Für einen ISP oder ein Labor bedeutet das, dass kleine netznahe Dienste mit der Routing-Ebene zusammengelegt werden können: ein Pi-hole- oder AdGuard-DNS-Filter, ein Monitoring-Agent, ein Reverse-Proxy oder eine IoT-Bridge. Die stabile Version RouterOS 7.23 vom 25. Mai 2026 fügte eine lange Liste einsatzbereiter Apps hinzu — darunter paperless-ngx, nextcloud, lorawan-stack, birdnet-go und Docker-Management-Frontends wie portainer und dockge — zusammen mit einem neuen Schalter network-outgoing-access, um einen container am Aufbau ausgehenden Datenverkehrs zu hindern. (RouterOS-7.23-Changelog)

Anforderungen und Hardware

Das container-Paket ist mit den Architekturen arm, arm64 und x86 kompatibel und muss vor allem anderen installiert werden. Das Ziehen eines Remote-Images braucht viel freien Speicher, daher empfiehlt MikroTik externen Speicher statt des internen Flash-Speichers des Geräts. (MikroTik-Dokumentation)

Planen Sie externe Medien per USB, SATA oder NVMe ein, formatiert mit einem von RouterOS unterstützten Dateisystem. MikroTik empfiehlt eine Disk, die mindestens 100 MB/s sequentiellen Durchsatz und 10K zufällige IOPS schafft — langsamere Disks machen das Entpacken des Images quälend lang. Vermeiden Sie es, container-Volumes auf dem internen Speicher abzulegen, der klein ist und unter den Schreibmustern von container verschleißt. Geräte mit sehr begrenztem Flash sollten vorgefertigte Images auf der angeschlossenen Disk verwenden, statt sie aus der Ferne zu ziehen.

Container-Device-Mode Sicher Aktivieren

Container sind standardmäßig deaktiviert und erfordern aus gutem Grund physischen Zugriff zum Einschalten. Aktivieren Sie die Funktion mit:

/system/device-mode/update container=yes

RouterOS wartet dann darauf, dass Sie mit einem Druck auf die Reset-Taste oder einem Kaltstart bestätigen. Dieses Tor der physischen Bestätigung ist eine bewusste Sicherheitskontrolle: Sobald der Container-Modus aktiv ist, können container aus der Ferne hinzugefügt, gestartet und entfernt werden, und ein bösartiges Image kann zu einem Standbein auf dem Router werden. MikroTik ist da deutlich — wenn Ihr RouterOS-Gerät kompromittiert ist, machen container das Installieren bösartiger Software trivial, und für Images von Drittanbietern gibt es keine Sicherheitsgarantie.

Behandeln Sie den Router, der container hostet, als genau so sicher wie das am wenigsten vertrauenswürdige Image, das Sie darauf ausführen. Stellen Sie nur Images bereit, denen Sie vertrauen, halten Sie das Gerät hinter einer Firewall und lesen Sie unseren Leitfaden zum sicheren Betrieb des Device-Mode, bevor Sie dies in der Produktion aktivieren.

Das Container-Netzwerk Aufbauen

Container benötigen ein virtuelles Interface, eine Bridge und NAT, um das Internet zu erreichen. Das folgende Muster spiegelt das „Bridge”-Netzwerk in Docker wider. Erstellen Sie zunächst ein veth-Interface und eine Bridge, die ihre Gateway-Adresse teilt:

/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

Ein veth kann viele container bedienen, und das Erstellen zusätzlicher veth/Bridge-Paare erlaubt es, Gruppen von container voneinander zu isolieren. Wenn Sie neu im RouterOS-Bridging sind, erklärt unser Tutorial zur Bridge-Konfiguration das zugrunde liegende Modell. Fügen Sie als Nächstes eine Masquerade-Regel hinzu, damit ausgehender container-Verkehr übersetzt wird — das vollständige Bild finden Sie im Leitfaden zur NAT-Konfiguration:

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

Ihren Ersten Container Bereitstellen

Verweisen Sie Registry und temporäres Entpackverzeichnis auf Ihre externe Disk und fügen Sie dann das Image hinzu. Das folgende Pi-hole-Beispiel ist das kanonische aus der MikroTik-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

Das Hinzufügen des container startet den Download und das Entpacken, führt ihn aber nicht aus. Prüfen Sie den Fortschritt mit /container/print und warten Sie bis status=stopped, dann starten Sie ihn:

/container/start pihole

Veröffentlichen Sie schließlich den Dienst, indem Sie einen Port vom Router an die veth-Adresse weiterleiten:

/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 antwortet nun auf der LAN-IP des Routers. DNS-Filterung auf diese Weise zu betreiben, ist eine Alternative zu den nativen Blocklists von RouterOS — wenn Sie den Weg ohne container bevorzugen, sehen Sie sich unser RouterOS-Adlist-Tutorial an.

Container über eine Flotte Verwalten

Ein einzelner container auf einem Router ist einfach. Die eigentliche betriebliche Frage für einen ISP ist Konsistenz: dasselbe Image, dasselbe veth- und NAT-Schema, dasselbe Speicher-Layout und dieselben start-on-boot- und Speichergrenzen auf jedem Gerät. RouterOS gibt Ihnen die Primitive — start-on-boot=yes überlebt Neustarts, und memory-high oder memory-max begrenzen den RAM pro container, damit ein außer Kontrolle geratener Dienst die Routing-Ebene nicht aushungert:

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

Der schwierige Teil ist, dies identisch über Dutzende oder Hunderte entfernter Router zu tun und dann nachzuweisen, dass jeder einzelne nach einem Neustart tatsächlich wieder hochgefahren ist — besonders wenn das Gerät hinter CGNAT sitzt und Sie seine öffentliche IP nicht einfach erreichen können.

Tipps

• Halten Sie jedes container-Volume auf der externen Disk; niemals auf dem internen NAND.
• Verwenden Sie ein separates veth/Bridge-Paar, um nicht vertrauenswürdige container von vertrauenswürdigen zu isolieren.
• Setzen Sie memory-max auf alles, dem Sie nicht voll vertrauen, damit der Router reaktionsfähig bleibt.
• Für eine saubere Testumgebung, bevor Sie die Produktion anfassen, führen Sie dieselben Images auf einer virtualisierten CHR-Instanz aus, bevor Sie sie auf physischen Routern bereitstellen.

Machen Sie den Nächsten Schritt

Container verwandeln einen MikroTik-Router in einen winzigen Anwendungs-Host, aber eine Flotte solcher Hosts braucht Orchestrierung. MKController erstellt zentral Vorlagen für die RouterOS-Konfiguration, wendet sie auf jedes Gerät in Ihrem Bestand an und verfolgt Drift, sodass Sie sehen, welcher Router abgewichen ist — und über NATCloud erreicht es Geräte hinter CGNAT, um zu bestätigen, dass ein container nach der Wartung neu gestartet ist. Das schließt die Lücke zwischen der manuellen Konfiguration eines container und dem zuverlässigen Betrieb über ein ganzes ISP-Netzwerk.

Starten Sie Ihre kostenlose MKController-Testversion