Docker containers.

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at osmocom.org
Sat Apr 25 17:32:33 UTC 2020


Hi Andrew,

On Sat, Apr 25, 2020 at 04:48:13PM +0100, Andrew Back wrote:
> The documentation suggests overlay networks support SCTP now:
> Not sure about bridge networks.

Well, as soon as you have an actual Layer3 or Layer2 network, for sure
you can use SCTP.

> Various vendors seem to be using Docker in NFV/SDN architectures 

I am convinced that either they must be building their own "network
drivers/plugins" to docker, or they can not implement 2G/3G 3GPP
interfaces as we know them.  This is not an Osmocom specific topic.

> would be nice to think there will be a way forward, which does not mean
> that we end up with a dichotomy, whereby other infrastructure is part of
> that world and Osmocom excluded. Be it through compliance tooling and
> best practices, plus Docker improvements — or whatever it takes.

Honestly, I seriously don't think that Docker is the right tool.  It is
actively hostile towards anyone doing anything serious in terms of
networking.  It is already an enormous nightmare to model the most
trivial of networking topologies.  It is centered around dns and dynamic
IP addresses, while classic 2G/3G is based around static IP addresses
everywhere.  You cannot have SS7/SIGTRAN on a container that gets a
dynamic IP address via DHCP.

I could imagine that other container runtimes with a less monolithic and
more modular approach might be more amenable to the requirements of 3GPP
networks, but I lack any hands-on experience with that.  Docker is just
trying to solve too many things at the same time, without giving users
the kind of tools/access to the underlying infrastructure.  Just take
the example about no way to get persistent network device naming:
	https://github.com/moby/moby/issues/25181
	https://github.com/docker/compose/issues/4645

Similarly, there is no functionality in Docker how you can move a
physical network device into a specific container.  Peaple have built
kludges/workarounds for that (https://github.com/jpetazzo/pipework)
but that's not Docker itself.

There are so many things people have been able to do for decades with
the Linux network stack on bare metal, and which they still can do with
Linux e.g. in lxc containers that I assume no Docker developer has even
imagined possible.  It's like you used to have a full mechanical
workshop available, an Docker then arbitrarily limits this to a set of
three philips screw drivers because that's what most people need ;)

Just because some people in the industry have heard some buzzwords and
think that Docker is the right tool to virtualize 3GPP network elements
doesn't mean that we have to agree :)

Sorry, I've already wasted way too many days of my life trying to work
around random arbitrary constraints of docker networking :/

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list