Looking for Docker container ideas for RouterOS

[strex]

Using it to install bird2 and replacing the not great mikrotik ospf and bgp daemon.

[Wolfraider]

SBC for VOIP. I posted the idea on the 3CX forums and my post was instantly deleted

[gotsprings]

MPTCPRouter?

Or something similar that let us use Multiple ISPs and Bond as a VPS elsewhere!

[jbl42]

https://hub.docker.com/r/andrius/asterisk
should run on RB5009/RB4011 and similar arm/arm64 MT devices, but did not try it yet.

[cfikes]

https://hub.docker.com/r/andrius/asterisk
should run on RB5009/RB4011 and similar arm/arm64 MT devices, but did not try it yet.

I’ll have to give this one a shot. Could not get the 3CX images started on here. I should probably just build a new FusionPBX image.

[cklee234]

I am able to build my debian based asterisk and migrate the existing SIP setting to the docker. It works without issues.

[cfikes]

I am able to build my debian based asterisk and migrate the existing SIP setting to the docker. It works without issues.

Thats awesome!

[theosoft]

A public PBX docker release with howto would be fine . Is there a GUI included? upss

[foureight84]

+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.

Interesting. I was looking into documentation and I didn’t see how one would do port mapping with Containers in ROS 7.

[tangent]

I was looking into documentation and I didn’t see how one would do port mapping with Containers in ROS 7.

How did you miss this? It’s precisely the same thing as “docker create --publish 80:80”.

[kraal]

Hi,

I’m reading this and other similar threads for some times now about using containers on mikrotik devices and, sorry to say that, I still don’t get why this would be a good idea nor can find what I would name “a valid use case” for having containers deployed on a mikrotik device.

Most arguments that I read are “something is missing/not good enough on the mikrotik device and I want to add/replace it”. It’s like willing to stockpile old plastic in your living room because your cellar is to small, and doing it because your living room is big enough… Fine, but it both sounds like a pad on a wooden leg to me and may not be worth potential involved risks. The cost argument is not valid either as cheap and power efficient devices can be found on the market.

So can you please enlighten me ? Why are people that enthusiastic about what sound like a gadget to me and which probably lowers Mikrotik bandwidth for fixing real issues (bgp for instance, pim-sm) and adding core features which are in my opinion really missing and cannot (not to say shouldn’t) be handled through containers anyway (nut for instance).

Apart from the “it would be cool to be able to”, I really see no “mindbreaking” argument so far.

Thanks in advance.

[tangent]

Most arguments that I read are “something is missing/not good enough on the mikrotik device and I want to add/replace it”.

What’s wrong with that argument? It’s a perfectly valid use case.

The cost argument is not valid either as cheap and power efficient devices can be found on the market.

Some of us have RouterOS devices with enough free RAM, flash, and CPU to do this for “free.” Buying another device to run the container is not free.

If you do not possess a device yet that will do this in a sensible fashion, there’s a fair chance your next RouterOS device will. What will you do with your spare slice of free compute power?

Even when cost is no object, the ability to deliver a complete, integrated, custom solution may be compelling.

lowers Mikrotik bandwidth for fixing real issues (bgp for instance, pim-sm)

Development talent isn’t fungible. The people working on containers likely weren’t pulled off your pet projects, nor could they be reassigned to them and be immediately productive.

Furthermore, most of this container stuff is out there, off the shelf, ready to repurpose. A good bit of it lives in the kernel they had to update to produce v7 already. Initial development on what would become the modern container infrastructure goes back to kernel 3.10.

I really see no “mindbreaking” argument so far.

Perhaps it is not for you, then.

That doesn’t mean it isn’t for anyone else, though.

[pe1chl]

Some of us have RouterOS devices with enough free RAM, flash, and CPU to do this for “free.” Buying another device to run the container is not free.

If you do not possess a device yet that will do this in a sensible fashion, there’s a fair chance your next RouterOS device will. What will you do with your spare slice of free compute power?

It is a bit sad that RouterOS does not allow to use the resources… e.g. I have a RB4011 that has 1GB RAM which is sitting 90% unused.
The flash is “only” 512MB and I have partitioned it so only 256MB available. And no USB or SD interface to extend it.

With a ramdisk I could at least run a volatile container stored in /ramdisk, but MikroTik refuse to enable it (the code is there, it only requires some trivial "if"s at startup).

[kobuki]

“something is missing/not good enough on the mikrotik device and I want to add/replace it”

I think that’s all to it. They they seem to keep adding extras to ROS to allure to more potential customers. Until it doesn’t compromise base functionality or security, I don’t thing there’s harm in doing that.

[foureight84]

I was looking into documentation and I didn’t see how one would do port mapping with Containers in ROS 7.

How did you miss this? It’s precisely the same thing as “docker create --publish 80:80”.

Then what do you do with two containers both using port 80? They’re both on the same VETH.

[kraal]

Hi,

Most arguments that I read are “something is missing/not good enough on the mikrotik device and I want to add/replace it”.

What’s wrong with that argument? It’s a perfectly valid use case.

Well if you consider that as a customer you should “help yourself” that’s inded fine. For me the “plain wrong part” is that instead of fixing / adding what’s missing (but was existing prior to ROS7) and should be part of a working solution, Mikrotik works on containers.

The cost argument is not valid either as cheap and power efficient devices can be found on the market.

Some of us have RouterOS devices with enough free RAM, flash, and CPU to do this for “free.” Buying another device to run the container is not free.

Ok, but how much free RAM/CPU to do what exactly ? For instance I don’t see a single usefull service in my 20+ VMs and containers deployed on my home network which could be a candidate for deployment on a mikrotik device. Security, performance, CPU usage, increased heat, separation of concerns, etc. Every time I evaluate a potential service I run into one of these cases: the Mikrotik device is not the place where to deploy it or the service is not lightweight enough. That’s why I’m asking: am I the only one in this situation ?

The cost argument is not valid either as cheap and power efficient devices can be found on the market.

If you do not possess a device yet that will do this in a sensible fashion, there’s a fair chance your next RouterOS device will. What will you do with your spare slice of free compute power?

Even when cost is no object, the ability to deliver a complete, integrated, custom solution may be compelling.

Well I don’t think so. I won’t deploy DMZ services on an network infrastructure appliance, nor will deploy security related services on it, nor will deploy potentially high RAM/CPU/I/O consuming services, nor critical services. That’s why I’m asking what do you really deploy on containers and for how many users ?

Even when cost is no object, the ability to deliver a complete, integrated, custom solution may be compelling.

This is an argument which may be of interest. But again what services are you talking about and for how many users ? And “integrated” with external storage ? hmm…

lowers Mikrotik bandwidth for fixing real issues (bgp for instance, pim-sm)

Development talent isn’t fungible. The people working on containers likely weren’t pulled off your pet projects, nor could they be reassigned to them and be immediately productive.

It’s part of my job to work on skills development so I know that you don’t “turn a pig into a dog just by telling him to bark”. The problem here is that these people were hired in the first place, they didn’t appear out of nowhere… There was a decision taken at a given point time to hire people to work on what appears to me as “wrong priorities” (away from what the voice of customers would ask for).

Furthermore, most of this container stuff is out there, off the shelf, ready to repurpose. A good bit of it lives in the kernel they had to update to produce v7 already. Initial development on what would become the modern container infrastructure goes back to kernel 3.10.

Yep as many other features in RouterOS as it is built on top of F/OSS.

I really see no “mindbreaking” argument so far.

Perhaps it is not for you, then.

That doesn’t mean it isn’t for anyone else, though.

Indeed, but apart from your “integrated solution” which is not really precise either. I still didn’t read what makes it a “must have” for ROS users. If I only knew, maybe it would be as well for me don’t you think ?

Regards

Edit: typo

[pe1chl]

It is not very interesting (read: of no interest at all) what you would or would not install on your router or elsewhere.
Everyone is free to decide what service they want to deploy where, and what method they want to use for it.
Given the fact that a MikroTik router does not allow a generic shell login, making it impossible to copy some random program to the device and run it as a normal Linux process, the possibility of containers is useful in many use cases, even if you cannot imagine one of them.

Of course I also would prefer if MikroTik work on feature parity in v7 (relative to v6) instead of on new features, but it is likely that the person(s) that are able to work on container are different from the one(s) that could fix and finish the BGP routing.
So we have to be patient and hope that the focus does not shift too much (with the risk that BGP will be labeled “not of interest for the RouterOS future”)…

[jvanhambelgium]

How did you miss this? It’s precisely the same thing as “docker create --publish 80:80”.

Then what do you do with two containers both using port 80? They’re both on the same VETH.

1 vETH for EACH container!
The IP’s of the containers can be in the same subnet or use different subnets.

vETH1 = 172.17.0.1
vETH2 = 172.17.0.2
…is perfectly possible.

[foureight84]

That makes sense. I tried implementing this at the time of the original post but I am on a level 1 license that restricts to just 1 VETH interface. I was also thrown off with the documentation’s example of using 172.17.0.2/16 which made me think the large IP block is for multiple containers using the same interface.

[jvanhambelgium]

Yeah I made the same wrong assumption some time ago.
And with the different vETH’s , you have full flexibility with things like DNAT etc if you want to expose to the outside world etc.