RouterOS Containers: รัน Docker บน MikroTik

สรุป MikroTik RouterOS v7 สามารถรัน container ที่เข้ากันได้กับ Docker ได้โดยตรงบนเราเตอร์ ทำให้การกรอง DNS เอเจนต์มอนิเตอร์ และบริการเครือข่ายขนาดเล็กอยู่ข้างเคียงกับเลเยอร์การเราต์แทนที่จะอยู่บนกล่องแยกต่างหาก คู่มือนี้ครอบคลุมข้อกำหนดด้านฮาร์ดแวร์และสถาปัตยกรรม การเปิด container device-mode อย่างปลอดภัย การสร้างเครือข่าย veth และ bridge ด้วย NAT การปรับใช้ container ตัวแรกของคุณ และการจัดการ container ทั่วทั้งฟลีต RouterOS 7.23 (พฤษภาคม 2026) ได้ขยายแคตตาล็อกของแอป container ที่พร้อมใช้งาน ทำให้สิ่งนี้เป็นทางเลือกที่ใช้งานได้จริงทั้งสำหรับ ISP และผู้สร้างแล็บ

Containers บน MikroTik RouterOS คืออะไร?

Containers บน MikroTik RouterOS คือการนำ Linux container มาใช้งานของ MikroTik ที่ให้อุปกรณ์ RouterOS v7 รัน application image ที่แยกออกจากกันและเข้ากันได้กับ Docker ได้โดยตรงบนเราเตอร์ มันทำงานกับ image จาก Docker Hub, GCR, Quay และ registry อื่น ๆ และแม้ว่า RouterOS จะใช้ไวยากรณ์ CLI ของตัวเองแทนคำสั่ง docker แต่พฤติกรรมเบื้องหลังก็เหมือนกัน — ดึง image ให้เครือข่าย เมาต์พื้นที่จัดเก็บ แล้วรันมัน (เอกสาร MikroTik)

สำหรับ ISP หรือแล็บ นี่หมายความว่าบริการขนาดเล็กที่อยู่ใกล้เครือข่ายสามารถวางร่วมกับเลเยอร์การเราต์ได้: ตัวกรอง DNS แบบ Pi-hole หรือ AdGuard เอเจนต์มอนิเตอร์ reverse proxy หรือ IoT bridge รุ่นเสถียร RouterOS 7.23 เมื่อวันที่ 25 พฤษภาคม 2026 ได้เพิ่มรายการแอปที่พร้อมใช้งานยาวเหยียด — รวมถึง paperless-ngx, nextcloud, lorawan-stack, birdnet-go และส่วนหน้าจัดการ Docker อย่าง portainer และ dockge — พร้อมกับสวิตช์ network-outgoing-access ใหม่เพื่อบล็อก container ไม่ให้เริ่มทราฟฟิกขาออก (RouterOS 7.23 changelog)

ข้อกำหนดและฮาร์ดแวร์

แพ็กเกจ container เข้ากันได้กับสถาปัตยกรรม arm, arm64 และ x86 และต้องติดตั้งก่อนสิ่งอื่นใด การดึง remote image ต้องใช้พื้นที่ว่างมาก ดังนั้น MikroTik จึงแนะนำพื้นที่จัดเก็บภายนอกแทนแฟลชภายในของอุปกรณ์ (เอกสาร MikroTik)

วางแผนใช้สื่อภายนอกบน USB, SATA หรือ NVMe ที่ฟอร์แมตด้วยระบบไฟล์ที่ RouterOS รองรับ MikroTik แนะนำดิสก์ที่สามารถทำทรูพุตแบบลำดับได้อย่างน้อย 100 MB/s และ 10K random IOPS — ดิสก์ที่ช้ากว่าจะทำให้การแตก image ใช้เวลานานอย่างทรมาน หลีกเลี่ยงการวางวอลุ่ม container บนพื้นที่จัดเก็บในตัวซึ่งมีขนาดเล็กและเสื่อมสภาพภายใต้รูปแบบการเขียนของ container อุปกรณ์ที่มีแฟลชจำกัดมากควรใช้ image ที่สร้างไว้ล่วงหน้าบนดิสก์ที่ต่อพ่วงแทนการดึงจากระยะไกล

เปิด Container Device-Mode อย่างปลอดภัย

Container ถูกปิดใช้งานโดยค่าเริ่มต้น และด้วยเหตุผลที่ดี จำเป็นต้องเข้าถึงทางกายภาพเพื่อเปิด เปิดคุณสมบัตินี้ด้วย:

/system/device-mode/update container=yes

จากนั้น RouterOS จะรอให้คุณยืนยันด้วยการกดปุ่ม reset หรือรีบูตแบบเย็น ประตูยืนยันทางกายภาพนี้เป็นการควบคุมความปลอดภัยโดยเจตนา: เมื่อเปิดโหมด container แล้ว container สามารถถูกเพิ่ม เริ่ม และลบจากระยะไกลได้ และ image ที่เป็นอันตรายอาจกลายเป็นจุดยึดบนเราเตอร์ได้ MikroTik พูดตรง ๆ เรื่องนี้ — หากอุปกรณ์ RouterOS ของคุณถูกบุกรุก container จะทำให้การติดตั้งซอฟต์แวร์ที่เป็นอันตรายเป็นเรื่องง่าย และไม่มีการรับประกันความปลอดภัยสำหรับ image ของบุคคลที่สาม

จงปฏิบัติต่อเราเตอร์ที่โฮสต์ container ว่าปลอดภัยเท่ากับ image ที่น่าเชื่อถือน้อยที่สุดที่คุณรันบนมันพอดี ปรับใช้เฉพาะ image ที่คุณไว้วางใจ เก็บอุปกรณ์ไว้หลังไฟร์วอลล์ และอ่านคู่มือการดำเนินงานความปลอดภัย device-mode ของเราก่อนเปิดใช้สิ่งนี้ในการใช้งานจริง

สร้างเครือข่าย Container

Container ต้องการ virtual interface, bridge และ NAT เพื่อเข้าถึงอินเทอร์เน็ต รูปแบบด้านล่างสะท้อนเครือข่ายแบบ “bridge” ใน Docker ก่อนอื่นสร้าง veth interface และ bridge ที่แชร์ที่อยู่ gateway ของมัน:

/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 ตัวเดียวสามารถให้บริการ container ได้หลายตัว และการสร้างคู่ veth/bridge เพิ่มเติมช่วยให้คุณแยกกลุ่มของ container ออกจากกันได้ หากคุณเพิ่งเริ่มใช้ bridging ของ RouterOS บทแนะนำการตั้งค่า bridge ของเราอธิบายโมเดลพื้นฐาน ต่อไปให้เพิ่มกฎ masquerade เพื่อให้ทราฟฟิก container ขาออกถูกแปล — ดูคู่มือการตั้งค่า NAT สำหรับภาพรวมทั้งหมด:

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

ปรับใช้ Container ตัวแรกของคุณ

ชี้ registry และไดเรกทอรีแตกไฟล์ชั่วคราวไปยังดิสก์ภายนอกของคุณ แล้วเพิ่ม image ตัวอย่าง 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 จะเริ่มการดาวน์โหลดและแตกไฟล์ แต่ยังไม่รันมัน ตรวจสอบความคืบหน้าด้วย /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 ด้วยวิธีนี้เป็นทางเลือกแทน blocklist ดั้งเดิมของ RouterOS — หากคุณชอบเส้นทางที่ไม่ใช้ container ดูบทแนะนำ RouterOS adlist ของเรา

จัดการ Containers ทั่วทั้งฟลีต

Container ตัวเดียวบนเราเตอร์ตัวเดียวนั้นง่าย คำถามด้านปฏิบัติการที่แท้จริงสำหรับ ISP คือความสอดคล้อง: image เดียวกัน รูปแบบ veth และ NAT เดียวกัน เลย์เอาต์พื้นที่จัดเก็บเดียวกัน และขีดจำกัด start-on-boot และหน่วยความจำเดียวกันบนทุกอุปกรณ์ RouterOS ให้พื้นฐานแก่คุณ — start-on-boot=yes อยู่รอดผ่านการรีบูต และ memory-high หรือ memory-max จำกัด RAM ต่อ container เพื่อไม่ให้บริการที่ควบคุมไม่ได้แย่งทรัพยากรเลเยอร์การเราต์:

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

ส่วนที่ยากคือการทำสิ่งนี้ให้เหมือนกันทั่วเราเตอร์ระยะไกลหลายสิบหรือหลายร้อยตัว แล้วพิสูจน์ว่าแต่ละตัวกลับมาทำงานจริงหลังการรีบูต — โดยเฉพาะเมื่ออุปกรณ์อยู่หลัง CGNAT และคุณไม่สามารถเข้าถึง IP สาธารณะของมันได้ง่าย ๆ

เคล็ดลับ

• เก็บทุกวอลุ่ม container ไว้บนดิสก์ภายนอก ไม่เคยบน NAND ภายใน
• ใช้คู่ veth/bridge แยกต่างหากเพื่อแยก container ที่ไม่น่าเชื่อถือออกจากที่น่าเชื่อถือ
• ตั้งค่า memory-max กับทุกสิ่งที่คุณไม่ไว้วางใจเต็มที่เพื่อให้เราเตอร์ตอบสนองได้ดี
• สำหรับสภาพแวดล้อมทดสอบที่สะอาดก่อนแตะการใช้งานจริง ให้รัน image เดียวกันบนอินสแตนซ์ CHR แบบเสมือนก่อนปรับใช้กับเราเตอร์จริง

ก้าวต่อไป

Container เปลี่ยนเราเตอร์ MikroTik ให้เป็นโฮสต์แอปพลิเคชันขนาดเล็ก แต่ฟลีตของโฮสต์เหล่านั้นต้องการการประสานงาน MKController สร้างเทมเพลตการกำหนดค่า RouterOS แบบรวมศูนย์ ใช้กับทุกอุปกรณ์ในคลังของคุณ และติดตามการเบี่ยงเบนเพื่อให้คุณเห็นว่าเราเตอร์ตัวใดเบี่ยงเบน — และผ่าน NATCloud มันเข้าถึงอุปกรณ์ที่อยู่หลัง CGNAT เพื่อยืนยันว่า container เริ่มต้นใหม่หลังการบำรุงรักษา นั่นปิดช่องว่างระหว่างการกำหนดค่า container ทีละตัวด้วยมือกับการดำเนินการอย่างน่าเชื่อถือทั่วทั้งเครือข่าย ISP

เริ่มทดลองใช้ MKController ฟรี