Golang二进制构建在Docker容器中，仍然是Mach-O可执行格式

Question

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

1. 当运行file命令时，主机上产生的二进制文件（随后复制到第二个容器中）似乎仍然是Mach-O 64位可执行文件。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'

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

Answer 1

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