OpenWrt's 'procd' now speaks containers

[Paul Spooren]

On 07.08.20 09:47, Daniel Golle wrote:
> Dear community,
>
> in the past couple of months I've been working on implementing the
> Open Container Initiative Runtime Specification [1] in procd by
> extending the already existing support for slim containers ('ujail').
> As a result, there is now a new CLI tool called 'uxc' which handles
> the basic operations on containers as defined by the spec [2].
> This allows to use it as a drop-in replacement for Docker's 'runc'
> (or 'crun') on OpenWrt hosts with a significantly reduced footprint.

Great news! Thank you very much your work! Due to the high traffic on 
OpenWrt I'm sure a lot of people will miss that email. I'd like to see a 
first usage[1] of openwrt-annouce and also a news bit on the website.

[1]: https://lists.openwrt.org/pipermail/openwrt-announce/

> Examples usage:
>
> # install packages
> opkg install kmod-veth uxc ujail-console
>
> # create veth pair for container
> uci batch <<EOF
> set network.veth0=device
> set network.veth0.type='veth'
> set network.veth0.name='vhost0'
> set network.veth0.peer_name='virt0'
> add_list network.lan.ifname='vhost0'
> set network.virt0=interface
> set network.virt0.ifname='virt0'
> set network.virt0.proto='none'
> # set proto='none' assuming DHCP client inside container
> # use 'static' otherwise and also set ipaddr, gateway and dns
> set network.virt0.jail='container1'
> set network.virt0.jail_ifname='host0'
> commit network
> EOF
>
> # assuming OCI run-time bundle with config.json in /mnt/sda3/debian
> uxc create container1 /mnt/sda3/debian true
> uxc start container1
>
> uxc list
> uxc state container1
>
> If the container uses a stdio console, you can attach it using
> ujail-console -c container1
> (there is no buffer, so if you like to see the complete bootlog of
> a container, make sure to attach a console after the 'create' call
> but before starting it)
>
> Roundabout 95% of the OCI run-time spec are supported which should
> be enough to already make some use or experiments with it and try
> running common containers (eg. using docker, podman or umoci to
> prepare an OCI run-time bundle on another host and launch it on
> OpenWrt).
>
>
> As the OCI spec defines JSON representations of capabilities as well
> as seccomp filter, my plan is to make use of those (more expressive)
> formats instead of our current approach to handle capabilities and
> seccomp filter in 'classic' ujail slim-containers.
>
> The conversion from OpenWrt's ujail's vendor
> JSON schema into the OCI schema is possible easily for both
> capabilities and seccomp and would have several advantages:
>   * having only one parser
>   * using a well documented specification
>   * having more expressive power (all capability sets can be edited
>     rather than just the boundinng set, seccomp filters can be
>     defined for groups of syscalls with user defined action rather
>     than just having a simple list of allowed calls).
>
> If there is everyone agrees, I'd start converting things.
I've never used it, but I'm all for not brewing our own stew but use 
what's already there.
> It'd be great to get some feedback and learn about potential needs and
> use-cases.

I'll give it a test within a qemu VM (doh!).

How complex is a minimal repository client which automatically downloads 
images (layers) from hub.docker.com or registry.gitlab.com? From my 
understanding Docker supports multiple architectures[2] so some existing 
containers may run on non x86 devices?

[2]: https://docs.docker.com/docker-for-mac/multi-arch/

> Cheers
Paul