מכולות RouterOS: Docker ב-MikroTik

תקציר MikroTik RouterOS v7 יכול להריץ מכולות תואמות Docker ישירות על הנתב, כך שסינון DNS, סוכני ניטור ושירותי רשת קטנים שוכנים לצד מישור הניתוב במקום על תיבה נפרדת. מדריך זה מכסה את דרישות החומרה והארכיטקטורה, הפעלה בטוחה של מצב ההתקן container, בניית רשת veth ו-bridge עם NAT, פריסת המכולה הראשונה שלכם וניהול מכולות על פני צי שלם. RouterOS 7.23 (מאי 2026) הרחיב את קטלוג אפליקציות המכולה המוכנות להרצה, מה שהופך אפשרות זו למעשית הן לספקי אינטרנט והן לבוני מעבדה כאחד.

מה הן מכולות ב-MikroTik RouterOS?

מכולות ב-MikroTik RouterOS הן המימוש של MikroTik למכולות Linux, המאפשר להתקן RouterOS v7 להריץ images מבודדים ותואמי Docker של אפליקציות ישירות על הנתב. הן עובדות עם images מ-Docker Hub, GCR, Quay ומרשמים אחרים, ולמרות ש-RouterOS משתמש בתחביר CLI משלו במקום בפקודת docker, ההתנהגות הבסיסית זהה — למשוך image, לתת לו רשת, לחבר אחסון ולהריץ אותו. (תיעוד MikroTik)

עבור ספק אינטרנט או מעבדה, פירוש הדבר ששירותים קטנים הסמוכים לרשת יכולים לשכון יחד עם מישור הניתוב: מסנן DNS של Pi-hole או AdGuard, סוכן ניטור, פרוקסי הפוך או גשר 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, וחובה להתקין אותה לפני כל דבר אחר. משיכת image מרוחק דורשת הרבה מקום פנוי, ולכן MikroTik ממליצה על אחסון חיצוני במקום זיכרון ה-flash הפנימי של ההתקן. (תיעוד MikroTik)

תכננו מדיה חיצונית בחיבור USB, SATA או NVMe, מפורמטת במערכת קבצים ש-RouterOS תומך בה. MikroTik מציעה דיסק המסוגל לתפוקה רציפה של לפחות 100 MB/s ו-10K IOPS אקראיים — דיסקים איטיים יותר הופכים את חילוץ ה-image לארוך עד כאב. הימנעו מהצבת נפחי מכולות באחסון המובנה, שהוא קטן ונשחק תחת דפוסי הכתיבה של מכולות. בהתקנים עם flash מוגבל מאוד כדאי להשתמש ב-images מוכנים מראש בדיסק המחובר במקום למשוך מרחוק.

הפעילו את מצב ההתקן container בבטחה

מכולות מושבתות כברירת מחדל, ומסיבה טובה דורשות גישה פיזית כדי להפעיל אותן. הפעילו את התכונה באמצעות:

/system/device-mode/update container=yes

RouterOS ממתין אז שתאשרו בלחיצה על כפתור ה-reset או באתחול קר. שער האישור הפיזי הזה הוא בקרת אבטחה מכוונת: ברגע שמצב המכולות פעיל, ניתן להוסיף, להפעיל ולהסיר מכולות מרחוק, ו-image זדוני יכול להפוך לדריסת רגל על הנתב. MikroTik מנסחת זאת בבירור — אם התקן ה-RouterOS שלכם נפרץ, מכולות הופכות התקנת תוכנה זדונית לעניין של מה בכך, ואין כל ערובת אבטחה ל-images של צד שלישי.

התייחסו לנתב המארח מכולות כבטוח בדיוק כמו ה-image הכי פחות מהימן שאתם מריצים עליו. פרסו רק images שאתם בוטחים בהם, שמרו את ההתקן מאחורי חומת אש, וקראו את מדריך תפעול האבטחה של device-mode לפני הפעלת זאת בסביבת ייצור.

בנו את רשת המכולות

מכולות זקוקות לממשק וירטואלי, ל-bridge ול-NAT כדי להגיע לאינטרנט. התבנית להלן משקפת רשת “bridge” ב-Docker. תחילה צרו ממשק veth ו-bridge שחולק את כתובת השער שלו:

/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/bridge נוספים מאפשרת לבודד קבוצות של מכולות זו מזו. אם אתם חדשים ב-bridging של RouterOS, מדריך הגדרת ה-bridge שלנו מסביר את המודל הבסיסי. בשלב הבא, הוסיפו כלל masquerade כדי שתעבורת המכולות היוצאת תתורגם — את התמונה המלאה תמצאו במדריך הגדרת ה-NAT:

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

פרסו את המכולה הראשונה שלכם

הפנו את ה-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/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 שלנו.

נהלו מכולות על פני צי

מכולה בודדת על נתב יחיד היא קלה. השאלה התפעולית האמיתית עבור ספק אינטרנט היא עקביות: אותו image, אותה סכמת 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/bridge נפרד כדי לבודד מכולות לא מהימנות ממכולות מהימנות.
• הגדירו memory-max על כל דבר שאינכם בוטחים בו לחלוטין כדי לשמור על הנתב מגיב.
• לסביבת בדיקה נקייה לפני נגיעה בייצור, הריצו את אותם images על מופע CHR וירטואלי לפני פריסה לנתבים פיזיים.

עשו את הצעד הבא

מכולות הופכות נתב MikroTik למארח אפליקציות זעיר, אך צי של מארחים כאלה זקוק לתזמור. MKController יוצר תבניות להגדרות RouterOS באופן מרכזי, מחיל אותן על כל התקן במלאי שלכם ועוקב אחר סחיפה כך שתוכלו לראות איזה נתב סטה — ובאמצעות NATCloud הוא מגיע להתקנים מאחורי CGNAT כדי לאשר שמכולה הופעלה מחדש לאחר תחזוקה. זה סוגר את הפער בין הגדרת מכולה אחת ידנית לבין הפעלתן באופן אמין על פני רשת ספק אינטרנט שלמה.

התחילו את גרסת הניסיון החינמית של MKController