-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: docs - Docker node:16-alpine requires setting engineType = "binary"
for Prisma to work
#975
Comments
Seems like it might be related to this? prisma/prisma#16205 Seems like it can be "fixed" by using If so I would recommend putting this in the docs as a temporary solution, and then keeping an eye on it as hopefully there will be a better solution soon. |
Hi @c-ehrlich, I think you're right! Setting |
@nicolomaioli hi, how can I set |
Change this line in the
Edit: I believe Alpine 3.17 uses v3 of openssl, which is why you need to specify 1.1. The |
Thank you @nicolomaioli , it works! Using |
@c-ehrlich I'd be happy to raise a PR for the documentation if that's helpful, I haven't contributed before but it seems straightforward enough |
First time contributions are always welcome, especially after opening such a thorough issue :) Just so I understand correctly:
If so I'm not sure what the best thing is to recommend. What do you (and everyone else) think is the best short-mid term solution here? |
Thanks @c-ehrlich happy to take a shot at this. Debian Buster also works without setting engineType to binary, so that might be the simplest fix and most straightforward recommendation. I need to play around with Buster slim as that would be a better replacement for Alpine. We could add a paragraph for Alpine, and explain the trade-offs (size, performance, security), I think there’s enough to unpack there. I’m a little wary about polluting the docs though, so open to suggestions. It’s worth mentioning that Alpine 3.16 won’t reach EOL until mid-2024, so it still receives security patches. Also I would argue that the real issue there is Prisma’s lack of support for OpenSSL past v1.1. Finally, we should consider how to best track the open issue on Prisma. Not sure what the best approach is here, maybe leaving an open issue to track? |
Prisma queries were failing with errors like this: ``` Error: Invalid `prisma.$queryRaw()` invocation: Unable to load Node-API Library from /workspace/node_modules/.prisma/client/libquery_engine-linux-musl.so.node, Library may be corrupt ``` The culprit was that the `node:14-alpine` Docker image that Hub runs on was [updated](https://github.com/yobasystems/alpine/blob/935827272dfe303a11b870e61a00b25f1a6d938e/CHANGELOG#L21) and OpenSSL 3.0 became the default. This adapts a fix mentioned [here](t3-oss/create-t3-app#975 (comment)), but we wanted to be able to stay on `node:14-alpine` (latest) vs having to pin to an older version (3.16 was the working one). This also updates `@prisma/client` to match the `prisma` version to bypass [this error](https://github.com/cardstack/cardstack/actions/runs/3704795929/jobs/6278311091#step:6:20).
Sorry for the delayed reply. I think either of the following is fine:
I'm leaning towards 1, but I'm far from an expert on Docker stuff so feel free to open a PR for whichever you think is the better choice :) |
No worries at all, I've also been a little swamped with the holidays! I agree that Alpine 3.16 is the more reasonable suggestion, especially if the plan is to revise in 6 months. I'll get the PR going! |
Hi, I'm one of the Prisma maintainers. I second what @nicolomaioli has stated here. |
Thanks! When I first tried to get this working with 3.17 I had the listed dependency and still couldn't make it work. I wonder now if the fact that I was using MySQL could have had an impact. I'm happy to do some more digging over the weekend, would it be ok for me to reach out with more findings/questions? |
@nicolomaioli Certo! Feel free to reach out again opening a new Prisma issue, although I think I know why it didn't work initially with |
That's brilliant, thank you! I'll try the different engines should be pretty straightforward. And thanks for reaching out! 🙏 |
@jkomyno thanks for coming in here and clarifying :) @nicolomaioli we are already on Prisma 4.8.0 now so this should hopefully be an easy fix now. If it works for you, would you be up for opening a pr for it? |
Happy to 🙌 |
@jkomyno @c-ehrlich I just managed to run on Alpine 3.17, with Prisma v4.8.0, using the MySQL driver. Note that my AMD laptop is currently out for repair (😢), so I'm running on a MacBook Air M1 using platform
Note the absence of additional dependencies: no I am keen to test this with PostgreSQL and SQLite also, I know very little about MongoDB tho so I could use some pointers to test this quickly. |
This seems great! I just got it running locally (M1 Pro) and can confirm it works. I benchmarked the Docker x64 emulation a while ago and the overhead was something like 5-10% depending on the task. Given how powerful the M1 is I think this is ok for now, and we don't exactly have a good alternative anyway. Re: alpine version: I think it might be better to not pin to 3.17? What do you think? I'm afraid I don't know much about Mongo either as I've never used it outside of toy projects, but
A bigger issue to me is that the existing Docker setup feels like it is specifically for a production setup - multi stage build that only includes the output, not running migrations when the containers come up, etc. However people who deploy dockerized apps in my experience usually also develop in a dockerized environment, so it would be nice to enable that. I had a working dev Docker setup a few months ago (ie optimized for being able to see changes quickly, making schema changes quickly, etc), but it was a completely separate Dockerfile and docker-compose, which afaik isn't really considered best practices anymore (?). It was extremely simple and could be improved upon but I could see if I still have the repo/branch as a starting point. |
That's great! Really good to hear it worked for you as well. I think having a separate Dockerfile and docker-compose is still standard, at least in my experience with Kubernetes. Re Alpine 3.17, I think the advantage there is that it comes with OpenSSL 3x instead of OpenSSL 1.1: @jkomyno please correct me if I'm wrong there, be also good to get your opinion here. |
I definitely agree with 3.17. My question is whether we want to pin to 3.17 or not pin at all, ie automatically use 3.18 once that is released (seems to be a ~6 month version schedule). My general opinion is that if a new version breaks something I'd rather know this sooner than later, but I can also see an argument for pinning to a known working version. Also sorry for editing your post, I clicked the wrong thing and thought I was quoting it 😅 should be back to normal now |
I have to say, I do like the way you think! On one end, I would say that pinning the version is in line with "best practices", and that we can trust the end user to make the right call, so we don't have to come back to this every 6 months. On the other hand, we are pinning the Node version to 16 following similar concerns, so I would say Another option, seeing as calling out to ARG BASE_IMAGE
### BUILDER
FROM --platform=linux/amd64 ${BASE_IMAGE} AS deps
WORKDIR /app
# etc... That way we are explicitly tasking the user with choosing their distribution and Node version. |
Sorry for the late reply, been busy + jetlagged. Thought about it and agree, pinning is fine. I think defaulting to users providing their own base image will cause more support requests than anything else 😅 btw i can't remember if there is any particular reason why we're still on Node 16 other than the Docker docs being undermaintained |
No worries! That all sounds good. I'll take Node 18 Alpine 3.17 for a spin and if everything seems to work well I'll get a PR going in the next few days. I think last time it seemed to work well with updating the code and the English docs leaving the translations untouched, as I will be removing some of the outdated notes. Let me know if that all sounds good with you :) |
Sounds good :) Btw I got a full setup working great on node 18 / alpine 3.17 including next-auth, see here: Still haven't had time to work on creating a good docker dev setup. With the setup above you can run the app non-dockerized in dev without having to change any files, but I know many projects might want their T3 app to be part of a multi-container setup because that's what they're already on, docker internal networking, etc. |
I'm not sure if this is what you are looking for, but I had a setup for this back when I was deploying to Google Cloud Run (have since move to Vercel). I put together a repo here: t3-docker-compose. This leverages extended services with two different
Getting HMR working in docker is a bit of a faff, easiest way is probably Visual Studio Code Dev Containers, for which I have provided a bare-bones implementation. Also, happy to wait for the other PR to drop, let me know what you think @c-ehrlich |
We are building our app with
|
Provide environment information
System:
OS: Linux 6.0 Fedora Linux 37 (Workstation Edition)
CPU: (16) x64 AMD Ryzen 7 PRO 6850U with Radeon Graphics
Memory: 23.97 GB / 30.12 GB
Container: Yes
Shell: 5.9 - /bin/zsh
Binaries:
Node: 16.19.0 - ~/.volta/tools/image/node/16.19.0/bin/node
npm: 8.19.3 - ~/.volta/tools/image/node/16.19.0/bin/npm
ct3aMetadata.initVersion: 6.11.3
Describe the bug
I've added a
Dockerfile
(copy-pasted from the docs, usingnode:16-alpine
as a base image) anddocker-compose.yml
to a freshly bootstrapped app. I modifiedindex.tsx
to runtrpc.example.getAll.useQuery()
, and received this error message at runtime:node:16-buster-slim
(pointing to the Debian engine).node:16-buster
fixes the error.engineType = "binary"
to Prismagenerator client
also fixes the error undernode:16-alpine
.To reproduce
trpc
andprisma
:trpc.example.getAll.useQuery()
toindex.tsx
docker-compose.yml
:docker compose up -d --build
localhost:3000
, then check the logsAdditional information
It's worth noting that setting
engineType = "binary"
is not a recommended approach according to the Prisma docs as it introduces additional overhead in the architecture: Query Engine. If there's a problem with using the Node-API Library in Alpine that seems out of scope for the t3 docs, but might be worth mentioning.The text was updated successfully, but these errors were encountered: