MikroTik
RouterOS 7 Containers

Το RouterOS 7 μπορεί να τρέξει containers — πραγματικά OCI images, πάνω στον ίδιο τον router. Pi-hole, ένα WireGuard UI, ένας Prometheus exporter, ένα μικρό web service: στο box που είναι ήδη always-on, αντί για ένα ξεχωριστό Raspberry Pi που πρέπει να τροφοδοτείς και να συντηρείς. Είναι το πιο "μικρό, κοφτερό, composable" feature που έχει βγάλει το MikroTik εδώ και χρόνια, και το documentation είναι λιγοστό. Ορίστε το ειλικρινές build.

MikroTik RouterOS Containers Docker Self-Hosting

Το feature container τρέχει OCI (Docker) images απευθείας πάνω σε RouterOS. Δεν είναι πλήρες Docker Engine — χωρίς compose, χωρίς swarm, ελάχιστο orchestration — αλλά τρέχει ένα μόνο image με interface, environment, και mounts, που καλύπτει εκπληκτικά πολλά: DNS ad-blocking, έναν metrics exporter, ένα management UI, έναν μικρό automation helper. Το επιχείρημα είναι consolidation: ο router είναι ήδη το always-on box σε κάθε site, οπότε ένα ελαφρύ service ανήκει εκεί αντί για μια άλλη συσκευή που πρέπει να τροφοδοτείς, να κάνεις patch, και να ανησυχείς γι' αυτήν.

Τρία πράγματα το κάνουν να μη μοιάζει MikroTik και μπερδεύουν κόσμο: χρειάζεται το πακέτο container και ένα σκόπιμο opt-in device-mode (ένα security gate — το επιβεβαιώνεις φυσικά), χρειάζεται πραγματικό storage για το root του image, και η αρχιτεκτονική του image πρέπει να ταιριάζει με το board (ARM/ARM64/x86). Κάνε αυτά τα τρία σωστά και το υπόλοιπο είναι δικτύωση που ήδη ξέρεις. Ταιριάζει με το fleet management και, φυσικά, το post του Prometheus exporter.

Προαπαιτουμενα

Ένα board ικανό για containers με ελεύθερη RAM/CPU και storage (USB ή εσωτερικός δίσκος)
Φυσική πρόσβαση — η ενεργοποίηση containers απαιτεί επιβεβαίωση device-mode
Ένα image χτισμένο για την αρχιτεκτονική του board σου

Το Security Gate — Package & Device-Mode

Τα containers είναι αρκετά ισχυρά ώστε το MikroTik τα βάζει πίσω από ένα ρητό, φυσικά επιβεβαιωμένο opt-in. Αυτό είναι σκόπιμο: ένα container είναι αυθαίρετος κώδικας πάνω στον router σου.

Terminal — εγκαταστησε το πακετο, ενεργοποιησε το mode (χρειαζεται επιβεβαιωση)

# 1. Εγκατέστησε το ξεχωριστό πακέτο 'container' (κατέβασε το extra
#    package bundle για την έκδοση/αρχιτεκτονική σου, ανέβασέ το, κάνε reboot).
> /system package print       # επιβεβαίωσε ότι το 'container' είναι ενεργό μετά το reboot

# 2. Ενεργοποίησε υποστήριξη container σε device-mode. Αυτό ΔΕΝ θα ισχύσει
#    μέχρι να το επιβεβαιώσεις με power-cycle ή πατώντας το κουμπί reset.
> /system device-mode update container=yes
  ... η ενημέρωση device-mode απαιτεί επιβεβαίωση — κάνε power-cycle το board
      ή πάτα το κουμπί reset/mode μέσα στο χρονικό όριο.

⚠ Παγιδα — Τα Containers Ειναι Αυθαιρετος Κωδικας στον Edge Router σου

Το gate φυσικής επιβεβαίωσης υπάρχει για έναν λόγο: ό,τι τρέχει μέσα στο container τρέχει πάνω στον router σου, με όποια πρόσβαση δικτύου δώσεις στο veth. Μεταχειρίσου τα container images σαν οποιαδήποτε third-party εξάρτηση — κάρφωσε versions, κάνε pull από trusted registries, και δώσε στο container το δικό του απομονωμένο bridge/VLAN με σφιχτό firewall, ποτέ ένα ίσιο bridge πάνω στο LAN σου. Σε ένα edge εκτεθειμένο στο internet, ένα συμβιβασμένο container είναι ένα foothold πίσω από την περίμετρό σου. Αυτή είναι ακριβώς η επιφάνεια που νοιάζονται τα posts hardening και επιθετικό — δύναμη με ευθύνη.

Δικτυωση — ενα veth στο Δικο του Bridge

Ένα container παίρνει ένα interface virtual ethernet (veth). Βάλ' το σε ένα αφιερωμένο bridge με δικό του subnet, masquerade για εξερχόμενη κίνηση, και ελέγχεις ακριβώς τι μπορεί να φτάσει.

Terminal — veth, bridge container, NAT εξοδου

# Το virtual NIC του container, με gateway που δείχνει στο bridge μας.
> /interface veth add name=veth-pihole address=172.19.0.2/24 gateway=172.19.0.1

# Ένα αφιερωμένο bridge για containers — ΟΧΙ το bridge του LAN σου.
> /interface bridge add name=containers
> /interface bridge port add bridge=containers interface=veth-pihole
> /ip address add address=172.19.0.1/24 interface=containers

# Άφησε το container να φτάσει το internet (για να κάνει pull updates κλπ).
> /ip firewall nat add chain=srcnat src-address=172.19.0.0/24 \
    out-interface-list=WAN action=masquerade

Pull, Ρυθμιση, Τρεξιμο

Δείξε το registry, όρισε environment και mounts, πρόσθεσε το container πάνω στο veth, και ξεκίνα το. Το Pi-hole είναι καλός πρώτος στόχος — DNS ad-blocking για ολόκληρο το site, hosted πάνω στον router.

Terminal — ενα container Pi-hole πανω στον router

# Από πού να κάνει pull, και ένα temp dir σε πραγματικό storage για τα layers.
> /container config set registry-url=https://registry-1.docker.io tmpdir=disk1/pull

# Env vars και ένα persistent mount (ώστε το config να επιβιώνει σε rebuild του container).
> /container envs add name=ph-envs key=TZ value="Europe/Athens"
> /container mounts add name=ph-etc src=disk1/pihole/etc dst=/etc/pihole

# Δημιούργησε το container πάνω στο veth, με root στο δίσκο, μετά ξεκίνα το.
> /container add remote-image=pihole/pihole:latest interface=veth-pihole \
    root-dir=disk1/pihole/root envlist=ph-envs mounts=ph-etc \
    logging=yes start-on-boot=yes
> /container print       # status: extracting -> stopped
> /container start [find]  # -> running· δείξε το DNS του LAN στο 172.19.0.2

Persistence, Ορια & ο Ελεγχος Πραγματικοτητας Ασφαλες να Τρεξεις

Τα containers είναι βολικά αλλά τα μικρά boards δεν είναι servers. Γνώρισε τους περιορισμούς πριν χτίσεις ένα site γύρω από ένα.

Περιορισμος	Τι σημαινει στην πραξη
Η αρχιτεκτονική πρέπει να ταιριάζει	ARM image σε ARM board — ένα image x86 δεν θα τρέξει σε RB. Έλεγξε το tag.
Απαιτειται storage	root-dir + layers χρειάζονται πραγματικό δίσκο (USB/NVMe)· τα flash-only boards δεν μπορούν.
Η RAM/CPU είναι μέτρια	Εντάξει για Pi-hole/exporters· όχι για κάτι πεινασμένο. Παρακολούθα το `/system resource`.
Χρησιμοποιησε mounts για state	Ό,τι δεν είναι σε mount χάνεται σε rebuild — κάνε persist το config ρητά.
Χωρις compose/orchestration	Ένα image τη φορά, καλωδιωμένο με το χέρι. Είναι helper, όχι platform.

💡 Που Πραγματικα Λαμπει

Οι killer χρήσεις είναι οι μικροί, always-on helpers που παλιά δικαιολογούσαν ένα ξεχωριστό Raspberry Pi: DNS filtering με Pi-hole, ένας Prometheus/SNMP exporter (δες το post metrics), ένα WireGuard UI για το VPN, ένα webhook/automation shim. Ένα box λιγότερο ανά site για τροφοδοσία, patch, και απώλεια. Ταίριαξε τη φιλοδοξία με το board και είναι ένα πραγματικά κομψό κομμάτι consolidation.

Βασικα Συμπερασματα

Το RouterOS 7 τρέχει images OCI πάνω στον router — ένα ελαφρύ single-container host, όχι πλήρες Docker. Φοβερό για always-on helpers.
Τρία gates: το πακέτο container, ένα φυσικά επιβεβαιωμένο opt-in device-mode, και πραγματικό storage. Και τα τρία απαιτούνται.
Η αρχιτεκτονική του image πρέπει να ταιριάζει με το board — ARM/ARM64/x86. Η πιο κοινή αιτία "δεν ξεκινά".
Δώσε στα containers δικό τους bridge/subnet και σφιχτό firewall — ένα container είναι αυθαίρετος κώδικας πίσω από την περίμετρό σου· ποτέ μην το κάνεις bridge ίσια πάνω στο LAN.
Κάνε persist το state με mounts· οτιδήποτε άλλο χάνεται σε rebuild. Τα μικρά boards έχουν μέτρια RAM/CPU — μέγεθος ανάλογα.
Καλύτερο για Pi-hole, exporters, ένα WireGuard UI — οι helpers που παλιά χρειάζονταν ξεχωριστό Pi. Ένα box λιγότερο ανά site.

Τρεχεις ενα Raspberry Pi σε καθε site μονο για Pi-hole η monitoring;

Πιθανότατα κατέχεις ήδη το hardware για αυτό. Τρέχω DNS filtering, metrics, και VPN UIs σαν containers πάνω στα boxes RouterOS που ήδη έχεις, σωστά απομονωμένα και firewalled — έναν server λιγότερο για να αγοράσεις και να συντηρήσεις.

Κλεισε μια Discovery Call →