Announcing Intel Clear Containers V2.1.1 | Hacker News Reader

Announcing Intel Clear Containers V2.1.1

clearlinux.org

93 pointsah-12 comments

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/

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... [2] https://github.com/coreos/rkt/releases/tag/v1.25.0 [3] https://groups.google.com/forum/#!forum/rkt-dev

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?

Sounds like the networking model for containerd will suit you? See https://github.com/docker/containerd/issues/362#issuecomment... - you get as long as you like to set up networking before the process starts running.

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.

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.

(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_....

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

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)

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

Sounds similar to what http://hypercontainer.io is doing.

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

Containers done right

I wish the documentation was better for integrating with docker seamlessly

Reply on news.ycombinator.com