حاويات RouterOS: تشغيل Docker على MikroTik

الملخص يمكن لـ MikroTik RouterOS v7 تشغيل حاويات متوافقة مع Docker مباشرة على الراوتر، بحيث تعيش تصفية DNS ووكلاء المراقبة وخدمات الشبكة الصغيرة بجانب مستوى التوجيه بدلًا من جهاز منفصل. يغطي هذا الدليل متطلبات العتاد والبنية المعمارية، وتفعيل وضع جهاز الحاويات بأمان، وبناء شبكة veth والجسر مع NAT، ونشر أول حاوية لك، وإدارة الحاويات عبر أسطول كامل. وسّع الإصدار RouterOS 7.23 (مايو 2026) فهرس تطبيقات الحاويات الجاهزة للتشغيل، مما يجعل هذا خيارًا عمليًا لمزودي خدمة الإنترنت وبناة المختبرات على حد سواء.

ما هي الحاويات على MikroTik RouterOS؟

الحاويات على MikroTik RouterOS هي تطبيق MikroTik لحاويات Linux الذي يتيح لجهاز RouterOS v7 تشغيل صور تطبيقات معزولة ومتوافقة مع Docker مباشرة على الراوتر. تعمل مع الصور من Docker Hub وGCR وQuay وسجلات أخرى، ورغم أن RouterOS يستخدم بناء جملة CLI الخاص به بدلًا من أمر docker، فإن السلوك الأساسي هو نفسه — اسحب صورة، امنحها شبكة، اربط التخزين، وشغّلها. (توثيق MikroTik)

بالنسبة لمزود خدمة الإنترنت أو المختبر، يعني هذا أنه يمكن وضع خدمات الشبكة الصغيرة المجاورة مع مستوى التوجيه: مرشح DNS من Pi-hole أو AdGuard، وكيل مراقبة، reverse proxy، أو جسر IoT. أضاف الإصدار المستقر RouterOS 7.23 في 25 مايو 2026 قائمة طويلة من التطبيقات الجاهزة للتشغيل — بما في ذلك paperless-ngx وnextcloud وlorawan-stack وbirdnet-go، وواجهات إدارة Docker مثل portainer وdockge — إلى جانب مفتاح جديد network-outgoing-access لمنع الحاوية من بدء حركة مرور صادرة. (سجل تغييرات RouterOS 7.23)

المتطلبات والعتاد

حزمة container متوافقة مع البنى المعمارية arm وarm64 وx86، ويجب تثبيتها قبل أي شيء آخر. يحتاج سحب صورة بعيدة إلى مساحة فارغة كبيرة، لذا توصي MikroTik بالتخزين الخارجي بدلًا من الذاكرة الداخلية للجهاز. (توثيق MikroTik)

خطّط لوسائط خارجية عبر USB أو SATA أو NVMe، مُهيأة بنظام ملفات يدعمه RouterOS. تقترح MikroTik قرصًا قادرًا على إنتاجية تسلسلية لا تقل عن 100 MB/s و10K IOPS عشوائية — فالأقراص الأبطأ تجعل استخراج الصور مؤلمًا في طوله. تجنب وضع وحدات تخزين الحاويات على الذاكرة المدمجة، فهي صغيرة وتتآكل تحت أنماط كتابة الحاويات. ينبغي للأجهزة ذات الذاكرة المحدودة جدًا استخدام صور مبنية مسبقًا على القرص المرفق بدلًا من السحب عن بُعد.

تفعيل وضع جهاز الحاويات بأمان

الحاويات معطّلة افتراضيًا، ولسبب وجيه، تتطلب وصولًا ماديًا لتفعيلها. فعّل الميزة بما يلي:

/system/device-mode/update container=yes

ثم ينتظر RouterOS أن تؤكد بالضغط على زر reset أو بإعادة تشغيل باردة. بوابة التأكيد المادي هذه هي ضابط أمان متعمّد: فبمجرد تفعيل وضع الحاويات، يمكن إضافة الحاويات وتشغيلها وإزالتها عن بُعد، ويمكن أن تصبح صورة خبيثة موطئ قدم على الراوتر. MikroTik صريحة بشأن هذا — إذا اختُرق جهاز RouterOS الخاص بك، فإن الحاويات تجعل تثبيت البرامج الخبيثة أمرًا تافهًا، ولا يوجد ضمان أمني لصور الأطراف الثالثة.

تعامل مع الراوتر الذي يستضيف الحاويات على أنه آمن تمامًا بقدر أقل الصور موثوقية التي تشغّلها عليه. انشر فقط الصور التي تثق بها، وأبقِ الجهاز محميًا بجدار حماية، وراجع دليل عمليات أمان وضع الجهاز قبل تفعيل هذا في الإنتاج.

بناء شبكة الحاويات

تحتاج الحاويات إلى واجهة افتراضية وجسر وNAT للوصول إلى الإنترنت. يعكس النمط أدناه شبكة “bridge” في 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/جسر إضافية يتيح لك عزل مجموعات الحاويات عن بعضها. إذا كنت جديدًا على bridging في 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 الآن على عنوان IP الخاص بشبكة LAN للراوتر. تشغيل تصفية DNS بهذه الطريقة هو بديل لقوائم الحظر الأصلية في RouterOS — إذا كنت تفضل المسار بدون حاوية، راجع دليل adlist في RouterOS.

إدارة الحاويات عبر أسطول

حاوية واحدة على راوتر واحد أمر سهل. السؤال التشغيلي الحقيقي لمزود خدمة الإنترنت هو الاتساق: الصورة نفسها، ومخطط 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 للتأكد من أن الحاوية أُعيد تشغيلها بعد الصيانة. وهذا يسد الفجوة بين تكوين حاوية واحدة يدويًا وتشغيلها بموثوقية عبر شبكة مزود خدمة إنترنت كاملة.

ابدأ تجربتك المجانية مع MKController