RouterOS Containers: Docker di MikroTik

Ringkasan MikroTik RouterOS v7 dapat menjalankan container yang kompatibel dengan Docker langsung di router, sehingga penyaringan DNS, agen pemantauan, dan layanan jaringan kecil berada di samping bidang routing, bukan di perangkat terpisah. Panduan ini membahas persyaratan hardware dan arsitektur, mengaktifkan device-mode container secara aman, membangun jaringan veth dan bridge dengan NAT, men-deploy container pertama Anda, dan mengelola container di seluruh fleet. RouterOS 7.23 (Mei 2026) memperluas katalog aplikasi container siap pakai, menjadikannya opsi praktis baik untuk ISP maupun pembangun lab.

Apa Itu Containers di MikroTik RouterOS?

Containers di MikroTik RouterOS adalah implementasi container Linux dari MikroTik yang memungkinkan perangkat RouterOS v7 menjalankan image aplikasi terisolasi dan kompatibel dengan Docker langsung di router. Mereka bekerja dengan image dari Docker Hub, GCR, Quay, dan registry lainnya, dan meskipun RouterOS menggunakan sintaks CLI-nya sendiri alih-alih perintah docker, perilaku dasarnya sama — tarik image, beri jaringan, pasang penyimpanan, dan jalankan. (Dokumentasi MikroTik)

Bagi ISP atau lab, ini berarti layanan kecil yang berdekatan dengan jaringan dapat ditempatkan bersama bidang routing: filter DNS Pi-hole atau AdGuard, agen pemantauan, reverse proxy, atau jembatan IoT. Rilis stabil RouterOS 7.23 pada 25 Mei 2026 menambahkan daftar panjang aplikasi siap pakai — termasuk paperless-ngx, nextcloud, lorawan-stack, birdnet-go, dan front-end manajemen Docker seperti portainer dan dockge — bersama switch baru network-outgoing-access untuk memblokir container memulai lalu lintas keluar. (Changelog RouterOS 7.23)

Persyaratan dan Hardware

Paket container kompatibel dengan arsitektur arm, arm64, dan x86, dan harus dipasang sebelum hal lainnya. Menarik image remote membutuhkan banyak ruang kosong, jadi MikroTik merekomendasikan penyimpanan eksternal alih-alih flash internal perangkat. (Dokumentasi MikroTik)

Rencanakan media eksternal di USB, SATA, atau NVMe, yang diformat dengan filesystem yang didukung RouterOS. MikroTik menyarankan disk yang mampu setidaknya 100 MB/s throughput sekuensial dan 10K IOPS acak — disk yang lebih lambat membuat ekstraksi image sangat lama. Hindari menempatkan volume container di penyimpanan internal, yang kecil dan cepat aus di bawah pola penulisan container. Perangkat dengan flash sangat terbatas sebaiknya menggunakan image pra-bangun di disk yang terpasang, alih-alih menariknya secara remote.

Aktifkan Device-Mode Container dengan Aman

Container nonaktif secara default dan, untuk alasan yang baik, memerlukan akses fisik untuk menyalakannya. Aktifkan fitur ini dengan:

/system/device-mode/update container=yes

RouterOS kemudian menunggu Anda mengonfirmasi dengan menekan tombol reset atau cold reboot. Gerbang konfirmasi fisik ini adalah kontrol keamanan yang disengaja: begitu mode container menyala, container dapat ditambahkan, dijalankan, dan dihapus dari jarak jauh, dan image berbahaya dapat menjadi pijakan di router. MikroTik berterus terang soal ini — jika perangkat RouterOS Anda disusupi, container membuat pemasangan perangkat lunak berbahaya menjadi sepele, dan tidak ada jaminan keamanan untuk image pihak ketiga.

Perlakukan router yang menghosting container persis seaman image paling tidak tepercaya yang Anda jalankan di atasnya. Hanya deploy image yang Anda percayai, jaga perangkat tetap di-firewall, dan tinjau panduan operasi keamanan device-mode kami sebelum mengaktifkan ini di produksi.

Bangun Jaringan Container

Container membutuhkan interface virtual, bridge, dan NAT untuk menjangkau internet. Pola di bawah ini mencerminkan jaringan “bridge” di Docker. Pertama, buat interface veth dan bridge yang berbagi alamat gateway-nya:

/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

Satu veth dapat melayani banyak container, dan membuat pasangan veth/bridge tambahan memungkinkan Anda mengisolasi grup container satu sama lain. Jika Anda baru mengenal bridging RouterOS, tutorial konfigurasi bridge kami menjelaskan model dasarnya. Selanjutnya, tambahkan aturan masquerade agar lalu lintas keluar container diterjemahkan — lihat panduan konfigurasi NAT untuk gambaran lengkapnya:

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

Deploy Container Pertama Anda

Arahkan registry dan direktori ekstraksi sementara ke disk eksternal Anda, lalu tambahkan image. Contoh Pi-hole di bawah ini adalah contoh kanonik dari dokumentasi 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

Menambahkan container memulai unduhan dan ekstraksi, tetapi tidak menjalankannya. Periksa progres dengan /container/print dan tunggu hingga status=stopped, lalu jalankan:

/container/start pihole

Terakhir, publikasikan layanan dengan meneruskan port dari router ke alamat 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 kini menjawab di IP LAN router. Menjalankan penyaringan DNS dengan cara ini adalah alternatif dari blocklist bawaan RouterOS — jika Anda lebih suka jalur tanpa container, lihat tutorial adlist RouterOS kami.

Kelola Container di Seluruh Fleet

Satu container di satu router itu mudah. Pertanyaan operasional sebenarnya bagi ISP adalah konsistensi: image yang sama, skema veth dan NAT yang sama, tata letak penyimpanan yang sama, serta batas start-on-boot dan memori yang sama di setiap perangkat. RouterOS memberi Anda primitifnya — start-on-boot=yes bertahan setelah reboot, dan memory-high atau memory-max membatasi RAM per container agar layanan yang lepas kendali tidak menguras bidang routing:

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

Bagian sulitnya adalah melakukan ini secara identik di puluhan atau ratusan router remote, lalu membuktikan masing-masing benar-benar kembali menyala setelah reboot — terutama ketika perangkat berada di balik CGNAT dan Anda tidak bisa begitu saja menjangkau IP publiknya.

Tips

• Simpan setiap volume container di disk eksternal; jangan pernah di NAND internal.
• Gunakan pasangan veth/bridge terpisah untuk mengisolasi container tidak tepercaya dari yang tepercaya.
• Atur memory-max pada apa pun yang tidak sepenuhnya Anda percayai agar router tetap responsif.
• Untuk lingkungan uji yang bersih sebelum menyentuh produksi, jalankan image yang sama di instance CHR tervirtualisasi sebelum men-deploy ke router fisik.

Ambil Langkah Berikutnya

Container mengubah router MikroTik menjadi host aplikasi mungil, tetapi sebuah fleet dari host tersebut membutuhkan orkestrasi. MKController membuat template konfigurasi RouterOS secara terpusat, menerapkannya ke setiap perangkat di inventaris Anda, dan melacak drift sehingga Anda bisa melihat router mana yang menyimpang — dan melalui NATCloud, ia menjangkau perangkat di balik CGNAT untuk memastikan sebuah container telah restart setelah pemeliharaan. Itu menutup celah antara mengonfigurasi satu container secara manual dan mengoperasikannya dengan andal di seluruh jaringan ISP.

Mulai uji coba gratis MKController Anda