为嵌入式设备交叉编译Linux容器

Question

我最近接触了Docker，发现它是一个很好的工具，可以使生产部署的风险大大降低(来自嵌入式世界，嵌入为"Linux移植在定制的arm PCB-s上，具有完整的系统映像交叉构建“)。

然而，我很快就体验到构建Docker映像是一个“执行运行时步骤”的过程，而不是使用Yocto构建一个rootfs。这是一个节目停止，因为它防止交叉编译。而且，在这种方法中，主机上没有sysroot的概念。

我见过云服务提供了为Arm构建Docker映像的选项，但考虑到再次缺少sysroot，它开始感觉像是一个笨拙的解决方案，我对这个想法感到不舒服……此外，如果您切换到一个不同的处理器平台，您必须交叉编译一个.

所以我想知道，这种无风险的生产更新是一件很棒的事情，肯定有人已经考虑过了，所有的智能机箱和路由器都需要远程更新，当然他们有某种“容器监管器”的架构，以防止系统在发生电源故障或严重的应用程序错误时死亡，但我得到的最远的是一个小型lwm文章只是在与这个想法调情。

更新:找到了一个新参考文献，它的目标似乎是这个方向。

我想听听你到目前为止所看到的解决这个问题的方法，以及哪种技术？

您是否使用了一个故障安全引导程序来等待一个完整的新映像(内核和rootfs)，以防出了什么问题？

构建带有构建系统的用户空间容器的概念吗？

Answer 1

我记得raspberry pi的NOOBS，但这需要用户交互。

我对嵌入式世界并不熟悉，但所有的容器/docker/x都是最近的堆栈，所以它可能还没有达到嵌入世界。:)

对容器的systemd方法是非常整洁的，您可以制作真正打包的sysroot容器(dnf = fedora，debootstrap = debian)，并使用systemd非常整洁地对它们进行监督。例如：

 mkdir /tmp/myimage 
 dnf --releasever=23 --installroot=/tmp/myimage install <package-name>
 rm -rf /tmp/myimage/var/cache/dnf
 # tar zcvf - /tmp/myimage | docker import - myimage ?

给你一个图像，是大约30米(15米压缩)，再加上大小的任何软件包，你正在安装。

在内核失败的情况下，正常情况下将使用kvm进行测试。我不知道任何用于内核测试的systemd特性(我不是一个系统专家)，但是内核肯定有一些引导钩子。

例如：

您可以使用systemd.unit=emergency.target启动，并定制emergency.target来完成您的工作而不存在“问题”，我认为您可以在那里做“任何事情”，比如恢复内核.但你知道你处在一个破碎的系统壳里所以也许这并不容易.;)

所以，如果可能的话，我会押注于系统方法。

你在用yocto吗？如果是，那你能解释一下原因吗？

干杯祝你好运。;)