在使用下面的代码构建时，我遇到了类似的问题

FROM golang:1.18.0-alpine3.15 AS builder

WORKDIR /go/src/blah
COPY . .

RUN go get -d -v ./...
RUN go install -v ./...

WORKDIR /go/src/blah

FROM centos AS runtime   ## NOTICE THE DISTRO CHANGE HERE
COPY --from=builder /go/bin/blah /bin/blah

CMD ["blah"]

以下是我的解决方案(与上面概述的相同，但添加了供人们检查)

FROM golang:1.18.0-alpine3.15 AS builder

WORKDIR /go/src/blah
COPY . .

RUN go get -d -v ./...
RUN export CGO_ENABLED=0 && go install -v ./...    <== added during install/build

WORKDIR /go/src/blah

FROM centos AS runtime
COPY --from=builder /go/bin/blah /bin/blah

CMD ["blah"]

欢呼。

我解决了一个类似的问题

我的配置: —> Docker Desktop WSL 2后端—Windows ->需要CGO_ENABLED=1，因为我使用库编译了一个Kafka生产者 confluent-kafka-go.v1 /卡夫卡

我的docker映像已经构建成功，但当我使用docker-compose启动映像时，出现了同样的问题:

xxxxx:~/cp-all-in-one/cp-all-in-one-community# docker-compose up
Recreating ms-c3alert ... done
Attaching to ms-c3alert
ms-c3alert | standard_init_linux.go:211: exec user process caused "no such file or directory"
ms-c3alert exited with code 1

之后，在线程和另一个页面测试所有选项…我发现修复添加在go build句子-ldflags='-w -extldflags "-static"'

RUN CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -ldflags='-w -extldflags "-static"' -a -installsuffix cgo -o c3alert .

这是因为shell脚本是在windows中格式化的，我们需要更改为unix格式。 您可以在任何Linux系统上运行dos2unix命令。

dos2unix your-file.sh

如果你不能访问Linux系统，你可以使用Git Bash for Windows，它带有dos2unix.exe

dos2unix.exe your-file.sh 

如果试图在从头开始的容器中运行动态链接的可执行文件，也会出现此错误。可执行文件将不能链接到共享库，并将报告一个(不是很有信息量)。"没有这样的文件或目录"错误。

让我们构建一个动态可执行测试:

cat <<EOF | g++ -x c++ - -o test
#include <iostream>
int main() {
    std::cerr << "Hello!" << std::endl;
    return 0;
}
EOF

这确实是一个动态可执行文件。运行ldd测试将报告如下内容(依赖于libc等):

linux-vdso.so.1 (0x00007ffd699fc000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff570f7a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff570c76000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff570a5f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5706c0000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff5714fe000)

现在，让我们用以前的可执行文件从头构建一个映像。Dockerfile将是:

FROM scratch
COPY test /
CMD [ "/test" ]

构建映像。然后，运行一个来自image的动态容器:

docker build . -t local/test
docker run --rm local/test

容器失败的退出码1，我得到:

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

这个问题是通过使用静态链接(在之前的gcc/g++ linker命令中使用-static flag)来解决的，它会生成一个独立的可执行文件。

存在的问题:

The problem comes from the .sh file. First we must remember that Windows uses \r\n as the end of the line, while Linux and Mac use \n. Git has a feature called autoclrf that is generally set to “true” on Windows. This automatically converts \n to \r\n upon completion of the download from a Git repository, but Git does not make any kind of notice of this, hence the error is generated. This process is good, at least for the other files, but it is not the case for bash files, as is the case for the entrypoint.sh file.

立即解决方案:

打开您最喜欢的代码编辑器并更改导致冲突的文件的行结束符，在我们的示例中是:entrypoint.sh。你可以在软件右下角的Visual Studio Code中做到这一点，单击CRLF，并将文件行的末尾更改为LF。

从下面的链接阅读整篇文章，找到永久的解决方案:

https://davidcasr.medium.com/docker-standard-init-linux-go-211-exec-user-process-caused-no-such-file-or-directory-en-c0cb42edb295

这是CRLF的问题。我用这个解决了这个问题:

git config --global core.eol lf

git config --global core.autocrlf input

find . -type f -print0 | xargs -0 dos2unix