OpenWrt's 'procd' now speaks containers
daniel at makrotopia.org
Fri Aug 7 15:47:59 EDT 2020
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.
# install packages
opkg install kmod-veth uxc ujail-console
# create veth pair for container
uci batch <<EOF
# set proto='none' assuming DHCP client inside container
# use 'static' otherwise and also set ipaddr, gateway and dns
# assuming OCI run-time bundle with config.json in /mnt/sda3/debian
uxc create container1 /mnt/sda3/debian true
uxc start container1
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.
It'd be great to get some feedback and learn about potential needs and
More information about the openwrt-devel