Docker之交叉编译

最近由于业务需要，在做一些关于国产化相关的事情，需要将平台从x86架构迁移到arm64上run起来，最重要的环节则在于镜像都需要rebuild一遍，在这个过程中还是碰到一些问题，拿出来分享一下，希望对其他人会有所帮助.

把所有的镜像都rebuild，这是个很辛苦且枯燥的事情，还好日常工作中都会良好的版本管理，每个应用的版本都对应有相应的commit号，这个可以直接使用稳定的版本进行rebuild,可以省去联调的工作

先简单介绍下binfmt_misc，后面docker交叉编译会用上.

binfmt_misc

binfmt_misc(Miscellaneous Binary Format)是Linux内核从很早开始就引入的机制，可以通过要打开文件的特性来选择到底使用哪个程序来打开它，不光可以通过文件的扩展名来判断的，还可以通过文件开始位置的特殊的字节（Magic Byte）来判断

这里不过多介绍，简单来说说是通过注册一个“解释器”和一个文件识别方式，以达到运行文件的时候调用自定义解释器的目的，docker buildx即是通过这种方式

启用binfmt_misc也比较简单，可以使用现成的docker直接启动:

docker run --rm --privileged docker/binfmt:66f9012c56a8316f9244ffd7622d7c21c1f6f28d

检查是否开启:

ls -al /proc/sys/fs/binfmt_misc/
-rw-r--r-- 1 root root 0 11月 18 00:12 qemu-aarch64
-rw-r--r-- 1 root root 0 11月 18 00:12 qemu-arm
-rw-r--r-- 1 root root 0 11月 18 00:12 qemu-ppc64le
-rw-r--r-- 1 root root 0 11月 18 00:12 qemu-s390x
--w------- 1 root root 0 11月 18 00:09 register
-rw-r--r-- 1 root root 0 11月 18 00:12 status

注意: 如果是centos的话，建议升级内核到4+以上

编译方法

大致有3种编译方法:

1. 直接在对应架构的机器上进行
2. 通过模拟器的方式，最常用的模拟器是开源的 QEMU
3. 通过binfmt_misc模拟目标硬件的用户空间
4. 通过交叉编译，像andriod程序，一般就是通过交叉编译而来，还有如go语言等，本身就有交叉编译器

这里要重点说的是docker的交叉编译

docker buildx

docker 在19.03的版本支持了一个实验性的功能 - - buildx，大大地减少了编译工作，但也还是有些坑，慢慢道来

利用 Docker 19.03 引入的插件 buildx，可以很轻松地构建多平台 Docker 镜像。buildx 是 docker build ... 命令的下一代替代品，它利用 BuildKit 的全部功能扩展了 docker build 的功能

这里不详细介绍该如此开启buildx了，大家可参考官方的handbook，这里假设开启了”experimental”: true

使用以下命令确认开启了:

docker info | grep -i exp
Experimental: true  

Docker buildx需要开启binfmt_misc， 开启方法如下

验证是否启用了相应的处理器：

cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/bin/qemu-aarch64
flags: OCF
offset 0
magic 7f454c460201010000000000000000000200b7mask 
ffffffffffffff00fffffffffffffffffeffff

Docker 默认会使用不支持多 CPU 架构的构建器，我们需要手动切换。

先创建一个新的构建器：

# 新建构建器
docker buildx create --use --name mybuilder 
# 启动构建器
docker buildx inspect mybuilder --bootstrap

准备工作就绪后，下面以例子来说明，既然是交叉编译，那就得先有一个初始的x86 的Dockerfile，然后将其编译出arm64的镜像

下文说到的体系架构指的就是x86跟arm64.

Docker Manifests

这里先解释下docker的manifests特性，因为下面会用到

FROM golang:alpine AS builder

相信大家在编写Dockerfile的时候会经常这么用，正常来说，这么写的镜像都是从docker hub拉取的镜像，docker hub上的镜像支持docker的manifests特性，简单来说就是一个镜像地址，当我们docker pull的时候，它会根据当前机器体系架构来拉取对应于这个体系架构的镜像，比如你是x86的，则给你拉取的是x86的镜像，是arm64的机器拉取的则是arm64的，原理就在于每个镜像都维护着一个manifest(清单),这个清单上记录着每个体系架构对应用镜像层，在docker pull的时候，docker这时做为一个client端，与docker hub的服务端通信的时候，会先看这个镜像存不存在manifests，如果存在则拉取匹配当前机器体系架构的镜像，如果不存在，则就直接拉取.

了解这个对下面的实践很重要

实践

这里以go语言的应用为例，直接在x86的CentOS机器上，如果不做特别说明，以下的所有操作都是在该机器上执行

dockerfile如下:

FROM golang:alpine AS builder
RUN mkdir /app
ADD . /app/
WORKDIR /app
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o hello .  # 注意这里

FROM alpine
RUN mkdir /app
WORKDIR /app
COPY --from=builder /app/hello .
CMD ["./hello"]

这里要注意go build命令，

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o hello .

简单说一下go的交叉编译:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go .
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build main.go .

GOOS指定的是目标机器的操作系统

GOARCH指定的是体系架构（i386、amd64、arm64）等

由于go是编译型语言，编译出来的都是二进制文件，这个二进制文件的运行环境一定是要跟编译时指的是编译参数一致，就好比，windows下的exe文件无法在linux上执行一样，如果指定了go编译的参数为amd64，则它就不能在arm64上运行,反过来同理

X86机器编译X86镜像

所以，x86正常编译的build命令为:

docker build -t xxx/yyy/zzz:latest .

由于是直接在x86的linux机器上，不存在交叉编译，所以可以直接使用build命令，最终产生的镜像就是一个可以运行在X86的机器上，如果运行在arm64的机器上，则会提示以下错误:

以上的错误基本都是运行的镜像与体系架构不匹配导致的

X86机器上编译arm64镜像

编译x86非常方便，也是我们最常规的操作，如果将上面的Dockerfile使用交叉编译编译出arm64的镜像呢

这里要注意的是，由于go本身就支持交叉编译，因此基础镜像是可以不用调整的,修改如下:

FROM golang:alpine AS builder # 注意这里
RUN mkdir /app
ADD . /app/
WORKDIR /app
RUN CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o hello .  # 修改的这里

FROM alpine  # 注意这里
RUN mkdir /app
WORKDIR /app
COPY --from=builder /app/hello .
CMD ["./hello"]

使用以下的命令编译出来的镜像就是arm64的了

docker buildx build -t xxx/yyy/zzz:latest --platform=linux/arm64 . --push

–push 表示构建之后直接将该镜像推送到镜像仓库中

可以看到，Dockerfile文件修改只修改了1行，已经在注释中标注出来了

二个From 为何都不需要改呢? 这个放到下文解析–platform中再说

go build那行的命令GOARCH已经修改为arm64了，表明目标体系架构为arm64，那最终生成的二进制在arm64是可以运行的.

这里要重点说一下docker buildx --platform这个参数, 顺便解释一下为何两个From的基础镜像都不需要修改的原因

首先–platform这个参数决定了Dockerfile文件中所有From后面的镜像的体系架构以及最终生成的镜像的体系架构，像上面那样，直接是

FROM golang:alpine AS builder 相当于FROM --platform=arm64 golang:alpine AS builder，而

FROM alpine 相当于FROM –platform=arm64 alpine`, 拉取下来的就是arm64的镜像，因此上面是可以不用修改的

这里说的是From中没有指定--platform的情况则会自动添加上docker buildx --platform中的参数，如果本身就存在的话，则是以From本身的--platform决定

但是一定要确保，最后一个From的镜像体系架构一定要跟目标体系架构保持一致，也就是说，如果上面的例子中最后一个From改成

From alpine-amd64 (不一定有这个镜像，这里只是形象说明),docker buildx不会报错，会正常编译通过，在docker run 这个镜像的时候就会出现exec format error

这里可能有人会问: 那为什么arm64的镜像可以在x86上run起来呢?

这个其实就是binfmt_misc在起作用，模拟了目标体系架构

但这有一个问题:

很多时候，由于各种不可明说的原因，我们并不会每次都直接去docker hub上拉取镜像，而是将镜像推送到公司内的镜像仓库，如果恰好镜像仓库还不支持manifest这个特性的话(比如我司)，那上面的例子就有坑了，因此，必须要这么写

FROM xxx/yyy/golang:alpine AS builder # 注意这里
RUN mkdir /app
ADD . /app/
WORKDIR /app
RUN CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o hello .  # 注意这里

FROM xxx/yyy/alpine-arm64  # 注意这里
RUN mkdir /app
WORKDIR /app
COPY --from=builder /app/hello .
CMD ["./hello"]

最后的一个FROM一定要是arm64的，由于是在x86的机器上使用交叉编译，如果镜像仓库又不支持manifest，则只能显示地指定使用arm64的镜像，这样打出来的镜像还会是arm64的

那为什么第一个FROM没有修改呢? 因为go本身是支持交叉编译的，虽然拉下来的是x86的镜像， 但go build出来的是arm64的，最后塞到alpine-arm64镜像里去的也是arm64的，这个是不冲突的，当然，第一个FROM换成arm64的golang:alpine也是没问题的

arm64机器编译arm64镜像

目标体系架构跟机器一致，这个就更没什么好说的了，直接使用最开始的Dockerfile就行

总结

这个例子中使用的是go，由于go本身就支持交叉编译，因此还算是方便

对于一些前端js的编译，也比较方便，因为js编译出来的都是一堆js文件，跟机器体系架构关系不大，

java的也是如此，天然的是通过java虚拟机的方式，屏蔽了底层的差异，跟机器体系架构关系不大

因此总结来说

对于交叉编译来说，保证最后一个FROM的镜像跟目标体系架构的一致即可

另外，docker buildx还有很多其它的选项，值得深入研究一番，有时间下次更

参考文章:

• https://blog.lyle.ac.cn/2020/04/14/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt-misc/
• https://www.w3xue.com/exp/article/201912/66543.html
• Building Multi-Arch Images for Arm and x86 with Docker Desktop
• https://gitee.com/windforce1981/buildx?_from=gitee_search#/windforce1981/buildx/blob/master/docs/reference/buildx_build.md
• https://gitee.com/windforce1981/buildx/blob/master/docs/reference/buildx_build.md

转载请注明原作者: 周淑科(https://izsk.me)