8

I am really not familiar with docker, but I'm using docker to run a web app, which uses prisma/nexus

When I try to compose up, I get this error:

 Error: Unknown binaryTarget linux-arm-openssl-undefined and no custom binaries were provided

Can someone tell me what this error means, and how can I solve it? I think it has to do with the fact that docker doesn't support the OS that I'm working on, but I'm not entirely sure.

David Maze
  • 130,717
  • 29
  • 175
  • 215
cassenav
  • 113
  • 2
  • 4
  • Does this answer your question? [Docker image run in m1 processor](https://stackoverflow.com/questions/66456627/docker-image-run-in-m1-processor) – jordanvrtanoski Mar 08 '21 at 13:58

6 Answers6

12

Undefined means you don't have openssl installed in the container. You can get correct binary target name by installing openssl. Add this to Dockerfile:

FROM node:16-slim
RUN apt-get update
RUN apt-get install -y openssl

Answer from here https://github.com/prisma/prisma/issues/861#issuecomment-881992292

Aleksandr Khaustov
  • 366
  • 2
  • 5
  • 1
    This is the right answer. Installing Prisma on `alpine` is broken no matter what packages you install with `apk`. Using `slim` and installing `openssl` seems to fix it. – TeemuK Aug 26 '22 at 09:45
10

From the official docs,

Prisma Client consists of three major components.

  • JavaScript client library
  • TypeScript type definitions
  • A query engine (in the form of binary file)

While the generated code is cross platform (this is javascript), the query engine is not.

When you run the prisma generate command, prisma seems to uses the query engine, but it needs to find the proper binary for the current platform otherwise it throws an error.

The problem is for some reason I cannot explain (because I am having the same problem) the platform within the docker is not recognized as a supported platform one.

My guess is either docker is providing the wrong platform or there is a bug in prisma at some point, the error message linux-arm-openssl-undefined with undefinedin it could possibly be a clue of the problem.

Solution: Right now: I plan running my images on an x86 computer the time for this issue to be fixed. The latest docker 3 RC2 (released 5 days ago) did not help neither.

Note that you can specify binaryTargets into the schema.prisma file.

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["debian-openssl-1.1.x"]
}

But for some reason, and even if I am building my docker image on top of a debian, this does not work. Prisma seems to recognize I am on linux-arm but is unable to associate a binaryTarget to. Also… is this platform really accurate ? Is docker running an linux arm under the hood or an x86 debian under rosetta ? I've no idea.

[EDIT] node images are Multi-Arch, meaning

FROM node:15.12.0-buster-slim AS builder

Will pick the linux architecture for my host platform (linux/arm64/v8) It seems we can actually build for x86 on m1 using buildx experimental feature according to this post

Flavien Volken
  • 19,196
  • 12
  • 100
  • 133
2

This can also mean that the image you're using in your Dockerfile (FROM node:16-alpine for example) are NOT available for ARM.

Most (if not all) images are available for x86 [x86_64|amd64] architecture, but not all of them are available for ARM. You can check this in the image repository (ex.: https://hub.docker.com)

As you're building your image on your M1 Mac (with an ARM CPU) Docker guesses that you want an image built for ARM. That may be your case.

But for the OP I think this is probably not the case and he/she is targeting the built image to be run remotely in a cloud Linux server, which as of today are mostly x86 [x86_64|amd64] machines.

If that's your scenario and you want images to be built for x86 [x86_64|amd64] instead, you can specify the architecture in your Dockerfile FROM entry (or entries for multi-stage) and add them an argument specifying the architecture.

So, instead of

FROM node:16-alpine

do this

FROM --platform=linux/amd64 node:16-alpine

note: make sure to replace ALL entries if your Dockerfile is multi-stage (i.e.: has many FROM entries)

This will make the image to be built and target x86 instead of ARM despite what CPU your M1 Mac has, which I think it was OP's goal.

  • The built image will be compatible and will run at native speed in target x86 servers
  • You can still run these images locally thru Docker for Mac via Rosetta2 x86 emulation (although somewhat slower) on your M1 Mac for Development or Debugging/Diagnostics purposes.
David Camarena
  • 160
  • 5
1

I had the same issue when using node:alpine. First I tried to install manually openssl with apk add openssl but there were still some other issues raising.

I managed to solve it by switching to node:lts and adding to my Dockerfile RUN apt-get -qy update && apt-get -qy install openssl

Maka
  • 29
  • 2
  • Thanks this solution worked for me even though I am running a Macbook Air M1. Changing `alpine` to `lts`and `apk` to `apt-get` fixed the issue. – Renaud Dec 15 '21 at 16:32
  • Glad to hear it ! I am on a Macbook M1 as well – Maka Dec 16 '21 at 17:18
0

Change the your base image from alpine to node this should fix the issue you are facing on M1. More information on this thread thread

shadrack Mwangi
  • 785
  • 6
  • 14
0

For me what works was mixed with some answers below.

For the container that was installing and generating Prisma I made this change:

# FROM node:fermium-alpine3.16 AS deps
FROM node:16-slim AS deps
RUN apt-get update
RUN apt-get install -y openssl libssl-dev

And for the container that runs, I made it:

# FROM node:fermium-alpine3.16 AS runner
FROM --platform=linux/amd64 node:fermium-alpine3.16 AS runner

Thanks, everyone for the answers. I hope it helps someone else.

Rodrigo Cipriani da Rosa
  • 316
  • 3
  • 4