Overhyped Docker

Overhyped Docker missing the most basic features

I've always been extremely skeptical of suddenly emerging over-hyped
technologies, particularly if they advertise to solve problems by adding
yet another layer to systems that are already sufficiently complex
themselves.

There are of course many issues with containers, ranging from replicated
system libraries and the basic underlying statement that you're giving
up on the system packet manager to properly deal with dependencies.

I'm also highly skeptical of FOSS projects that are primarily driven by
one (VC funded?) company. Especially if their offering includes a
so-called cloud service which they can stop to operate at any given
point in time, or (more realistically) first get everybody to use and
then start charging for.

But well, despite all the bad things I read about it over the years, on
one day in May 2017 I finally thought let's give it a try. My problem
to solve as a test balloon is fairly simple.

My basic use case

The plan is to start OsmoSTP, the m3ua-testtool and the sua-testtool,
which both connect to OsmoSTP. By running this setup inside containers
and inside an internal network, we could then execute the entire
testsuite e.g. during jenkins test without having IP address or port
number conflicts. It could even run multiple times in parallel on one
buildhost, verifying different patches as part of the continuous
integration setup.

This application is not so complex. All it needs is three containers,
an internal network and some connections in between. Should be a piece
of cake, right?

But enter the world of buzzword-fueled web-4000.0 software-defined
virtualised and orchestrated container NFW + SDN vodoo: It turns out to
be impossible, at least not with the preferred tools they advertise.

Dockerfiles

The part that worked relatively easily was writing a few Dockerfiles to
build the actual containers. All based on debian:jessie from the
library.

As m3ua-testsuite is written in guile, and needs to build some guile
plugin/extension, I had to actually include guile-2.0-dev and other
packages in the container, making it a bit bloated.

I couldn't immediately find a nice example Dockerfile recipe that would
allow me to build stuff from source outside of the container, and then
install the resulting binaries into the container. This seems to be a
somewhat weak spot, where more support/infrastructure would be helpful.
I guess the idea is that you simply install applications via package
feeds and apt-get. But I digress.

So after some tinkering, I ended up with three docker containers:

• one running OsmoSTP




• one running m3ua-testtool




• one running sua-testtool

I also managed to create an internal bridged network between the
containers, so the containers could talk to one another.

However, I have to manually start each of the containers with ugly long
command line arguments, such as docker run --network sigtran --ip
172.18.0.200 -it osmo-stp-master. This is of course sub-optimal, and
what Docker Services + Stacks should resolve.

Services + Stacks

The idea seems good: A service defines how a given container is run,
and a stack defines multiple containers and their relation to each
other. So it should be simple to define a stack with three
services, right?

Well, it turns out that it is not. Docker documents that you can
configure a static ipv4_address , .

This seems to be related that for some strange reason stacks can (at
least in later versions of docker) only use overlay type networks,
rather than the much simpler bridge networks. And while bridge
networks appear to support static IP address allocations, overlay
apparently doesn't.

I still have a hard time grasping that something that considers itself a
serious product for production use (by a company with estimated value
over a billion USD, not by a few hobbyists) that has no support for
running containers on static IP addresses. that. How many applications
out there have I seen that require static IP address configuration? How
much simpler do setups get, if you don't have to rely on things like
dynamic DNS updates (or DNS availability at all)?

So I'm stuck with having to manually configure the network between my
containers, and manually starting them by clumsy shell scripts, rather
than having a proper abstraction for all of that. Well done :/

Exposing Ports

Unrelated to all of the above: If you run some software inside
containers, you will pretty soon want to expose some network services
from containers. This should also be the most basic task on the planet.

However, it seems that the creators of docker live in the early 1980ies,
where only TCP and UDP transport protocols existed. They seem to have
missed that by the late 1990ies to early 2000s, protocols like were invented.

But yet, in 2017, Docker chooses to

• blindly assume TCP in
  ), but then
  only parse tcp and udp, despite people requesting support for other
  protocols like SCTP to run my three
  test programs in a separate network namespace for isolated execution of
  test suite execution as part of a Jenkins CI setup :/

  
  

  It's also clear that Docker apparently don't care much about playing a
  role in the Cellular Telecom world, which is increasingly moving away
  from proprietary and hardware-based systems (like STPs) to virtualised,
  software-based systems.