So when 7.1rc3 with Docker support came out, i instantly jumped to obvious things to use it to run stand alone DNS server - feature that is missing in RouterOS itself.
But i must admit i strugle to find any usage of this feature on a router, most of the things i would run in container i would run on x64 server, that has much more resources available.
so what would be the thing you will use Docker support for on a router and why?
reverse proxy ( ssl terminaison ) with letsencrypt ( haproxy or traefik )
The list of services that might be run in containers is endless. Just compile list of services that people mentioned in numerous wish-list posts.
The problem is that most (if not all) RB devices are not really fit for running (full-blown) containers either due to RAM shortage or due to storage shortage (or both) and that inclusion of those services in ROS itself would make better use of scarce resources. Specially so as containers run on router don’t really get the integration some people would like to see (e.g. using same L2/L3 interfaces as core ROS does) …
As already mentioned it would make much greater sense that people would be running a general-purpose gadget (can be a humble rPI or a decent server) running all the wanted services … either natively (e.g. in bare-metal linux OS) or in containers. But some people outright reject such solution (it’s beyond my comprehension as to why), wanting to reduce number of gadgets run in their network at all costs.
Agree with mkx.
Most RouterBoards are not suited for this purpose because of RAM, storage (some boards don’t even allow external storage), processing power.
Which does not mean it can not be done.
But it’s not because something can be done, it might not be better done using something else.
Looking at it from another angle:
if all you have is a hammer, you tend to see every problem as a nail.
Routerboards CAN be used as Docker environments, yes.
But a lot of other (and even cheaper) devices are far more better equipped to serve this purpose.
Even a lot of existing NAS devices can nowadays be used for this goal so it’s not that you HAVE to add another gadget in the mix (which on itself still should not be a problem).
I don’t think the Docker-Feature will be widely used in the “Entreprise” enviroment.
In other words, no Entreprise with On-Site virtualization capability, will move there DNS-Server to a Mikrotik-Device!
It just doesn’t make any sense =)
having said that,
I use Mikrotik-Devices all the time to solve problem no other Router can !
So the Docker-Feature is a welcome Tool for my Toolbox 
Possible use cases…
Replace All-in-One Router
I find it difficult sometimes to implement a Mikrotik-Routers in a SOHO or SME’s environment.
There is always a small Feature or Service from the All-in-One Router that Mikrotik can’t provide.
Dockers may help to solve this problem.
Raspberry Pi replacement
I know a lot of IT-Enthusiast wo use RPi’s at home as some sort of low performance Server.
like ioT-Server, Web-Server, Data and Logging, Authentication (freeradius) , DNS (pihole) etc…
I for exemple need at home very small MariaDB-Server for a software I use (Devolutions RDM).
My handfull of devices usually make each 1 SQL-Request a day . Since i don’t have a Server or NAS,
Installing Dockers on my Router could be a very nice solution.
ISP could have a small Web-Server installed on Client devices.
Client could access the Website to
+1
I’d like to add mqtt-broker/mosquitto and unbound to the list
Big one for us is a light weight Zabbix proxy for remote sites without needing to add another device onsite
We also use a tik for our Out of Band devices, and being able to spin up a basic linux docker could be useful to run extra troubleshooting software onsite (eg. could have a container with nmap etc)
Another use case would be running something like netinstall in a container, running a container on each port of router/switch, allowing for quick bulk netinstall operations etc
Its a shame they cheaped out on the storage for things like the RB5009, surely 1GB of storage wouldn’t add too much to the BOM, or they could add an “extra storage” model
small voip pbx
Hi!
I will only need a single container with Openwrt. That gives all the possibilites and not much overhead,
via a huge repository of (mostly) lightweight packages: PBX, proxy, DNS (Bind, unbound, blacklisting…) ,many kinds onf VPNs and a lot more.
OpenWRT is geared towards home routers, so it comes with much less overhead as a Debian or Alpine container would come with.
Btw. it has a nice and more lightweight solution instead of PiHole. PiHole is better run on a Raspi as that needs a lot of RAM & CPU.
Regards
W
I’d like to spawn a container to push DNS updates to route53.
+1 for OpenWRT minimal container. It’s very lightweight and there is already package manager and other good features available for all architectures ROS runs on.
Also maybe make minimal containers with just busybox for different architectures. Something that can be easily used for doing scripting or port mapping jobs that ROS can’t, with little impact on memory/flash.
This is what I am planning on using container support for.
With an Openwrt install, you could choose from: Asterisk, Fresswitch, Kamaillo, Siproxd, Yate and a few more… (I hope they all are available on Arm64)
W
Ubiquiti controller
Enlighten me please…
Why would one run Openwrt in Docker on Routeros when it can be run natively on lots of Tik HW ??
Natively performance should be better ?
No plans myself, just wondering why.
Best of both worlds… Can winbox talk to, and be used to configure OpenWrt ? 
Webbrowser access ?
While I do agree that Docker is of limited use on RouterOS, there are broad cases where it’ll be worth putting up with the many problems you buy in using the feature:
Many of the problems on the list in my article linked above can be solved by switching from piggy services written in scripting languages, with many external dependencies to single statically-linked binaries. Since a lot of the cloud is moving toward such things already (e.g. microservices, serverless architectures, etc.) I think we’ll find alternatives to a lot of the worst offenders, ones that will fit within the current stringent limits.
I expect MikroTik to start shipping devices with these limitations removed, but even after they do, we’ll still benefit from compact, efficient containers, if only so we can run more of them on a single box.
You keep talking about some limitations but even in your blogpost and in here you didn’t mention ONE limitation that MikroTik should remove(?).