0

I'm building a multistage Docker image of a golang microservice and I want to make it very thin using busybox as base image to run the final executable. The image is correctly built, but when I run it I get this error:

standard_init_linux.go:211: exec user process caused "no such file or directory"

I'm working on my Ubuntu laptop, so this error has nothing to do with the Windows OS as many other questions report.

This is my image.

# build stage
FROM golang:1.15.3 AS build-stage

RUN mkdir /build
ADD . /build/
WORKDIR /build

RUN go mod download
RUN go test ./...
RUN go build -o goapp .

# final stage
FROM busybox
WORKDIR /app
COPY --from=build-stage /build/goapp /app/

CMD ["./goapp"]

A very simplified version of my project folder could be:

project
├── Dockerfile
├── go.mod
├── go.sum
├── main.go
└── other-packages
Alessandro Argentieri
  • 2,901
  • 3
  • 32
  • 62

2 Answers2

1

You are building your app with CGO_ENABLED=1 (this is Go's default setting for builds) - and transplanting that executable to a docker image where there is no compatible library support (glibc, dns resolver etc.).

To ensure your build does not rely on any external libraries - statically binding all dependencies - and can then be deployed to a SCRATCH docker image or busybox - disable CGO during your build phase:

RUN CGO_ENABLED=0 go build -o goapp .
colm.anseo
  • 19,337
  • 4
  • 43
  • 52
  • after having applied your changes I get this: COPY failed: stat /var/lib/docker/overlay2/c989081c12b1f7b2a976bbf0a6848d48a929550d104b5ca6238758b5651394bc/merged/goapp: no such file or directory – Alessandro Argentieri Nov 16 '20 at 16:06
  • the `COPY` looks correct. Maybe something is up with your `docker` cache. Try adding the `--no-cache` to your `docker build` command. – colm.anseo Nov 16 '20 at 16:37
0

I guess there's a difference between the libc of the two images. As introduced in description of busybox image, there are several libc variants, which is distinguished by image tags.

The libc of golang:1.15.3 is glibc (it is FROM the corresponding version of debian:buster), so you should use busybox:glibc on your final stage.

The default busybox:latest is using uclibc. They are incompatible. Check the sha256 digest of busybox:latest and busybox:uclibc.

Flying onion
  • 126
  • 7