由于我们的 Dockerfile 使用多阶段构建，
FROM golang-alpine as build
...
FROM alpine as prod
...
由于 alpine 镜像非常小，只有 5 mb 左右，但是由于客户那边强制要使用红帽的基础镜像，所以在第二阶段修改成红帽的镜像，最终打成的镜像运行的时候会提示 No such file or directory。
先说结果
这个问题的原因在于第一阶段构建的环境和第二阶段的运行的环境不一致，很多时候以为都是 Linux 环境，怎么可能不一致呢，但是由于 Linux 的各个发行版都有自己定制化的部分，就譬如 alpine 分支，他的 C 语言动态链接库使用的是 musl，而像 centos 用的都是 glibc，他们都是 c 语言的标准库，用来调用操作系统的库。
上面说的是一方面原因，但是不是这个问题的最具体的原因。
go build 打包出来的二进制文件还写一个非常重要的信息 interpreter。
我将二进制文件从容器内 copy 出来通过 file 查看
$ file main_alpine
/app/main_alpine: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, Go BuildID=DhA6cmZs6MxBAv6mHCP-/EObNtMuW1c-MWYfhAt-J/koCmwSCoqY7V5VjEjCbZ/6EhWkyVxzgneeLbFgCKp, not stripped
$ file main_centos
/app/main_centos: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=cjxetIHekB97uQ3ZAAms/EObNtMuW1c-MWYfhAt-J/koCmwSCoqY7V5VjEjCbZ/92-lIHHBJhIK8zwllpfL, not stripped
可以看到二进制的文件上有些一个解释器的地址，这个文件地址是写死在二进制文件上的，后面我启动一个 centos 容器。
$ /lib/ld-musl-x86_64.so.1 /app/main_alpine
bash: /lib/ld-musl-x86_64.so.1: No such file or directory
果然报了同样的一个错误。
Linux 如何启动一个二进制文件可以参考一下参考文档，就是通过这个解释器出发将程序调入内存。
网友评论