11

I am trying to create the docker image of an app that was developed in Go. I have the binary called myapp, and if I execute it then it work correctly, I execute it with:

./myapp

Then, take that bin and put it alone in a directory called mydirectory and inside I put this dockerfile:

# iron/go is the alpine image with only ca-certificates added
FROM iron/go

WORKDIR /

# Now just add the binary
ADD myapp /

ENTRYPOINT ["./myapp"]

and then I create the docker image by typing:

docker build -t myDockerHubUser/myapp .

Then, when I run the image I get this message:

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

What does it mean? I found some post related with the same message but the thing is that my bnary is executed correctly without any problems

Sredny M Casanova
  • 4,735
  • 21
  • 70
  • 115

3 Answers3

48

You most likely either:

  • use the binary for the wrong platform
  • the binary is not statically linked (has not all the necessary libraries)

You can use CGO_ENABLED=0 to build your binary statically.

Enrico Stahn
  • 2,967
  • 1
  • 23
  • 23
  • 9
    I was running a go binary in an `alpine:latest` container, while the binary was built inside a `golang:1.11` container. Switching the base image for the building container into `golang:1.11-alpine` fixed this issue for me. – ndequeker Mar 15 '19 at 16:05
  • 4
    This ended up being my issue too (https://stackoverflow.com/questions/71262223/why-does-switching-my-docker-base-image-from-distroless-to-alpine-cause-the-erro/71262352#71262352). I was using a multi stage build and didn't get both stages using Alpine-based. One was Debian-based and the other was Alpine-based. When they were in sync, it worked. – Matt Welke Feb 25 '22 at 07:20
  • What does "wrong platform" refer to here? Is it like x86 vs. Arm, or something else? Is Alpine on x86 considered a completely different platform than Debian on x86, and there's something fundamentally different about the binaries besides the libraries they're expected to link to at runtime? – Matt Welke Feb 26 '22 at 01:25
  • I was using ```scratch``` as my second base image in the multi stage build, and changed ```FROM scratch``` to ```FROM alpine:3``` and it worked. – J.E.C. Mar 27 '23 at 18:12
1

You have to build the binary inside docker not in your machine. 

FROM golang

ADD ./ /go/src/app

WORKDIR /go/src/app

RUN go get ./

RUN go build

CMD app
Mostafa Solati
  • 1,235
  • 2
  • 13
  • 33
  • Do note that this produces a *much* bigger image than if you add a statically compiled binary to a small (if not empty) base image. – Peter Mar 03 '18 at 08:34
  • @PeterYes you're right but disk space is cheapest resource in the server , this method makes deployment and further changes easier on the run. you can fetch latest changes from git and rebuild the image instead of uploading a huge binary in every change. – Mostafa Solati Mar 03 '18 at 08:42
  • 1
    It's not about disk space, it's about network traffic in my experience. Launching a 15MB image with one or two layers is orders of magnitude faster than a 300MB image with tens of layers. – Peter Mar 03 '18 at 10:43
  • 2
    Just use a multi-stage Dockerfile. You can push the last image. – Fabian Feb 14 '19 at 19:30
  • This answer doesn't address OP's original issue. It's true that they can leverage multi stage builds and get benefits from that, but their issue right now is just about how t run a built binary. It isn't relevant how the binary is built. – Matt Welke Feb 25 '22 at 07:15
-3

Inside the container /myfile doesn't have the permission for execution. You have to do a chmod +x /myfile inside the dockerfile. Just add following statement before ENTRYPOINT line.

RUN chmod +x /myfile

MB11
  • 610
  • 1
  • 5
  • 16