
Announcing Intel Clear Containers V2.1.1 - ah-
https://clearlinux.org/blogs/announcing-intel%C2%AE-clear-containers-v211
======
alpb
Here's a cool technical and short article about the Clear Containers by
someone worked on the project to bring you up to speed with what is going on:
[https://lwn.net/Articles/644675/](https://lwn.net/Articles/644675/)

------
philips
If you want to try out Clear Containers with rkt you can easily do it on a
linux physical machine. First, install rkt via deb/rpm[1] or tarball[2]

Then do:

    
    
        sudo rkt run --debug --insecure-options=image --stage1-name=coreos.com/rkt/stage1-kvm:1.25.0 docker://redis
    

If you run into problem you can email rkt-dev[3].

[1] [https://coreos.com/rkt/docs/latest/distributions.html#rpm-
ba...](https://coreos.com/rkt/docs/latest/distributions.html#rpm-based) [2]
[https://github.com/coreos/rkt/releases/tag/v1.25.0](https://github.com/coreos/rkt/releases/tag/v1.25.0)
[3] [https://groups.google.com/forum/#!forum/rkt-
dev](https://groups.google.com/forum/#!forum/rkt-dev)

------
chatmasta
I hadn't seen this project before. It looks really cool. I especially like the
support for pushing network configuration at startup (via the "hyperstart"
concept in v1 and systemd in v2). This is sorely lacking in Docker. You can
accomplish it with pipework (which is just a wrapper around `ip exec` in the
container netns), but then you need to write code in the container like "wait
for interface XX to be up before running entry_point.sh"

My use case is creating containers with multiple interfaces and custom routing
rules for each interface. Currently I am using pipework.sh to setup the
interfaces and routes, but it's a dirty hack and increases container boot time
due to the need to poll for interfaces to be up before starting the
application. It looks like this "hyperstart"/systemd approach to namespace
isolation avoids that latency, which is nice.

Unfortunately, according to these docs, each container interface requires a
tap bridge in addition to the usual veth pair, due to qemu networking
limitations. That's unfortunate, especially for containers with multiple
interfaces, which is specifically my use-case.

Does anyone have an idea of the overhead of creating many tap interfaces
within a container?

~~~
doublerebel
FWIW I just use Joyent Triton with SmartOS and docker containers, my VLANs
exist on start and I can't imagine dealing with those issues. What SDN
solution are you using that requires this kind of init process?

Solaris solved the service dependency graph problem with SMF, which is nice.

~~~
chatmasta
I'm using out of the box docker container networking. I setup a bridge network
(docker network create) for every external IP on the host. Each container
needs multiple external IPs, so it joins multiple bridge networks and then
sets up routing rules for the outbound traffic on each interface. When
creating a container, you can only join it to one network. But once it's
created you can run 'docker network attach' to join other networks (and get an
interface for each). However the application is already running at that point.

What I really want is to create and configure a network namespace using my own
tools, and then launch a docker container into the existing namespace. I
haven't figured out how to do this yet.

~~~
dlespiau
(Clear Containers dev here)

I believe a "correct" way to do it would be to create a network plugin (or
extend an existing one that does 80% of what you want) for docker doing what
you want. Those are the ones responsible for setting up the network namespace
at startup. A new CNM plugin, only if the current one isn't enough of course,
a number of things can be done before container startup, eg.
[https://docs.docker.com/engine/userguide/networking/default_...](https://docs.docker.com/engine/userguide/networking/default_network/build-
bridges/).

The Clear containers OCI runtime doesn't add a feature to push network
configuration in addition to what Docker already does today. It relies on a
CNM plugin to setup the network namespace, as usual, then reads back the netns
configuration to decide how to best interface between the container netns and
the network stack within the VM. It's not exactly easy to get right and we
have to juggle with all thid because we're trying to shoehorn a VM where netns
are the de-facto interface. Work is going on to make all this simpler and
integrated, but it will take some time.

A current limitation is that only the netns configuration at startup time is
taken into account and `docker network connect` on a running container doesn't
work (we'd have to listen to changes in the netns and propagate the
configuration to the VM).

A bit more info there: [https://github.com/01org/cc-oci-
runtime/blob/master/document...](https://github.com/01org/cc-oci-
runtime/blob/master/documentation/architecture.md#networking)

~~~
chatmasta
Thank you very much for the reply.

I've already seen those links, but the information in your comment provides
valuable context. Thanks!

One problem I've noticed is that you cannot add a routing table to a network
namespace with the `ip exec netns <nsid>` command, because there is no `ip`
command for creating a routing table. You need to edit the /etc/rt_tables
file. Because of this, if your network configuration depends on creating
routing tables, you need to wait for the filesystem to mount so you can edit
/etc/rt_tables.

I've tried doing things like `ip exec netns <nsid> echo "tblnm 42" >>
/etc/rt_tables` but I couldn't get it to work (how to redirect echo output in
exec subshell into /etc/rt_tables in network namespace?).

I'm trying to create a really fast, multi-tenant routing fabric. I am relying
on namespaces to separate rules, routes, and subnets from each other. This way
all routing logic for tenants is separate but still done with native linux
routing features at kernel speed.

I would love to be able to create the network namespace without any
application running in it (so I can take advantage of kernel routing speed),
and only launch an application when necessary (hmm... perhaps a one-time
application to configure /etc/rt_tables)

------
gtirloni
Anyone using this in production and betting on the long term viability of this
project?

------
tyingq
Sounds similar to what [http://hypercontainer.io](http://hypercontainer.io) is
doing.

------
phildougherty
Pretty neat how nicely this integrates into an existing docker host setup.
Definitely going to give it a try and see about integrating into
containership.

edit: typo

------
nimish
Containers done right

I wish the documentation was better for integrating with docker seamlessly

