在Balena容器的Alpine中运行openrc，除softlevel外有更佳方案吗？

背景信息 #

我在Balena容器组合中运行Alpine Linux，这不属于典型Docker使用场景。Balena主打将Docker容器组合部署到嵌入式设备，以此简化小型特殊设备上复杂应用的部署流程。

在这个场景下自由度很高，Docker更多被当作应用模块来用，而Balena OS正是为此设计的。因此，在Docker容器内运行systemctl/systemd服务属于非典型用法，但对于把传统PC端应用迁移到Balena环境的需求来说，这是很常见的情况。

本次问题中，我无法修改代码，且必须运行服务。核心诉求是：在Alpine上实现该需求的最佳方式是什么？（我已在Debian上通过systemctl实现了该功能）

现有尝试与问题 #

我可以用Alpine的openrc（对应Debian的systemctl|systemd）来运行服务，但需要在Docker容器中启用softlevel模式：

touch /run/openrc/softlevel

而非通过openrc“启动”系统。不过在运行的Docker容器中执行时，openrc会弹出醒目的黄色警告：

/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/blkio/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/cpu/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/cpuacct/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/cpuset/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/devices/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/freezer/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/hugetlb/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/memory/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/misc/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/net_cls/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/net_prio/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/perf_event/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/pids/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/rdma/tasks: Read-only file system
/lib/rc/sh/openrc-run.sh: line 108: can't create /sys/fs/cgroup/systemd/tasks: Read-only file system
 * You are attempting to run an openrc service on a
 * system which openrc did not boot.
 * You may be inside a chroot or you may have used
 * another initialization system to boot this system.
 * In this situation, you will get unpredictable results!
 * If you really want to do this, issue the following command:
 * touch /run/openrc/softlevel

这种方式是否可行？有没有更好的方法在Docker中运行openrc？这些警告会有什么影响？还是说它能正常工作？

我的顾虑 #

理想情况下，我希望Docker容器的CMD|ENTRYPOINT参数尽可能简洁，让openrc能正常工作。

ENTRYPOINT指定容器启动时运行的命令。如果Dockerfile同时包含ENTRYPOINT和CMD指令，CMD参数会作为ENTRYPOINT命令的参数传递。运行容器时可以指定新命令覆盖ENTRYPOINT。

这意味着，如果CMD/ENTRYPOINT中包含openrc启动指令，即便容器配置正确，当ENTRYPOINT被脚本或后续操作覆盖时，容器也无法按预期工作，除非操作者知晓正确的openrc启动方式。

相反，在BalenaOS中运行openrc且ENTRYPOINT常被覆盖的场景下，启用softlevel模式或许正是我需要的。但我只能通过测试验证其可行性，缺乏理论层面的依据。

结合上述背景，在Docker容器中通过openrc运行服务的最佳方式是什么？

内容的提问来源于stack exchange，提问作者Chris