OpenWrt's 'procd' now speaks containers

[Daniel Golle]

On Fri, Aug 07, 2020 at 02:57:54PM -1000, Paul Spooren wrote:
> 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?

You would have to implemet the OCI Image Specification as well as
OCI Distribution Specification or port existing tools to OpenWrt
(eg. podman).
Note that OCI Run-Time bundle != OCI Image. So tool needs to fetch
layers from registry (usually using SPDY, but classic 'HTTP' should
work as well afaik), convert AUFS-style whiteouts to overlayfs-style
and generte the OCI Run-Time configuration.
So either we use the existing tooling (mostly written in Go and not
exactly small) or we re-implement also that part using libubox,
blobmsg-json, libuclient, ...
For now, I'd be glad if some of the folks more familiar with Go would
port podman as that would allow people to test and use 'uxc' more
easily.


Cheers


Daniel