Kontenery RouterOS: Docker na MikroTik

Podsumowanie MikroTik RouterOS v7 może uruchamiać kontenery zgodne z Docker bezpośrednio na routerze, dzięki czemu filtrowanie DNS, agenci monitorowania i niewielkie usługi sieciowe działają obok płaszczyzny routingu, a nie na osobnym urządzeniu. Ten przewodnik obejmuje wymagania sprzętowe i architektoniczne, bezpieczne włączanie trybu container device-mode, budowę sieci veth i bridge z NAT, wdrażanie pierwszego kontenera oraz zarządzanie kontenerami w całej flocie. RouterOS 7.23 (maj 2026) rozszerzył katalog gotowych do uruchomienia aplikacji kontenerowych, czyniąc to praktyczną opcją zarówno dla ISP, jak i budowniczych laboratoriów.

Czym Są Kontenery na MikroTik RouterOS?

Kontenery na MikroTik RouterOS to implementacja kontenerów Linux firmy MikroTik, która pozwala urządzeniu RouterOS v7 uruchamiać izolowane, zgodne z Docker obrazy aplikacji bezpośrednio na routerze. Współpracują one z obrazami z Docker Hub, GCR, Quay i innych rejestrów, a chociaż RouterOS używa własnej składni CLI zamiast polecenia docker, podstawowe działanie jest takie samo — pobierz obraz, nadaj mu sieć, zamontuj pamięć i uruchom go. (Dokumentacja MikroTik)

Dla ISP lub laboratorium oznacza to, że niewielkie usługi związane z siecią można umieścić obok płaszczyzny routingu: filtr DNS Pi-hole lub AdGuard, agent monitorowania, reverse proxy lub mostek IoT. Stabilne wydanie RouterOS 7.23 z 25 maja 2026 r. dodało długą listę gotowych do uruchomienia aplikacji — w tym paperless-ngx, nextcloud, lorawan-stack, birdnet-go oraz interfejsy zarządzania Docker, takie jak portainer i dockge — wraz z nowym przełącznikiem network-outgoing-access, blokującym inicjowanie ruchu wychodzącego przez kontener. (Dziennik zmian RouterOS 7.23)

Wymagania i Sprzęt

Pakiet container jest zgodny z architekturami arm, arm64 i x86 i musi zostać zainstalowany przed wszystkim innym. Pobieranie zdalnego obrazu wymaga dużej ilości wolnego miejsca, dlatego MikroTik zaleca pamięć zewnętrzną zamiast wewnętrznej pamięci flash urządzenia. (Dokumentacja MikroTik)

Zaplanuj nośniki zewnętrzne przez USB, SATA lub NVMe, sformatowane systemem plików obsługiwanym przez RouterOS. MikroTik sugeruje dysk zdolny do co najmniej 100 MB/s przepustowości sekwencyjnej i 10K losowych IOPS — wolniejsze dyski sprawiają, że wypakowywanie obrazu trwa boleśnie długo. Unikaj umieszczania woluminów kontenerów na pamięci wbudowanej, która jest mała i zużywa się pod wpływem wzorców zapisu kontenerów. Urządzenia z bardzo ograniczoną pamięcią flash powinny używać gotowych obrazów na podłączonym dysku zamiast pobierać je zdalnie.

Bezpieczne Włączanie Trybu Container Device-Mode

Kontenery są domyślnie wyłączone i, nie bez powodu, wymagają fizycznego dostępu do włączenia. Włącz funkcję poleceniem:

/system/device-mode/update container=yes

RouterOS czeka następnie, aż potwierdzisz naciśnięciem przycisku reset lub zimnym restartem. Ta bramka fizycznego potwierdzenia to celowy mechanizm bezpieczeństwa: gdy tryb kontenerów jest włączony, kontenery można dodawać, uruchamiać i usuwać zdalnie, a złośliwy obraz może stać się przyczółkiem na routerze. MikroTik mówi o tym wprost — jeśli Twoje urządzenie RouterOS zostanie skompromitowane, kontenery sprawiają, że instalacja złośliwego oprogramowania staje się trywialna, a dla obrazów stron trzecich nie ma gwarancji bezpieczeństwa.

Traktuj router hostujący kontenery jako dokładnie tak bezpieczny, jak najmniej zaufany obraz, który na nim uruchamiasz. Wdrażaj tylko obrazy, którym ufasz, trzymaj urządzenie za zaporą sieciową i przeczytaj nasz przewodnik po bezpiecznej obsłudze device-mode, zanim włączysz to w środowisku produkcyjnym.

Budowa Sieci Kontenerów

Kontenery potrzebują interfejsu wirtualnego, mostka i NAT, aby uzyskać dostęp do internetu. Poniższy wzorzec odzwierciedla sieć „bridge” w Docker. Najpierw utwórz interfejs veth i mostek, który współdzieli jego adres bramy:

/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

Jeden veth może obsługiwać wiele kontenerów, a tworzenie dodatkowych par veth/bridge pozwala izolować grupy kontenerów od siebie. Jeśli dopiero zaczynasz pracę z mostkowaniem w RouterOS, nasz poradnik konfiguracji bridge wyjaśnia podstawowy model. Następnie dodaj regułę masquerade, aby wychodzący ruch kontenerów był tłumaczony — pełny obraz znajdziesz w przewodniku konfiguracji NAT:

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

Wdróż Swój Pierwszy Kontener

Skieruj registry i tymczasowy katalog wypakowywania na dysk zewnętrzny, a następnie dodaj obraz. Poniższy przykład Pi-hole jest kanonicznym przykładem z dokumentacji 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

Dodanie kontenera rozpoczyna pobieranie i wypakowywanie, ale go nie uruchamia. Sprawdź postęp za pomocą /container/print i poczekaj, aż status=stopped, a następnie uruchom go:

/container/start pihole

Na koniec opublikuj usługę, przekierowując port z routera na adres veth:

/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 odpowiada teraz na adresie IP LAN routera. Uruchamianie filtrowania DNS w ten sposób jest alternatywą dla natywnych list blokowania RouterOS — jeśli wolisz ścieżkę bez kontenera, zobacz nasz poradnik RouterOS adlist.

Zarządzanie Kontenerami w Całej Flocie

Pojedynczy kontener na jednym routerze jest prosty. Prawdziwym pytaniem operacyjnym dla ISP jest spójność: ten sam obraz, ten sam schemat veth i NAT, ten sam układ pamięci oraz te same limity start-on-boot i pamięci na każdym urządzeniu. RouterOS daje Ci podstawowe mechanizmy — start-on-boot=yes przetrwa restarty, a memory-high lub memory-max ograniczają pamięć RAM na kontener, aby wymknięta spod kontroli usługa nie zagłodziła płaszczyzny routingu:

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

Trudną częścią jest zrobienie tego identycznie na dziesiątkach lub setkach zdalnych routerów, a następnie udowodnienie, że każdy z nich faktycznie wstał ponownie po restarcie — zwłaszcza gdy urządzenie znajduje się za CGNAT i nie można po prostu dotrzeć do jego publicznego adresu IP.

Wskazówki

• Trzymaj każdy wolumin kontenera na dysku zewnętrznym; nigdy na wewnętrznej pamięci NAND.
• Użyj osobnej pary veth/bridge, aby izolować niezaufane kontenery od zaufanych.
• Ustaw memory-max na wszystkim, czemu nie ufasz w pełni, aby router pozostał responsywny.
• Aby uzyskać czyste środowisko testowe przed dotknięciem produkcji, uruchom te same obrazy na zwirtualizowanej instancji CHR, zanim wdrożysz je na fizycznych routerach.

Zrób Następny Krok

Kontenery zamieniają router MikroTik w niewielki host aplikacji, ale flota takich hostów wymaga orkiestracji. MKController centralnie tworzy szablony konfiguracji RouterOS, stosuje je na każdym urządzeniu w Twoim zasobie i śledzi rozbieżności, dzięki czemu widzisz, który router odbiegł od normy — a poprzez NATCloud dociera do urządzeń za CGNAT, aby potwierdzić, że kontener uruchomił się ponownie po konserwacji. To zamyka lukę między ręczną konfiguracją jednego kontenera a niezawodnym ich obsługiwaniem w całej sieci ISP.

Rozpocznij bezpłatny okres próbny MKController