"no binary found" using Docker example

[mjlangan]

I'm trying to package my application into a Docker image following the guide here: https://goprisma.org/docs/reference/deploy/docker#optimized-dockerfile

The image builds fine, but when I run I get (pardon the JSON-formatted log output):

{"level":"fatal","msg":"error connecting to database: ensure: no binary found","time":"2024-05-03T01:12:54Z"}

I did check for other issues and know this isn't the first issue about this error, but in my case:

• I'm targeting Linux, not Windows
• My code does not call Connect() during any init() functions

Dockerfile looks like this:

FROM golang:1.22.2 as build

WORKDIR /src

# Copy the dependency files and download deps
COPY go.mod go.sum ./
RUN go mod download

# prefetch the prisma binaries, so that they will be cached and not downloaded on each change
RUN go run github.com/steebchen/prisma-client-go prefetch

# copy over everything and rely on dockerignore to filter out the junk
# See https://github.com/docker/docs/issues/14609
COPY ./ ./

# re-run the Prisma generator because it does some magic
ENV PRISMA_GENERATOR_CLIENT go run github.com/steebchen/prisma-client-go
RUN go run github.com/steebchen/prisma-client-go generate

# build the binary for Linux
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -ldflags '-extldflags "-static"' -o app .

# generate the dotenv file
RUN <<EOF cat >> .env

... config-like stuff goes here

EOF

# build the deployment image
FROM scratch

# copy over SSL certificates, so that we can make HTTPS requests
COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt

# copy over the  binary and the .env
COPY --from=build src/app /app
COPY --from=build src/.env /.env

ENTRYPOINT ["/app", "server"]

.dockerignore is filtering out stuff like IDE files, the .git folder, locally-built app binaries on the dev's machine, etc., but I'm also running the generator again so that should be getting whatever binary I need for Linux, right?

[steebchen]

You are probably on an arm Mac, right? I can reproduce, I'll have to look closer into it

[mjlangan]

You are probably on an arm Mac, right? I can reproduce, I'll have to look closer into it

Intel Mac, actually. Though I have teammates with ARM machines.

I forgot to add a step after re-generating the client within the Dockerfile where I move the package to another location (the schema file comes from a git submodule) I added the generated Prisma files to my .dockerignore and included the step to copy them into the right place, and now I get a different error (progress!)

{"level":"fatal","msg":"error connecting to database: ensure: version check failed: fork/exec /tmp/prisma/binaries/engines/473ed3124229e22d881cb7addf559799debae1ab/unpacked/v2/prisma-query-engine-debian-openssl-3.0.x: no such file or directory","time":"2024-05-03T07:37:54Z"}

I think I recall something about a/tmp folder in another issue, I'll keep poking at this on my end too.

For reference, the "generate" portion of my dockerfile now looks like:

ENV PRISMA_GENERATOR_CLIENT go run github.com/steebchen/prisma-client-go
RUN go run github.com/steebchen/prisma-client-go generate
RUN cp ./prisma/db/* ./database/db
RUN rm -rf ./prisma/db

[mjlangan]

Inspecting the filesystem within the build stage shows I got something generated under /tmp/prisma-binaries, but this path does not match what my application says it's looking for, either.

ls -al
total 16
drwxrwxrwt 1 root root 4096 May  3 07:37 .
drwxr-xr-x 1 root root 4096 May  3 18:29 ..
drwxr-xr-x 1 root root 4096 May  3 00:36 prisma-binaries
cd prisma-binaries
ls -al
total 47052
drwxr-xr-x 1 root root     4096 May  3 00:36 .
drwxrwxrwt 1 root root     4096 May  3 07:37 ..
-rwxr-xr-x 1 root root 22857424 May  3 07:29 prisma-query-engine-linux-static-x64
-rwxr-xr-x 1 root root 25307344 May  3 07:29 prisma-schema-engine-linux-static-x64

[steebchen]

Interesting, as on my M1 mac it actually uses the arm64 binary and there's a different error. Thanks for the report though, I'll have to look closer into it when I have some time. For now as a temporary workaround please use a single-stage build then it will work fine