可以在Windows上的Docker中运行ARM/rpi映像,但不能在Linux上运行

可以在Windows上的Docker中运行ARM/rpi映像,但不能在Linux上运行

问题描述:

我能够在Windows(64位)上的Docker中运行ARM映像(例如hypriot/rpi-node),但是在我尝试过的所有linux x86/64机器(Debian,CoreOS,Alpine等)中,我出现以下错误-这对我来说很有意义,但我不明白为什么它会在Windows上的Docker上运行,并且我想知道是否是否缺少一些机会将x86机器用作ARM映像的构建服务器(即.在google/aws cloud/azure中).有什么想法可能吗?

I'm able to run the ARM images (eg. hypriot/rpi-node) in Docker on Windows (64bit), but in all linux x86/64 machines I've tried (Debian, CoreOS, Alpine etc) I get the following error - which makes sense to me but I dont get why it'd run in Docker on Windows then, and I wonder whether I'm missing some opportunity to use an x86 machine as a build server for ARM images (ie. the in google/aws cloud/azure). Any ideas how I might be able to?

docker run -ti hypriot/rpi-node ls
standard_init_linux.go:175: exec user process caused "exec format error"

适用于Windows的Docker(适用于Mac的Docker)都使用linux vm托管容器.但是,他们使用的Linux vm与您的linux机器之间的区别在于,他们的VM具有称为binfmt_misc的内核系统设置,以便在遇到外部体系结构的二进制文件时调用qemu(

Docker for windows (and docker for mac) both use a linux vm to host containers. However, the difference between the linux vm they use and your linux machines is the fact that their VM has a kernel system called binfmt_misc setup to call qemu whenever it encounters a binary for a foreign architecture (https://github.com/linuxkit/linuxkit/blob/1c552f7a9db7f0660d3c83362d241e54142323ca/pkg/binfmt/etc/binfmt.d/00_linuxkit.conf )

如果要正确配置linux计算机,则可以将其用作ARM映像的构建服务器. Google qemu-user-static了解有关设置的一些想法.

If you were to configure your linux machine appropriately, it could be used as a build server for ARM images. Google qemu-user-static for some ideas of how to set it up.

请注意,linuxkit vm使用'F'标志,在配置典型的linux环境时,这似乎不是标准的.没有它,您需要将qemu二进制文件放入容器中.我不确定为什么在更多地方使用'F'不是标准做法(这样做似乎确实是debian的错误

Note that the linuxkit vm uses the 'F' flag which doesn't seem to be standard when configuring a typical linux environment. Without it, you need to put the qemu binary inside the container. I'm not sure why it isn't standard practice to use 'F' in more places (there does seem to be a debian bug to do so https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868030 )