Home > Software engineering >  Unable to exec -it into the container
Unable to exec -it into the container

Time:12-12

FROM golang:1.13.8-alpine3.11 as build-env
WORKDIR /app
COPY *.go /app
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o docker-simple-app

FROM scratch
COPY --from=build-env /app/docker-simple-app .
EXPOSE 8000
CMD ["./docker-simple-app"]

Error : OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "-it": executable file not found in $PATH: unknown

CodePudding user response:

FROM golang:1.13.8-alpine3.11 as build-env
WORKDIR /app
COPY *.go /app
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o docker-simple-app

FROM scratch
WORKDIR /app
COPY --from=build-env /app/docker-simple-app .
EXPOSE 8000
CMD ["./docker-simple-app"]

You forgot to specify WORKDIR for scratch/base container

CodePudding user response:

Since the final image is a FROM scratch image, the only thing it contains at all is the /docker-simple-app binary. You won't be able to docker exec anything else, even an interactive shell, because it literally doesn't exist in the image. If you had some way of looking at the filesystem (maybe call os.ReadDir in your application code?) you wouldn't see a /bin or /usr directory the way you might expect; there is no /bin/sh to run.

This is usually fine, especially for a statically-linked Go application: it gives you a very lightweight image (even smaller than Alpine), if you're concerned about an end user reading your code this is the most protection it's possible to have in Docker, and since the image is so simple there's not really anything to debug if it were possible to use docker exec.

If this does matter to you, changing the final image to FROM alpine would give you a shell and a base set of Unix tools, at a small cost in space.

  • Related