[RFC] OpenWrt within a Docker container

Paul Spooren mail at aparcar.org
Mon May 17 11:39:41 PDT 2021


Hello,

after some back and forth I'd like to request some more opinions on what 
kind of Docker containers to offer containing the OpenWrt rootfs. This 
is not about the SDK or ImageBuilder Docker containers.

tl;dr:

Should we ship `slim` containers only, running a OpenWrt shell (ash) and 
nothing more? Whoever wants services to run (e.g. ubus) should run 
additional containers and glue them together via mounts? Or should we 
run /sbin/init or `procd` to have a *OpenWrt-like experience*, with 
LuCI, ubusd and friends.

/tl;dr

Currently the `openwrt/rootfs` container is shipped with minimal 
modifications and starts `/sbin/init` as default action.

Running the container for e.g. LuCI development within a local shell 
results in the following output:

```
user at reactor:~$ docker run -it openwrt/rootfs
Failed to resize receive buffer: Operation not permitted
/etc/preinit: line 5: can't create 
/sys/devices/system/cpu/microcode/reload: Read-only file system
ip: RTNETLINK answers: Operation not permitted
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
ip: can't send flush request: Operation not permitted
ip: SIOCSIFFLAGS: Operation not permitted
Please press Enter to activate this console.
--- %< ---
root at da3dfbdc5ae4:/#

```

Some init scripts fail due to missing privileges. The console input is 
only possible by using a patched /etc/inittab file and multiple services 
keep failing, most problematic the `network` service since it tries and 
fails in a fast loop to flush some interfaces.

A possible patch is available[1] which disables services obsolete within 
a Docker environment, however this would "flaw" the *OpenWrt-like 
experience*.

Another, probably better approach could be to have *slim-containers* 
which only run `ash` and let the user start whatever is needed, e.g. 
`ubusd && uhttpd` and thereby have access to a LuCI interface to play with.

This would follow the experience from other popular containers like 
`alpine` or `debian`. This would also allow us to become an "official" 
container, which would allow to be used as `docker run -it openwrt` 
rather than `docker run -it openwrt/rootfs`. Some efforts were made here[2].

I'd prefer the latter option; only offer SDK and ImageBuilder and let 
the rootfs become a "official" Docker container without any running 
services. Whoever needs services can use `FROM openwrt` within a 
Dockerfile  and run whatever is needed.

Best,
Paul

[1]: https://gitlab.com/openwrt/docker/-/merge_requests/47
[2]: https://github.com/docker-library/official-images/pull/7975




More information about the openwrt-devel mailing list