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
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
