کانتینر در MikroTik چیست و چه کاربردی دارد؟

Container در MikroTik قابلیتی در RouterOS است که اجازه می‌دهد برخی محیط‌ها و سرویس‌های لینوکسی را مستقیماً در کنار سیستم‌عامل روتر اجرا کنیم.

به زبان ساده، روتر دیگر فقط وظایفی مانند Routing، Firewall، NAT، VPN و مدیریت پهنای باند انجام نمی‌دهد؛ بلکه در سخت‌افزارهای سازگار می‌تواند میزبان سرویس‌هایی مانند DNS Filtering، MQTT Broker، Home Automation، Reverse Proxy، RADIUS Server یا ابزارهای مانیتورینگ نیز باشد.

برای مثال می‌توان Pi-hole را داخل یک Container اجرا کرد تا درخواست‌های DNS کاربران شبکه فیلتر شوند، یا Mosquitto را به‌عنوان MQTT Broker برای تجهیزات IoT اجرا کرد.

اما یک نکته بسیار مهم وجود دارد:

قابلیت Container به این معنا نیست که هر روتر MikroTik را باید به یک Server تبدیل کنیم.

پردازنده، RAM، فضای ذخیره‌سازی، معماری CPU، نوع Storage و حساسیت سرویس باید پیش از اجرای Container بررسی شوند.

Container چیست؟

Container یک محیط ایزوله برای اجرای Application و وابستگی‌های آن است. برخلاف ماشین مجازی که معمولاً سیستم‌عامل و Kernel مستقل خود را دارد، Containerها از Kernel میزبان استفاده می‌کنند و به همین دلیل معمولاً سبک‌تر هستند.

یک Container می‌تواند شامل موارد زیر باشد:

• Application اصلی
• Libraryهای موردنیاز
• فایل‌های Configuration
• Environment Variableها
• Filesystem موردنیاز برنامه

این ساختار باعث می‌شود Application همراه با وابستگی‌های خودش بسته‌بندی شود و نیاز نباشد تعداد زیادی Package مستقیماً روی سیستم‌عامل میزبان نصب شوند.

Container در RouterOS چگونه کار می‌کند؟

RouterOS دارای پیاده‌سازی مخصوص خود برای Linux Containerها است.

مدیریت Containerها از مسیر زیر انجام می‌شود:

/container

هر Container معمولاً به چند جزء اصلی نیاز دارد:

• Container Image
• Root Directory
• Virtual Ethernet Interface یا VETH
• Environment Variableها
• Mountها یا Volumeهای دائمی
• Storage
• Firewall و Routing مناسب

ساختار مفهومی را می‌توان به‌شکل زیر نمایش داد:

Internet
 |
RouterOS
 |
Firewall / NAT / Routing
 |
Container Bridge
 |
 +--------------------+
 | |
 veth1 veth2
 | |
 Pi-hole MQTT Broker
Container Container

در این معماری، RouterOS همچنان کنترل اصلی Routing، Firewall و Network Interfaceها را در اختیار دارد و Containerها از طریق Interfaceهای مجازی به شبکه متصل می‌شوند.

آیا Container در MikroTik همان Docker است؟

خیر.

عبارت «Docker روی MikroTik» در مکالمات فنی رایج است، اما از نظر دقیق RouterOS یک Docker Host استاندارد با Docker Engine و دستور docker نیست.

در MikroTik مدیریت Container با دستورات RouterOS انجام می‌شود:

/container
/container/config
/container/envs
/container/mounts

در مقابل روی Linux دارای Docker معمولاً دستورهایی مانند موارد زیر استفاده می‌شوند:

docker pull
docker run
docker ps
docker stop

بااین‌حال RouterOS می‌تواند از Container Imageهای سازگار با Registryهای متداول استفاده کند و Image را مستقیماً دریافت یا از فایل Archive وارد کند.

تفاوت Container و ماشین مجازی چیست؟

برای آشنایی عمیق‌تر با VM و Hypervisor، مقاله مجازی‌سازی سخت‌افزاری چیست؟ را مطالعه کنید.

پیش‌نیازهای Container در MikroTik

پیش از اجرای Container باید چند شرط مهم بررسی شوند.

۱. RouterOS v7

قابلیت Container بخشی از RouterOS v7 است و بهتر است دستگاه روی نسخه Stable و پشتیبانی‌شده RouterOS قرار داشته باشد.

۲. نصب Container Package

ابتدا Packageهای نصب‌شده را بررسی کنید:

/system/package/print

در فهرست باید Package مربوط به Container وجود داشته باشد.

۳. فعال‌سازی Container در Device Mode

قابلیت Container به‌دلایل امنیتی به‌صورت پیش‌فرض فعال نیست.

برای فعال‌سازی:

/system/device-mode/update container=yes

RouterOS برای تأیید این تغییر درخواست دسترسی فیزیکی به دستگاه می‌کند. بسته به مدل باید Reset/Mode Button را در زمان مشخص فشار دهید یا فرآیند تأیید فیزیکی موردنیاز دستگاه را انجام دهید.

۴. منابع سخت‌افزاری کافی

قبل از انتخاب Container موارد زیر را بررسی کنید:

• معماری CPU
• تعداد Core
• RAM آزاد
• فضای Storage
• سرعت Storage
• Load فعلی RouterOS

معماری CPU و Container Image

Container Image باید با معماری سخت‌افزار MikroTik سازگار باشد.

معماری‌های رایج عبارت‌اند از:

• ARM
• ARM64
• x86 / AMD64
• CHR روی معماری x86-64

معماری دستگاه را با دستور زیر بررسی کنید:

/system/resource/print

برای مثال یک Image که فقط برای linux/amd64 ساخته شده است روی دستگاه ARM64 به‌صورت Native اجرا نمی‌شود.

هنگام انتخاب Image از Registry باید بخش Supported Architectures همان Image بررسی شود.

برای انتخاب سخت‌افزار متناسب با Workload، مقاله با ۵ سؤال روتر مناسب خود را پیدا کنید را مطالعه کنید.

چرا Storage برای Container اهمیت زیادی دارد؟

بسیاری از روترهای MikroTik برای نگهداری RouterOS و Configuration طراحی شده‌اند، نه برای ذخیره Imageهای چندصد مگابایتی، Database یا Logهای Application.

به همین دلیل در دستگاه‌های دارای USB یا Storage مناسب بهتر است Root Directory، Temporary Extraction Directory و Volumeهای Container روی Storage خارجی قرار گیرند.

برای مثال:

/container/config/set \
 registry-url=https://registry-1.docker.io \
 tmpdir=disk1/container-tmp

و Root Directory:

root-dir=disk1/containers/pihole

چرا Storage داخلی مناسب نیست؟

• ظرفیت محدود دارد.
• Image Extraction فضای زیادی مصرف می‌کند.
• Application ممکن است Log یا Database تولید کند.
• نوشتن مداوم می‌تواند برای Flash داخلی مناسب نباشد.
• Update Image فضای موقت بیشتری نیاز دارد.

برای Containerهایی با Write زیاد، SSD یا Storage مناسب از یک Flash USB بسیار ضعیف انتخاب بهتری است.

VETH در Container MikroTik چیست؟

Container برای ارتباط با شبکه به یک Virtual Ethernet Interface یا VETH نیاز دارد.

VETH را می‌توان مشابه کارت شبکه مجازی Container در نظر گرفت.

نمونه:

/interface/veth/add \
 name=veth-pihole \
 address=172.17.0.2/24 \
 gateway=172.17.0.1

سپس یک Bridge برای شبکه Container ایجاد می‌کنیم:

/interface/bridge/add name=bridge-containers

/ip/address/add \
 address=172.17.0.1/24 \
 interface=bridge-containers

/interface/bridge/port/add \
 bridge=bridge-containers \
 interface=veth-pihole

در این حالت:

• RouterOS برابر 172.17.0.1 است.
• Container برابر 172.17.0.2 است.
• RouterOS می‌تواند Firewall و Routing بین Container و سایر شبکه‌ها را کنترل کند.

دسترسی Container به اینترنت

در صورت نیاز می‌توان برای Subnet Container NAT ایجاد کرد:

/ip/firewall/nat/add \
 chain=srcnat \
 action=masquerade \
 src-address=172.17.0.0/24 \
 out-interface-list=WAN

آیا Container را مستقیماً داخل LAN قرار دهیم؟

در بیشتر سناریوها بهتر است Container Network از LAN کاربران جدا باشد تا Firewall بتواند دسترسی آن را کنترل کند.

برای مثال:

Users VLAN
 |
Firewall
 |
Container VLAN / Bridge
 |
Pi-hole / MQTT / App

این معماری نسبت به قراردادن تمام Containerها در Broadcast Domain کاربران کنترل امنیتی بیشتری ایجاد می‌کند.

Container در MikroTik چه کاربردهایی دارد؟

۱. Pi-hole؛ DNS Filtering و مسدودسازی تبلیغات

یکی از محبوب‌ترین کاربردها اجرای Pi-hole است.

Pi-hole می‌تواند به‌عنوان DNS Server شبکه عمل کرده و Domainهای تبلیغاتی، Trackerها یا فهرست‌های تعریف‌شده توسط مدیر شبکه را فیلتر کند.

ساختار:

Clients
 |
MikroTik DHCP
 |
Pi-hole Container
 |
Upstream DNS

۲. MQTT Broker برای IoT

می‌توان Containerهایی مانند Mosquitto را برای راه‌اندازی MQTT Broker اجرا کرد.

این سناریو برای موارد زیر مناسب است:

• Sensorها
• سیستم‌های Home Automation
• Industrial IoT سبک
• ارسال اطلاعات Monitoring
• Automation داخلی

۳. Home Assistant

روی سخت‌افزار دارای RAM و Storage مناسب می‌توان Home Assistant را در Container اجرا کرد.

این سرویس برای مدیریت تجهیزات Smart Home، Sensorها، Automationها و دستگاه‌های IoT کاربرد دارد.

۴. FreeRADIUS

در معماری مناسب می‌توان RADIUS Server را نیز در Container اجرا کرد و از آن برای Authentication سرویس‌هایی مانند موارد زیر استفاده نمود:

• Hotspot
• PPP
• PPPoE
• سرویس‌های احراز هویت شبکه

برای شبکه Production باید Database، Backup، Availability و امنیت RADIUS به‌صورت مستقل بررسی شوند.

۵. HAProxy یا Reverse Proxy

یک Container می‌تواند HAProxy یا Reverse Proxy سبک اجرا کند.

کاربردهای آن عبارت‌اند از:

• Reverse Proxy برای Web Application داخلی
• Load Balancing ساده
• هدایت درخواست‌های HTTP و HTTPS
• متمرکزکردن ورودی چند سرویس

۶. ابزارهای Monitoring سبک

برخی Agentها، Collectorها یا Dashboardهای سبک را می‌توان در Container اجرا کرد.

اما Applicationهایی با Database بزرگ، Retention طولانی یا حجم زیاد Metric بهتر است روی Server یا VM جداگانه اجرا شوند.

۷. Application یا API سفارشی

اگر تیم IT یک Application کوچک با Python، Go، Node.js یا فناوری مشابه نوشته باشد، در صورت وجود Image سازگار می‌توان آن را داخل Container اجرا کرد.

برای نمونه:

• Webhook داخلی
• API ساده
• Automation Gateway
• تبدیل داده بین سرویس‌ها
• Service کوچک برای تجهیزات IoT

نمونه معماری Pi-hole روی MikroTik

فرض کنیم:

• شبکه Container: 172.17.0.0/24
• Gateway: 172.17.0.1
• Pi-hole: 172.17.0.2
• Storage خارجی: disk1

مرحله اول: فعال‌سازی Container Mode

/system/device-mode/update container=yes

سپس تأیید فیزیکی موردنیاز RouterOS انجام می‌شود.

مرحله دوم: ایجاد VETH

/interface/veth/add \
 name=veth-pihole \
 address=172.17.0.2/24 \
 gateway=172.17.0.1

مرحله سوم: ایجاد Bridge

/interface/bridge/add name=bridge-containers

/ip/address/add \
 address=172.17.0.1/24 \
 interface=bridge-containers

/interface/bridge/port/add \
 bridge=bridge-containers \
 interface=veth-pihole

مرحله چهارم: NAT

/ip/firewall/nat/add \
 chain=srcnat \
 action=masquerade \
 src-address=172.17.0.0/24 \
 out-interface-list=WAN

مرحله پنجم: تعریف Registry و Temporary Directory

/container/config/set \
 registry-url=https://registry-1.docker.io \
 tmpdir=disk1/container-tmp

مرحله ششم: ایجاد Container

Environment Variableها و Mountهای دقیق Pi-hole باید براساس نسخه Image مورد استفاده تنظیم شوند.

ساختار کلی دستور به شکل زیر است:

/container/add \
 remote-image=pihole/pihole \
 interface=veth-pihole \
 root-dir=disk1/containers/pihole \
 logging=yes \
 name=pihole

بررسی وضعیت

/container/print

بعد از پایان Download و Extraction می‌توان Container را Start کرد:

/container/start pihole

Mount و Volume چه کاربردی دارند؟

اگر اطلاعات مهم فقط در Filesystem داخلی Container ذخیره شوند، حذف یا بازسازی Container ممکن است آن داده‌ها را از بین ببرد.

Mount اجازه می‌دهد یک Directory موجود روی Storage RouterOS به Directory مشخصی داخل Container متصل شود.

مثال مفهومی:

RouterOS:
disk1/pihole-config

 ↓ Mount

Container:
/etc/pihole

این روش برای موارد زیر مهم است:

• Configuration
• Database
• Certificate
• Log
• Persistent Data

Environment Variable چیست؟

بسیاری از Container Imageها تنظیمات خود را از Environment Variable دریافت می‌کنند.

برای نمونه:

/container/envs/add \
 list=APP_ENV \
 key=TZ \
 value=Asia/Tehran

یا Application ممکن است Username، Port، Database Name یا سایر پارامترها را از Environment Variable دریافت کند.

امنیت Container در MikroTik؛ مهم‌تر از نصب آن

Container قابلیت قدرتمندی است، اما سطح حمله دستگاه را نیز افزایش می‌دهد.

Router در مرز شبکه قرار دارد و معمولاً به اینترنت، VLANهای داخلی، VPNها و بخش‌های حساس دسترسی دارد. اجرای یک Image ناشناس روی چنین دستگاهی باید با حساسیت بیشتری نسبت به یک کامپیوتر آزمایشگاهی انجام شود.

۱. Image را از منبع معتبر دریافت کنید

از Imageهای ناشناس، قدیمی یا بدون Maintainer مشخص برای سرویس Production استفاده نکنید.

۲. Version را Pin کنید

استفاده دائمی از Tagهایی مانند latest می‌تواند رفتار Update را غیرقابل پیش‌بینی کند.

در محیط Production بهتر است Version مورد آزمایش مشخص باشد.

۳. شبکه Container را جدا کنید

Container را بدون نیاز به Management VLAN یا تمام Server VLANها متصل نکنید.

Firewall باید مشخص کند:

• چه Clientهایی به Container دسترسی دارند.
• Container به چه Serverهایی دسترسی دارد.
• چه Portهایی مجاز هستند.
• آیا Container اجازه Internet Access دارد.

۴. Portهای Container را بی‌دلیل روی اینترنت Publish نکنید

قبل از هر DST-NAT بپرسید آیا سرویس واقعاً باید Public باشد.

برای Web Applicationهای عمومی، استفاده از Reverse Proxy، TLS و Policy امنیتی مناسب را بررسی کنید.

۵. Container را با دسترسی بیش از حد اجرا نکنید

اگر Image امکان اجرا با User محدود را دارد، از اجرای بی‌دلیل Process با سطح دسترسی بالا خودداری کنید.

۶. RouterOS را به‌روز نگه دارید

Container Security از امنیت Host جدا نیست. RouterOS، Firmware و Imageهای Container باید در برنامه Patch Management قرار داشته باشند.

برای Hardening کامل‌تر، مقاله امنیت در MikroTik از کجا شروع می‌شود؟ را مطالعه کنید.

Container چه تأثیری روی CPU و RAM روتر دارد؟

Container از همان CPU و RAMی استفاده می‌کند که RouterOS برای Routing، Firewall، VPN، Queue و سایر وظایف شبکه استفاده می‌کند.

در نتیجه اگر Application منابع زیادی مصرف کند، Performance وظیفه اصلی روتر نیز می‌تواند تحت تأثیر قرار گیرد.

منابع را با دستورات زیر بررسی کنید:

/system/resource/print
/tool/profile
/container/print

قبل از اجرا این سؤال‌ها را پاسخ دهید

• در Peak شبکه CPU روتر چند درصد است؟
• چقدر RAM آزاد داریم؟
• Container در حالت Idle چقدر RAM مصرف می‌کند؟
• در زمان Load چه مقدار CPU لازم دارد؟
• آیا Application Database دارد؟
• Storage آن چقدر IOPS نیاز دارد؟
• اگر Container Crash کند، شبکه اصلی چه تأثیری می‌گیرد؟

چه زمانی نباید Container را روی MikroTik اجرا کنیم؟

Container قابلیت جذابی است، اما در همه پروژه‌ها انتخاب مناسبی نیست.

در موارد زیر بهتر است Server، VM، Mini PC یا VPS جداگانه بررسی شود:

• Database سنگین
• مصرف RAM بالا
• CPU Intensive Workload
• Storage Write زیاد
• Application حیاتی سازمان
• نیاز به High Availability
• نیاز به Backup پیچیده
• تعداد زیاد Container
• نیاز به Docker Compose یا Orchestration پیچیده
• Prometheus یا Logging با Retention بالا
• Application دارای تعداد زیاد User

اجرای سرویس روی Router یا Server جداگانه؟

Backup در Container چگونه باید طراحی شود؟

Backup خود RouterOS برای محافظت از Database و Volumeهای Application کافی نیست.

سه بخش را جداگانه در نظر بگیرید:

1. RouterOS Configuration
2. Container Definition
3. Persistent Application Data

برای Applicationهایی مانند Pi-hole، Home Assistant یا RADIUS باید Directoryهای Mount شده نیز Backup شوند.

همچنین بهتر است Backup فقط روی همان USB یا SSD متصل به روتر باقی نماند.

چک‌لیست پیش از فعال‌کردن Container در MikroTik

1. مدل روتر و معماری CPU مشخص شده است.
2. Container Image معماری سازگار دارد.
3. RouterOS به نسخه Stable مناسب ارتقا یافته است.
4. Container Package نصب شده است.
5. CPU Load فعلی اندازه‌گیری شده است.
6. RAM آزاد کافی وجود دارد.
7. Storage خارجی مناسب در دسترس است.
8. Backup RouterOS تهیه شده است.
9. Container Network مستقل طراحی شده است.
10. VETH و IP Plan مشخص هستند.
11. Firewall بین Container و LAN طراحی شده است.
12. دسترسی اینترنت Container فقط در صورت نیاز مجاز است.
13. Portهای Container بدون نیاز روی WAN منتشر نشده‌اند.
14. Image از Registry معتبر دریافت می‌شود.
15. Version Image مشخص و مستند است.
16. Persistent Volumeها روی Storage مناسب قرار دارند.
17. روش Backup داده Application مشخص است.
18. Monitoring CPU، RAM و Storage طراحی شده است.
19. در صورت خرابی Container، سرویس اصلی شبکه وابسته به آن نیست یا Plan جایگزین وجود دارد.

انتخاب سخت‌افزار مناسب Container با گروه بیستون

امکان اجرای Container در RouterOS به‌تنهایی دلیل کافی برای انتخاب یک مدل نیست. نوع پردازنده، معماری ARM یا ARM64، مقدار RAM، وجود USB، ظرفیت Storage و بار اصلی Routing باید هم‌زمان بررسی شوند.

برای مثال روتر ممکن است از نظر نرم‌افزاری Container را پشتیبانی کند، اما اگر بیشتر CPU آن صرف VPN، Firewall، Queue و Routing شود، اضافه‌کردن Application لینوکسی تصمیم مناسبی نخواهد بود.

گروه فناوری ارتباطات پندار بیستون امکان بررسی تجهیزات MikroTik و انتخاب مدل متناسب با سناریوی شبکه را فراهم می‌کند.

برای نیازسنجی دقیق‌تر اطلاعات زیر را آماده کنید:

• Container موردنظر
• معماری Image
• RAM موردنیاز Application
• حجم Storage
• میزان Write روی Storage
• تعداد کاربران
• سرعت اینترنت
• تعداد VPNها
• Firewall و Queueهای فعال
• تعداد Containerهای موردنظر

سؤالات متداول درباره Container در MikroTik

آیا MikroTik از Docker پشتیبانی می‌کند؟

RouterOS دارای پیاده‌سازی Linux Container با مدیریت اختصاصی خود است و می‌تواند Container Imageهای سازگار را اجرا کند. این قابلیت با نصب Docker Engine و استفاده مستقیم از Docker CLI یکسان نیست.

آیا همه روترهای MikroTik از Container پشتیبانی می‌کنند؟

خیر. معماری سخت‌افزار، Packageهای RouterOS و منابع دستگاه باید بررسی شوند. علاوه بر پشتیبانی نرم‌افزاری، CPU، RAM و Storage نیز باید برای Application موردنظر کافی باشند.

چگونه بفهمیم معماری MikroTik چیست؟

از دستور /system/resource/print استفاده کنید و مقدار Architecture را بررسی نمایید.

آیا برای Container به USB نیاز داریم؟

الزاماً در تمام سناریوها خیر، اما برای Image، Root Directory و Persistent Volumeها استفاده از Storage خارجی مناسب قویاً توصیه می‌شود.

آیا می‌توان Pi-hole را روی MikroTik اجرا کرد؟

بله، روی دستگاه سازگار و دارای منابع کافی می‌توان Pi-hole را داخل Container اجرا و از آن به‌عنوان DNS Filtering Server استفاده کرد.

آیا Home Assistant روی MikroTik اجرا می‌شود؟

روی معماری و سخت‌افزار مناسب قابل اجرا است، اما مصرف RAM و Storage آن باید بررسی شود. برای Installationهای بزرگ‌تر Server یا Mini PC ممکن است انتخاب مناسب‌تری باشد.

VETH چیست؟

VETH کارت شبکه مجازی Container است که آن را به Bridge، VLAN یا شبکه موردنظر RouterOS متصل می‌کند.

آیا هر Container Image موجود در Docker Hub روی MikroTik اجرا می‌شود؟

خیر. Image باید برای معماری CPU دستگاه ساخته شده باشد و نیازهای Kernel، RAM، Storage و Hardware آن با محیط RouterOS سازگار باشند.

آیا می‌توان چند Container را هم‌زمان اجرا کرد؟

در صورت وجود منابع کافی بله. محدودیت عملی را CPU، RAM، Storage و نوع Workload تعیین می‌کنند.

آیا Container می‌تواند به VLANهای شبکه دسترسی داشته باشد؟

بله، اما Routing و Firewall باید دسترسی آن را کنترل کنند. بهتر است Containerها بدون نیاز به تمام VLANهای سازمان دسترسی نداشته باشند.

آیا Container در MikroTik امن است؟

امنیت آن به RouterOS، Image مورد استفاده، Firewall، نحوه انتشار Portها و مدیریت دسترسی‌ها وابسته است. اجرای Image شخص ثالث می‌تواند Attack Surface روتر را افزایش دهد.

آیا Container جایگزین VM است؟

خیر. Container برای Applicationهای بسته‌بندی‌شده و سبک مناسب است، درحالی‌که VM سیستم‌عامل کامل و سطح جداسازی متفاوتی ارائه می‌دهد.

آیا Container جایگزین Server است؟

برای بعضی سرویس‌های سبک می‌تواند نیاز به یک دستگاه جداگانه را کاهش دهد، اما برای Database، Application حیاتی، High Availability یا Workload سنگین معمولاً Server یا VM مناسب‌تر است.

آیا CHR می‌تواند Container اجرا کند؟

Container Package برای CHR نیز ارائه می‌شود. منابع VM میزبان و معماری Image باید با سناریوی موردنظر هماهنگ باشند.

چرا Container Mode به تأیید فیزیکی نیاز دارد؟

این محدودیت امنیتی باعث می‌شود مهاجمی که فقط دسترسی Remote به RouterOS به دست آورده است نتواند بدون دخالت فیزیکی مدیر، قابلیت Container را به‌سادگی فعال کند.

جمع‌بندی؛ آیا Container در MikroTik ارزش استفاده دارد؟

Container در MikroTik یکی از قابلیت‌های جذاب RouterOS v7 است که مرز میان یک Network Appliance سنتی و یک Edge Computing Platform کوچک را کمرنگ‌تر می‌کند.

با استفاده صحیح از این قابلیت می‌توان سرویس‌هایی مانند Pi-hole، MQTT Broker، Home Assistant، FreeRADIUS، Reverse Proxy و Applicationهای سفارشی سبک را مستقیماً روی سخت‌افزار سازگار MikroTik اجرا کرد.

مزیت اصلی این معماری کاهش تعداد دستگاه‌های کوچک شبکه و قرارگرفتن Application در نزدیکی Routing و Firewall است.

اما همین نزدیکی یک ریسک نیز ایجاد می‌کند: Application از همان CPU، RAM، Storage و Hostی استفاده می‌کند که وظیفه اصلی آن حفظ ارتباط شبکه است.

بنابراین قبل از اجرای Container باید چهار موضوع بررسی شوند:

1. سازگاری: آیا Image برای معماری CPU دستگاه ساخته شده است؟
2. ظرفیت: آیا CPU، RAM و Storage کافی داریم؟
3. امنیت: آیا Image، Firewall و دسترسی‌ها قابل اعتماد هستند؟
4. اهمیت سرویس: آیا واقعاً منطقی است این Application روی Router اجرا شود؟

اگر پاسخ این چهار سؤال مثبت باشد، Container می‌تواند قابلیت بسیار مفیدی برای Edge Serviceها، Home Lab، SMB و شبکه‌های تخصصی باشد.

اما اگر Application حجیم، حیاتی یا دارای Database سنگین است، بهتر است RouterOS کار اصلی خود یعنی Routing، Firewall و Networking را انجام دهد و Workload نرم‌افزاری روی Server، VM یا زیرساخت اختصاصی اجرا شود.