4

我真的可以在这里使用一些帮助。我想要做的是使用标准的 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，那么我会得到一个正确类型的可执行文件。只是想弄清楚这里发生了什么。

4

1 回答 1

2

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

于 2015-11-06T13:50:10.910 回答