Docker 容器内构建的 Golang 二进制文件，还是 Mach-O 可执行格式？

Question

我真的需要一些帮助。我想做的是使用标准 golang:1.5 Docker 映像构建 Go 二进制文件，然后将该二进制文件从容器中复制到基于 busybox 的新的最小 Docker 容器中。使用 Docker 安装的卷将二进制文件从容器中拉出。到目前为止，我遇到了两个问题。

1. 运行命令时，主机上生成的二进制文件（随后复制到第二个容器中）似乎仍然是 Mach-O 64 位可执行文件file。Docker 容器是否以某种方式从主机获取 GOOS 和 GOARCH？

2. 当手动运行容器并bash构建 Go 二进制文件时，它现在说它是 ELF 可执行文件，但它是动态链接的。我认为默认情况下构建静态链接的二进制文件？我的这个假设可能是错误的。

预先感谢您可以提供的任何帮助。

编辑：这是我正在使用的命令。希望这能让它更清楚一些

## golang:1.5 base image with WORKDIR set to $GOPATH/src/myproject the source
## for the project was added in when creating the 'mybuild_img' docker image
## GOPATH is set automatically in the golang image.
docker run -i -v `pwd`/jenkins/out:$GOPATH/src/myproject/jenkins/out mybuild_img:latest bash -c 'go build && cp myproject ./jenkins/out'

容器运行完毕后，我在 ./jenkins/out/ 中有一个 Mach-O 64 位可执行文件。我不确定这是否是 docker-machine/boot2docker 或类似行为的某种奇怪行为。只是看起来真的很奇怪。我已经确认，如果我在命令GOOS=linux GOARCH=amd64之前设置go build，那么我确实会得到正确类型的可执行文件。只是想弄清楚这里发生了什么。

Answer 1

看来您仍在绑定某些 C 库。将 Go 可执行文件移动到超最小容器时，这是一个常见问题。go build 您可以通过更改为 将这些绑定库滚动到可执行文件中。 您可以在Codeship 的博客CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .中找到有关此问题的更多信息以及它与最小 docker 构建的关系。