OpenWrt's 'procd' now speaks containers
mail at aparcar.org
Fri Aug 7 20:57:54 EDT 2020
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  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 .
> 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 of openwrt-annouce and also a news bit on the website.
> 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
> # 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
> 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
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 so some existing
containers may run on non x86 devices?
More information about the openwrt-devel