给定一个二进制文件，使用Go使用GOOS=linux和GOARCH=amd64编译，并部署到基于alpine:3.3的docker容器中，如果docker引擎主机是Ubuntu（15.10）:，则该二进制文件将不会运行
sh: /bin/artisan: not found
如果docker引擎主机是部署在Mac OS X上的VirtualBox VM中的busybox（它是alpine的基础），那么这个相同的二进制文件（为相同的操作系统和arch编译）将运行良好。
如果容器基于一个Ubuntu映像，那么这个二进制文件也会运行得很好。
知道这个二进制文件缺少什么吗
这是我所做的复制（在操作系统X上的VirtualBox/bussybox中成功运行，未显示）：
构建（即使拱门匹配，也显式使用标志构建）：
➜ artisan git:(master) ✗ GOOS=linux GOARCH=amd64 go build
检查它是否可以在主机上运行：
➜ artisan git:(master) ✗ ./artisan
10:14:04.925 [ERROR] artisan: need a command, one of server, provision or build
复制到docker目录，构建，运行：
➜ artisan git:(master) ✗ cp artisan docker/build/bin/
➜ artisan git:(master) ✗ cd docker
➜ docker git:(master) ✗ cat Dockerfile
FROM docker:1.10
COPY build/ /
➜ docker git:(master) ✗ docker build -t artisan .
Sending build context to Docker daemon 10.15 MB
Step 1 : FROM docker:1.10
...
➜ docker git:(master) ✗ docker run -it artisan sh
/ # /bin/artisan
sh: /bin/artisan: not found
现在将图像库更改为phusion/baseimage:
➜ docker git:(master) ✗ cat Dockerfile
#FROM docker:1.10
FROM phusion/baseimage
COPY build/ /
➜ docker git:(master) ✗ docker build -t artisan .
Sending build context to Docker daemon 10.15 MB
Step 1 : FROM phusion/baseimage
...
➜ docker git:(master) ✗ docker run -it artisan sh
# /bin/artisan
08:16:39.424 [ERROR] artisan: need a command, one of server, provision or build
默认情况下，如果使用net包，则构建可能会生成具有一些动态链接的二进制文件，例如到libc。您可以通过查看ldd output.bin 的结果来动态检查与静态检查链接
我遇到了两种解决方案：
- 通过
CGO_ENABLED=0禁用CGO - 强制使用网络依赖关系的Go实现，netgo通过
go build -tags netgo -a -v，这是针对特定平台实现的
发件人https://golang.org/doc/go1.2:
默认情况下，net包需要cgo，因为主机操作系统通常必须调解网络调用设置。不过，在某些系统上，可以在没有cgo的情况下使用网络，这样做很有用，例如可以避免动态链接。新的构建标记netgo（默认为off）允许在可能的情况下在那些系统上以纯Go构建网络包。
以上假设唯一的CGO依赖项是标准库的net包。
我在go二进制文件中遇到了同样的问题，在将其添加到我的docker文件中后，我使其工作起来：
RUN apk add --no-cache libc6-compat
我的诀窍是在链接器选项中启用静态链接：
$ go build -ldflags '-linkmode external -w -extldflags "-static"'
-linkmode选项告诉Go使用外部链接器，-extldflags选项设置要传递到链接器的选项，-w标志禁用DWARF调试信息以提高二进制大小。
请参阅go tool link和静态编译的Go程序，即使使用cgo，也始终使用musl有关更多详细信息，
Go编译器可能会将二进制文件与Alpine中不同位置的库链接起来。在我的例子中，它是在/lib64下使用依赖项编译的，但Alpine不使用该文件夹。
FROM alpine:edge AS build
RUN apk update
RUN apk upgrade
RUN apk add --update go=1.8.3-r0 gcc=6.3.0-r4 g++=6.3.0-r4
WORKDIR /app
ENV GOPATH /app
ADD src /app/src
RUN go get server # server is name of our application
RUN CGO_ENABLED=1 GOOS=linux go install -a server
FROM alpine:edge
WORKDIR /app
RUN cd /app
COPY --from=build /app/bin/server /app/bin/server
CMD ["bin/server"]
我正在写一篇关于这个问题的文章。您可以在此处找到此解决方案的草稿https://kefblog.com/Post/2017-07-04_golang-in-docker-without-disabling-cgo-on-alpine。
在debian docker容器内执行go二进制文件时，面临以下问题：/bin/bash: line 10: /my/go/binary: No such file or directory
二进制文件是通过在docker（dind）中使用docker从高山容器中使用命令构建的：GOOS=linux GOARCH=amd64 go build
在构建二进制文件时使用以下env修复了此问题：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build
我有一个需要CGO_ENABLED=1的应用程序。
我在debian瘦容器中运行编译后的go二进制文件的修复方法是使用RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=1 go build -o goapp 构建二进制文件
并在debian slim 中运行以下命令
RUN apt-get update && apt-get install -y musl-dev
RUN ln -s /usr/lib/x86_64-linux-musl/libc.so /lib/libc.musl-x86_64.so.1
让我能够在之后运行山羊膏
提示：ldd goapp显示容器中缺少libc.musl-x86_64。
这个问题的原因是alpine映像使用musl-libc，而cgo编译的二进制程序依赖于gnu-libc，因此会存在兼容性问题。您可以使用ldd命令来查看二进制文件所依赖的动态库。
root# ldd main
!10807
linux-vdso.so.1 (0x00007ffea7fab000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f7b1f818000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7b1f5f9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7b1f208000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7b1fa32000)
有一些方法可以解决这个问题，go构建将CGO_ENABLED设置为0。
env CGO_ENABLED=0 go build -o main main.go
此外，如果你坚持使用cgo来编译程序，你可以使用frolvlad/alpine glibc作为基础映像来解决这个问题。
FROM frolvlad/alpine-glibc
WORKDIR /hello
COPY . .
CMD ["./main"]
希望它能帮助你。