I’m seeing a few unhappy comments about this, so I’ll just point out a couple of things:
1. This was introduced in a beta. It was then removed from subsequent betas until a fix could be found.
2. Running docker on a router could be really helpful in some cases, especially for small ISPs such as mine. For example: being able to run a recursive DNS resolver at the broadcast tower (ie nearer the customer) without having to run an entire server would be great. Or running a Prometheus exporter on the router for metric collection. Or for local processing/archiving of netflow data.
There are some really helpful use cases for this, but they are not the normal devops reasons for using docker.
Support, as well as detailed, rigorous documentation in a technical writing style, are definitely lacking with Mikrotik products. There is a lot of assumed knowledge in the process of specifying and then purchasing from them. However the price, support and feature set are not too bad if you're able to determine ahead of time that it would all be suitable for your environment.
I did get very technical support in the forums, down to the level of tracking latencies and detailed package inspection. But that was way too low-level and over my head for something that worked out of the box on several previous OpenWRT installs on much weaker hardware.
I like the idea of Mikrotik and understand that they are pretty powerful for the price, but as you said, they require a certain level of experience and knowledge to wrangle them to the users liking.
Edge equipment should not be multi-purpose, "maximizing hardware" or not.
This pursuit of saving money has given us weak boundaries that are relatively easy to cross, which will ultimately cost substantially more given any successful attack. The risk of an attack is an existential threat to the business itself. Do you really want to risk your entire business because you are trying to save a few hundred for a separate device?
There are places to try to save money and consolidate workloads, but edge routers are not it.
I was initially inclined to agree, especially since openwrt can run docker too, but I think it's fair to question both defaults and supported modes of operation, and how much work it is to go from the default to the desired target state. If out of the box openwrt has less attack surface and you have to go out of your way to add those features, that's probably better than a jack-of-all-trades that comes out of the box with loads of attack surface that you have to pare down and hope that removing the features you don't want is possible/supported.
RouterOS by default doesn't have container support. It's a separate package which has to be installed on the system. And it is still in testing / beta phase.
Oh boy, glad I moved mine to SwitchOS I guess. This being a beta means I would've ended up with this eventually, and Docker is just not something I want on a network device
Seriously considering replacing this with Mikrotik showing up so often
Edit: Any recommendations for 10GbE switches with ~8 ports would be appreciated, likely encouraging me to follow through
1. This was introduced in a beta. It was then removed from subsequent betas until a fix could be found.
2. Running docker on a router could be really helpful in some cases, especially for small ISPs such as mine. For example: being able to run a recursive DNS resolver at the broadcast tower (ie nearer the customer) without having to run an entire server would be great. Or running a Prometheus exporter on the router for metric collection. Or for local processing/archiving of netflow data.
There are some really helpful use cases for this, but they are not the normal devops reasons for using docker.