Go编译的二进制文件不会在Ubuntu主机上的高山docker容器中运行

时间:2016-03-29 08:34:29

标签: go docker busybox alpine

给定一个二进制文件,使用Go编译,使用GOOS=linuxGOARCH=amd64,基于docker部署到alpine:3.3容器,如果docker引擎主机,二进制文件将无法运行是Ubuntu(15.10):

sh: /bin/artisan: not found

如果docker引擎主机busybox(这是alpine的基础)部署,那么相同的二进制文件(针对相同的OS和arch编译)将运行得很好在Mac OS X上的VirtualBox VM中。

如果容器基于Ubuntu映像之一,那么同样的二进制文件也会运行得很好。

知道这个二进制文件丢失了吗?

这是我为重现而做的(在OS X上的VirtualBox / busybox中成功运行未显示):

构建(即使拱门匹配,也使用标记显式构建):

➜  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 

6 个答案:

答案 0 :(得分:50)

默认情况下,如果使用net包,则构建可能会生成带有一些动态链接的二进制文件,例如到libc。您可以通过查看ldd output.bin

的结果来动态检查静态链接

我遇到过两种解决方案:

  • 通过CGO_ENABLED=0
  • 停用CGO
  • 强制使用网络依赖关系的Go实现,netgo通过go build -tags netgo -a -v,这是针对某些平台实现的

来自https://golang.org/doc/go1.2

  

默认情况下,网络包需要cgo,因为主机操作系统通常必须调解网络呼叫设置。但是,在某些系统上,可以使用没有cgo的网络,这样做很有用,例如避免动态链接。新的构建标记netgo(默认情况下是关闭)允许在可能的系统上使用纯Go构建网络包。

以上假设唯一的CGO依赖是标准库的net包。

答案 1 :(得分:35)

我在使用go二进制文件时遇到了同样的问题,并且在将其添加到我的docker文件后我开始工作了:

RUN apk add --no-cache \ libc6-compat

答案 2 :(得分:6)

从您的构建机器开始编译器可能会将您的二进制文件链接到与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"]

我正在处理有关此问题的文章。您可以在http://kefblog.com/2017-07-04/Golang-ang-docker找到此解决方案的草稿。

答案 3 :(得分:1)

我有一个需要 CGO_ENABLED=1 的应用。

在 debian-slim 容器中运行编译好的 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

让我能够在之后运行 goapp

提示:ldd goapp 显示容器中缺少 libc.musl-x86_64。

答案 4 :(得分:0)

对我来说,窍门是在链接器选项中启用静态链接:

$ go build -ldflags '-linkmode external -w -extldflags "-static"'

-linkmode选项告诉Go使用外部链接器,-extldflags选项设置要传递给链接器的选项,-w标志禁用DWARF调试信息以提高二进制大小。 / p>

有关更多详细信息,请参见go tool linkStatically compiled Go programs, always, even with cgo, using musl

答案 5 :(得分:0)

在debian docker容器中执行go二进制文件时,遇到此问题: /bin/bash: line 10: /my/go/binary: No such file or directory

二进制文件是通过使用以下命令从高山容器中使用docker-in-docker(dind)构建的: GOOS=linux GOARCH=amd64 go build

在构建二进制文件时使用以下env修复了该问题: CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build