RouterOS Containers: MikroTik에서 Docker

요약 MikroTik RouterOS v7은 Docker 호환 컨테이너를 라우터에서 직접 실행할 수 있어, DNS 필터링, 모니터링 에이전트, 소규모 네트워크 서비스를 별도의 장비가 아닌 라우팅 플레인 옆에 둘 수 있습니다. 이 가이드는 하드웨어와 아키텍처 요구 사항, 컨테이너 device-mode의 안전한 활성화, NAT를 포함한 veth 및 브리지 네트워킹 구성, 첫 컨테이너 배포, 그리고 전체 장치에 걸친 컨테이너 관리를 다룹니다. RouterOS 7.23(2026년 5월)은 바로 실행 가능한 컨테이너 앱 카탈로그를 확장하여, ISP와 랩 구축자 모두에게 실용적인 선택지가 되었습니다.

MikroTik RouterOS의 컨테이너란?

MikroTik RouterOS의 컨테이너는 RouterOS v7 장치가 격리된 Docker 호환 애플리케이션 이미지를 라우터에서 직접 실행할 수 있게 해주는, MikroTik의 Linux 컨테이너 구현입니다. Docker Hub, GCR, Quay 및 기타 레지스트리의 이미지로 동작하며, RouterOS는 docker 명령 대신 자체 CLI 구문을 사용하지만 기본 동작은 동일합니다 — 이미지를 풀하고, 네트워크를 부여하고, 스토리지를 마운트하여 실행합니다. (MikroTik 문서)

ISP나 랩의 경우, 이는 네트워크 인접 소규모 서비스를 라우팅 플레인과 함께 배치할 수 있음을 의미합니다. Pi-hole 또는 AdGuard DNS 필터, 모니터링 에이전트, 리버스 프록시, IoT 브리지 등이 그 예입니다. 2026년 5월 25일 안정 버전 RouterOS 7.23은 바로 실행 가능한 앱의 긴 목록을 추가했습니다 — paperless-ngx, nextcloud, lorawan-stack, birdnet-go, 그리고 portainer나 dockge 같은 Docker 관리 프런트엔드 등 — 아울러 컨테이너가 아웃바운드 트래픽을 시작하지 못하도록 차단하는 새로운 network-outgoing-access 스위치도 추가되었습니다. (RouterOS 7.23 changelog)

요구 사항과 하드웨어

container 패키지는 arm, arm64, x86 아키텍처와 호환되며, 다른 무엇보다 먼저 설치해야 합니다. 원격 이미지를 풀하려면 많은 여유 공간이 필요하므로, MikroTik은 장치의 내부 플래시 대신 외장 스토리지를 권장합니다. (MikroTik 문서)

RouterOS가 지원하는 파일 시스템으로 포맷한 USB, SATA 또는 NVMe 외장 미디어를 계획하세요. MikroTik은 최소 100 MB/s의 순차 처리량과 10K 랜덤 IOPS를 처리할 수 있는 디스크를 제안합니다 — 더 느린 디스크는 이미지 추출을 고통스러울 만큼 길게 만듭니다. 컨테이너 볼륨을 내장 스토리지에 두는 것은 피하세요. 용량이 작고 컨테이너 쓰기 패턴에서 마모됩니다. 플래시가 매우 제한된 장치는 원격으로 풀하는 대신 연결된 디스크의 사전 빌드된 이미지를 사용해야 합니다.

컨테이너 Device-Mode 안전하게 활성화

컨테이너는 기본적으로 비활성화되어 있으며, 합당한 이유로 활성화하려면 물리적 접근이 필요합니다. 다음으로 기능을 활성화합니다.

/system/device-mode/update container=yes

그러면 RouterOS는 리셋 버튼 누름 또는 콜드 리부트로 확인하기를 기다립니다. 이 물리적 확인 관문은 의도적인 보안 통제입니다. 일단 컨테이너 모드가 켜지면 컨테이너를 원격으로 추가, 시작, 제거할 수 있으며, 악성 이미지가 라우터의 발판이 될 수 있습니다. MikroTik은 이 점을 분명히 말합니다 — RouterOS 장치가 손상되면 컨테이너로 인해 악성 소프트웨어 설치가 손쉬워지며, 서드파티 이미지에 대한 보안 보장은 없습니다.

컨테이너를 호스팅하는 라우터는 그 위에서 실행하는 가장 신뢰할 수 없는 이미지와 정확히 같은 수준으로만 안전하다고 여기세요. 신뢰하는 이미지만 배포하고, 장치를 방화벽 뒤에 두며, 운영 환경에서 활성화하기 전에 당사의 device-mode 보안 운영 가이드를 읽어보세요.

컨테이너 네트워크 구성

컨테이너가 인터넷에 도달하려면 가상 인터페이스, 브리지, NAT가 필요합니다. 아래 패턴은 Docker의 “브리지” 네트워킹을 반영합니다. 먼저 게이트웨이 주소를 공유하는 veth 인터페이스와 브리지를 만듭니다.

/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

하나의 veth는 여러 컨테이너를 처리할 수 있으며, 추가 veth/브리지 쌍을 만들면 컨테이너 그룹을 서로 격리할 수 있습니다. RouterOS 브리징이 처음이라면, 당사의 브리지 구성 튜토리얼이 기본 모델을 설명합니다. 다음으로, 아웃바운드 컨테이너 트래픽이 변환되도록 masquerade 규칙을 추가합니다 — 전체 그림은 NAT 구성 가이드를 참조하세요.

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

첫 컨테이너 배포

레지스트리와 임시 추출 디렉터리를 외장 디스크로 지정한 뒤 이미지를 추가합니다. 아래 Pi-hole 예시는 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

컨테이너를 추가하면 다운로드와 추출이 시작되지만 실행되지는 않습니다. /container/print로 진행 상황을 확인하고 status=stopped가 될 때까지 기다린 뒤 시작합니다.

/container/start pihole

마지막으로, 라우터에서 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이 라우터의 LAN IP에서 응답합니다. 이 방식으로 DNS 필터링을 실행하는 것은 RouterOS의 기본 차단 목록에 대한 대안입니다 — 컨테이너 없는 방식을 선호한다면, 당사의 RouterOS adlist 튜토리얼을 참조하세요.

전체 장치에 걸친 컨테이너 관리

한 라우터의 단일 컨테이너는 쉽습니다. ISP에게 진짜 운영상의 과제는 일관성입니다. 모든 장치에서 동일한 이미지, 동일한 veth 및 NAT 체계, 동일한 스토리지 레이아웃, 동일한 start-on-boot 및 메모리 한도를 유지하는 것입니다. RouterOS는 이를 위한 기본 요소를 제공합니다 — start-on-boot=yes는 재부팅 후에도 유지되며, memory-high 또는 memory-max는 컨테이너당 RAM을 제한하여 통제 불능 서비스가 라우팅 플레인을 고갈시키지 못하게 합니다.

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

어려운 부분은 이를 수십 대 또는 수백 대의 원격 라우터에서 동일하게 수행한 뒤, 각각이 재부팅 후 실제로 다시 가동되었음을 증명하는 것입니다 — 특히 장치가 CGNAT 뒤에 있어 공용 IP에 단순히 접근할 수 없는 경우에 그렇습니다.

팁

• 모든 컨테이너 볼륨을 외장 디스크에 두고, 내부 NAND에는 절대 두지 마세요.
• 신뢰할 수 없는 컨테이너를 신뢰하는 컨테이너로부터 격리하려면 별도의 veth/브리지 쌍을 사용하세요.
• 라우터의 응답성을 유지하기 위해, 완전히 신뢰하지 않는 모든 것에 memory-max를 설정하세요.
• 운영 환경을 건드리기 전 깨끗한 테스트 환경으로, 물리 라우터에 배포하기 전에 가상화된 CHR 인스턴스에서 동일한 이미지를 실행하세요.

다음 단계로

컨테이너는 MikroTik 라우터를 작은 애플리케이션 호스트로 바꾸지만, 이러한 호스트의 집합에는 오케스트레이션이 필요합니다. MKController는 RouterOS 구성을 중앙에서 템플릿화하고, 인벤토리의 모든 장치에 적용하며, 드리프트를 추적하여 어떤 라우터가 벗어났는지 확인할 수 있게 합니다 — 그리고 NATCloud를 통해 CGNAT 뒤의 장치에도 도달하여 유지보수 후 컨테이너가 재시작되었는지 확인합니다. 이는 컨테이너 하나를 수작업으로 구성하는 것과 ISP 네트워크 전체에서 이를 안정적으로 운영하는 것 사이의 간극을 메웁니다.

MKController 무료 체험 시작하기