flyctl: Can't deploy with prisma
I’m not sure where the issue lies between prisma and fly.io, so I’ve opened issues in both repos hoping somebody has a clue about what might be happening 🥴
Prisma has a postinstall script that runs after npm install, for whatever reason it’s hitting an EOF error (and I don’t know which file).
Here’s a little repo to reproduce: https://github.com/ryanflorence/fly-prisma
The app runs fine locally, here’s the output from the deploy after Node.js is installed and it runs npm install:
[Parsing package.json]
[INFO] Parsing package.json
[INFO] Using npm v6.14.12 from Node
[INFO] Installing node modules from ./package-lock.json
> prisma@2.21.2 preinstall /workspace/node_modules/prisma
> node scripts/preinstall-entry.js
> @prisma/engines@2.21.0-36.e421996c87d5f3c8f7eeadd502d4ad402c89464d postinstall /workspace/node_modules/@prisma/engines
> node download/index.js
> prisma@2.21.2 install /workspace/node_modules/prisma
> node scripts/install-entry.js
> @prisma/client@2.21.2 postinstall /workspace/node_modules/@prisma/client
> node scripts/postinstall.js
Prisma schema loaded from prisma/schema.prisma
Error executing lifecycle: unexpected EOF
fly.toml
My fly.toml is the default from fly launch
# fly.toml file generated for solitary-wave-5918 on 2021-04-25T19:56:40-06:00
app = "..."
kill_signal = "SIGINT"
kill_timeout = 5
[build]
builder = "heroku/buildpacks:20"
[env]
PORT = "8080"
[experimental]
auto_rollback = true
[[services]]
http_checks = []
internal_port = 8080
protocol = "tcp"
script_checks = []
[services.concurrency]
hard_limit = 25
soft_limit = 20
type = "connections"
[[services.ports]]
handlers = ["http"]
port = 80
[[services.ports]]
handlers = ["tls", "http"]
port = 443
[[services.tcp_checks]]
grace_period = "1s"
interval = "15s"
restart_limit = 6
timeout = "2s"
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 39 (17 by maintainers)
You can pass that as a build arg:
fly deploy --build-arg PRISMA_SKIP_POSTINSTALL_GENERATE=true.You can also change the fly.toml build block to:
It works for me now - thanks so much for staying on this @jeromegn.
Here is my update (and close) of the Prisma side issue: https://github.com/prisma/prisma/issues/6779#issuecomment-834649804
Ok I’ve been playing with changes to our remote builder and am able to keep the connection alive by writing periodically to prevent it from becoming idle.
However, things are not quite progressing. It hangs forever (well, as long as my patience allowed) during
Prisma schema loaded from prisma/schema.prisma.I SSHed into the builder and saw a process using 100% CPU:
stracereveals it’s stuck at:epoll_wait(13,, not doing anything else.I also tried the sample code from this guide: https://www.prisma.io/docs/guides/deployment/deployment-guides/deploying-to-heroku
I was able to deploy to heroku no problem in a timely fashion. Trying to deploy the same exact code didn’t work on us and was instead stuck at
[INFO] Installing node modulesA slightly different process was hanging in the remote builder:
straceshowed the sameepoll_wait(13,hanging.I’m starting to think something is wrong with the buildpack here, or at least with our use of the buildpack.
Ah, I think this is different from the other issue! I’ll keep looking into it. I think this is the idle timeout from our proxy being reached on the connection.
I was testing with
Without I also see the EOF.
I tweaked our remote builders quite a bit and was able to deploy this with both the buildpack and the Dockerfile from the example repo.
Until we change this for everybody, if you want to try the new builder you will have to destroy your current builder with
flyctl apps destroy fly-builder-.... Then you can start a new build.However, it looks like there’s another issue? I don’t think it’s a build-time problem though.
The simple workaround is to install and run docker locally, then run
fly deploy --local-onlyto force its use. This should work really well until we get our remote builder EOFs tracked down.I phrased that badly! The example uses express, which needs to listen on 0.0.0.0. It’s actually configured here: https://github.com/ryanflorence/fly-prisma/blob/main/server.js#L14
We health check the app port to determine whether we can send traffic to it. So the instances are coming up and running just fine, we just stop them because we’re unable to connect. You can remove the entire
[[services]]definition in your fly.toml to disable our external load balancer and turn off this check for simplicity.We think we figured out the issue. It wasn’t really prisma related, it was a problem with high IO load and the encrypted volumes we use for remote Docker daemons. It seems to manifest when there’s a lot of disk activity involved in a build. Heroku’s buildpack + Node is worst case for this.
We should have a fix out today!
Thanks for the debug tip:
Mine get’s hung up on this last line, I’m going on like 10 minutes waiting for it: