Docker alpine部署go项目失败分析

Jan 23, 2017 · 1 min read [ golang docker ]

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

详细错误记录：

➜  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镜像编译的确不行，对比编译后的文件发现有猫腻。

> 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:

> 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上不支持。

总结

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

参考：Linking golang statically