Docker alpine部署go项目失败分析

用docker基于alpine微型镜像部署go的项目,启动时报错 panic: standard_init_linux.go:175: exec user process caused "no such file or directory",去年测试docker时遇到过,没去深入研究,这次项目遇又到了,深入分析了一下。

详细错误记录:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
➜  xxx git:(master) ✗ docker run --rm -it xxxx.com/xxx_webapp:prod
panic: standard_init_linux.go:175: exec user process caused "no such file or directory" [recovered]
panic: standard_init_linux.go:175: exec user process caused "no such file or directory"

goroutine 1 [running, locked to thread]:
panic(0x88f8a0, 0xc82011bb20)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
github.com/urfave/cli.HandleAction.func1(0xc8200e72e8)
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:478 +0x38e
panic(0x88f8a0, 0xc82011bb20)
/usr/local/go/src/runtime/panic.go:443 +0x4e9
github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization.func1(0xc8200e6bf8, 0xc82001a0c8, 0xc8200e6d08)
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:259 +0x136
github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization(0xc820051630, 0x7fc3c9efc728, 0xc82011bb20)
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:277 +0x5b1
main.glob.func8(0xc82006ea00, 0x0, 0x0)
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/main_unix.go:26 +0x68
reflect.Value.call(0x7f45a0, 0x9a4d88, 0x13, 0x8ebac8, 0x4, 0xc8200e7268, 0x1, 0x1, 0x0, 0x0, ...)
/usr/local/go/src/reflect/value.go:435 +0x120d
reflect.Value.Call(0x7f45a0, 0x9a4d88, 0x13, 0xc8200e7268, 0x1, 0x1, 0x0, 0x0, 0x0)
/usr/local/go/src/reflect/value.go:303 +0xb1
github.com/urfave/cli.HandleAction(0x7f45a0, 0x9a4d88, 0xc82006ea00, 0x0, 0x0)
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:487 +0x2ee
github.com/urfave/cli.Command.Run(0x8ee970, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x984240, 0x51, 0x0, ...)
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/command.go:191 +0xfec
github.com/urfave/cli.(*App).Run(0xc820001500, 0xc82000a100, 0x2, 0x2, 0x0, 0x0)
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:240 +0xaa4
main.main()
/tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/main.go:137 +0xe24

首先确认被执行的程序都是存在的,经过一番搜索测试也没解决。

之前用GOOS=linux GOARCH=amd64 go build是可以的,这次是通过golang的docker镜像编译的确不行,对比编译后的文件发现有猫腻。

1
2
3
> GOOS=linux GOARCH=amd64 go build
> file xxx
xxx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

vs docker build:

1
2
3
> docker run --rm -it -v $GOPATH:/go golang:1.7 bash -c 'cd $GOPATH/src/xxx && go build
> file xxx
xxx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

问题找到了,一个是静态链接,一个是动态链接,动态链接的在微型镜像alpine上不支持。

总结

  1. 默认go使用静态链接,在docker的golang环境中默认是使用动态编译。
  2. 如果想使用docker编译+alpine部署,可以通过禁用cgoCGO_ENABLED=0来解决。
  3. 如果要使用cgo可以通过go build --ldflags "-extldflags -static" 来让gcc使用静态编译。

参考:Linking golang statically