Apple M1上docker-compose启动Prisma/Nexus应用报arm-openssl错误

这个报错是Prisma ORM运行时抛出的逻辑异常，并非Docker与操作系统的底层兼容问题。Prisma运行需要匹配当前运行环境的专属查询引擎二进制文件，匹配维度包含两个核心参数：当前运行的CPU架构、当前环境依赖的OpenSSL版本。

• 报错里的linux-arm代表Prisma初步识别到当前运行环境是Linux下的ARM架构场景（常见于Apple Silicon芯片的Mac本地Docker、ARM架构云服务器）
• 报错里的openssl-undefined代表Prisma在探测容器内的OpenSSL版本时，没有识别到明确的版本标识，既无法匹配官方预打包的对应二进制文件，也没有检测到用户手动提供的自定义二进制，最终直接中断运行

• 容器内基础镜像未做OpenSSL的标准路径软链接，导致Prisma的版本探测逻辑找不到对应的动态库，返回无有效版本的识别结果
• 项目构建时直接复用了宿主机的node_modules目录，容器内拿到的Prisma二进制是匹配宿主机系统的，和容器实际架构不匹配
• 使用的Prisma版本过低，旧版本本身存在ARM架构下OpenSSL版本探测的bug，容易返回undefined的识别结果

• 修复容器内的OpenSSL路径映射
  在Dockerfile的依赖安装阶段，为系统中的libssl、libcrypto动态库创建软链接到系统标准库路径，让Prisma的探测脚本可以直接定位到对应库文件。对于Debian/Ubuntu系的基础镜像，对应可执行如下命令：

  ln -s /usr/lib/*-linux-gnu/libssl.so.3 /usr/lib/libssl.so
  ln -s /usr/lib/*-linux-gnu/libcrypto.so.3 /usr/lib/libcrypto.so
  

  不需要手动指定具体架构的路径，通配符路径可以自动适配x86、ARM的不同架构场景。
• 主动指定Prisma的二进制匹配目标
  跳过Prisma自动探测的环节，在容器的环境变量配置中明确指定当前环境对应的二进制目标。主流的Apple Silicon本地Docker、ARM云服务器的正确目标为linux-arm64-openssl-3.0.x，直接在docker-compose.yml的环境变量段加上：

  PRISMA_QUERY_ENGINE_BINARY=linux-arm64-openssl-3.0.x
  

  注意报错中出现的linux-arm是探测错误生成的无效目标名，主流ARM环境均为arm64架构，不存在通用的32位linux-arm生产场景。
• 调整镜像构建逻辑避免环境错配
  不要在docker-compose配置中将宿主机的node_modules目录直接挂载到容器内，要保证容器构建阶段是在容器内部完成Prisma二进制的安装拉取。构建时可指定Prisma的缓存目录为容器内部的临时路径，避免复用宿主机的缓存内容：

  ENV PRISMA_CACHE_DIR=/tmp/prisma-cache
  

• 升级Prisma到稳定版本
  如果使用的Prisma版本低于4.16，直接升级到当前最新的稳定版即可。旧版本Prisma的跨架构探测逻辑本身存在缺陷，在ARM环境下经常出现OpenSSL版本识别为undefined的问题，这类问题在后续版本中已经完成修复。

内容的提问来源于stack exchange，提问作者cassenav