Containers and responsibilities on host actions

A cryptic title, yes.

One thing that has been bothering me for a while with SPCs is that they often perform actions in the context of the host.

I.e. sometime a go I tried to get customer udev rules on to the host to get them recoginized by udevd (which should only be running on the host). The solution back then was to have a command during the container deployment which copied the files from inside the container to the host. This action was performed by the container - and this is bad, because the container needs to ensure that it finds the right place on the host. Because of this small interaction with the host, the container looses it’s portability.

Now, Roman let me know how cAdvisor is handling config discovery inside of containers: It is using plain docker LABELs to expose the config. This config can then be read by cAdvisor (runing on the host) and cAdvisor can access the container to fetch the config and do whatever it neesd to do.

The same mechanism can be adopted for other cases, where a file or action needs to be performed on the host, like adding a custom udev rule.

I.e. for adding a custom udev rule, the container could define a label:

LABEL org.example.udev.rules.custom /path/to/my.rule

A component on the host side - on Fedora probably atomic - would inspect this label and perform the necessary action.

This is a great flow, because it is a declarative approach, and the separation between container and host is kept a little bit more than before.

The same principle can actually (and is) applied to higher-level tools like kubernetes. In that context annotations can be used to expose stuff.

::: {#footer} [ May 6th, 2016 12:35pm ]{#timestamp} [fedora]{.tag} [atomic]{.tag} [udev]{.tag} :::