docker - standard_init_linux.go :211: exec user process caused "no such file or directory" on Alpine

Question

我正在尝试按照有关使用 multi-stage builds 精简 Docker 文件的说明进行操作.特别是，我尝试使用以下 Dockerfile 将生成的可执行文件从构建器镜像复制到 alpine:latest 中:

FROM debian:stable-slim AS builder

RUN apt-get update && \
    apt-get install -y --no-install-recommends fp-compiler fp-units-fcl fp-units-net libc6-dev

COPY src /whatwg/wattsi/src
RUN /whatwg/wattsi/src/build.sh

FROM alpine:latest
COPY --from=builder /whatwg/wattsi/bin /whatwg/wattsi/bin

ENTRYPOINT ["/whatwg/wattsi/bin/wattsi"]

但是，当我尝试使用 docker run 运行生成的 docker 镜像时，出现错误

standard_init_linux.go:211: exec user process caused "no such file or directory"

这是怎么回事，我该如何解决？

Answer 1

这个问题出现了很多次，这个错误似乎有很多可能的原因。有些是missing or wrong shebang instructions in any bash scripts , 或 Windows line endings in files copied to the volume .但是，就我而言，这是出于不同的原因。

发生此错误是因为构建的二进制文件(问题中的/whatwg/wattsi/bin)取决于具有glibc 的系统安装。大概是在运行的时候，有东西在寻找系统的glibc，但是Alpine Linux 并没有可用的glibc。 (相反，它使用 musl-libc，它更精简，但不太流行。)

解决这个问题的最简单方法是使用具有可用 glibc 的不同基础镜像。您可以使用在构建器镜像 (69.2 MiB) 中使用的 debian:stable-slim，但较小的是 Google 的 Distroless base image。 gcr.io/distroless/base(16.9 MiB)。这仍然比 alpine:latest (5.61 MiB) 或 Distroless 静态图像 (1.82 MiB) 大，但还不错。

可能还有其他解决方案，例如this question讨论了在 Alpine Linux 上设置 glibc 的方法。或者，您可以弄清楚如何更改编译器/链接器以链接到系统 libc(即 Alpine Linux 上的 musl-libc)，而不是专门假设 glibc 的存在。但就我而言，gcr.io/distroless/base 工作得很好。