root@5683d551b36518:/myapp# printenv DATABASE_URL
file:/data/sqlite.db
root@5683d551b36518:/myapp# ls /data
lost+found
So this line in the dockerfile was suspect:
ENV DATABASE_URL=file:/data/sqlite.db
I tried changing it to file:/myapp/dev.db because that file actually exists inside the docker container. But alas, that didn’t solve my problem either.
I encounted this error so I changed the vite port to 8080.
Now I’m back to the health check failing
So then I got thinking: why is dev.db in the root myapp? I looked in /myapp/prisma and there’s also a dev.db file there Y tho? I changed the db url to point to it but that didn’t do anything for me either.
For context, I have successfully deployed a remix app (just a demo, so nothing complicated) using both the Dockerfile provided by the indie stack and the one that we will generate using either fly launch or the dockerfile generator. I also see from our logs that other people have successfully run fly launch with remix applications.
And while I know fly and dockerfiles and node, my knowledge of remix is limited and my knowledge of your app is zero.
With that out of the way, if you are using sqlite3, you will want the database to stay around between deploys, so you will want it on a volume. /data/ looks right and you finding lost+found there is also a good sign as such directories are created on each new volume.
Assuming that your prisma/schema.prisma contains:
datasource db {
provider = "sqlite"
url = env("DATABASE_URL")
}
The next step is to verify that the startup of your server causes the following to be run:
npx prisma migrate deploy
What do the ENTRYPOINT and CMD look like in your Dockerfile? What script do they run, and does that script run the command listed above?
Okay, I’m more of a frontend dev so I was a bit confused about persistent storage but I came to understand that I do have a volume named data and it is getting mounted in the data dir. Note that the example I’m using is public so you can take a look at the dockerfile here: test-indie-stack/Dockerfile at main · justin-hackin/test-indie-stack · GitHub .
On thing I noticed about the dockerfile from npx --yes @flydotio/dockerfile@latest --force is that it had 3 slashes following file: and everywhere else only had 1 so I changed it but that didn’t help either. The entrypoint file can be seen here: test-indie-stack/docker-entrypoint.js at main · justin-hackin/test-indie-stack · GitHub and I added a log that confirms that migrate is running in entrypoint but it doesn’t show up anywhere I guess because it’s outside the docker container.
However, I was able to confirm that the bad db url was the source of problem because I see
2024-04-01T13:52:10.496 app[9080e339b75748] yyz [info] Prisma schema loaded from schema.prisma
2024-04-01T13:52:10.502 app[9080e339b75748] yyz [info] Datasource "db": SQLite database "sqlite.db" at "file:/data/sqlite.db"
2024-04-01T13:52:10.545 app[9080e339b75748] yyz [info] 1 migration found in prisma/migrations
2024-04-01T13:52:10.548 app[9080e339b75748] yyz [info] No pending migrations to apply.
However, the app still didn’t work because of an invariant error. It didn’t print the env var but it was obvious from the code I forgot to add a SESSION_SECRET. Adding it, the app still hangs.
Finally, the fly.toml file had the wong internal port so I set it to 3000.
2024-04-01T14:20:15.573 app[9080e339b75748] yyz [info] > start
2024-04-01T14:20:15.573 app[9080e339b75748] yyz [info] > remix-serve ./build/index.js
2024-04-01T14:20:15.974 app[9080e339b75748] yyz [info] [remix-serve] http://localhost:3000 (http://172.19.17.42:3000)
2024-04-01T14:20:16.066 proxy[9080e339b75748] yyz [error] failed to connect to machine: gave up after 15 attempts (in 8.156592822s)
I was pretty confused about the port mapping (80) to the internal port so I added :80 to the app url and the app actually showed up instead of the connection hanging So then I noticed the fly.toml was forcing https and I assumed the project wasn’t supporting that since it didn’t even have a vite config. Setting both of the force_https in the file to false solved the issue. Thanks a lot for your support @rubys . It meant a lot because this has been one of the most frustrating devops experiences I’ve ever had with a basic example setup.
Cool. Now that you have it working, you should be able to enable https as that is something that fly.io will automatically take care of for you, if you configure it correctly in your fly.toml.
These deploys seem really flakey. One time I only just changed the prisma schema to use the DATABASE_URL env var and the building of the images fails:
Waiting for remote builder fly-builder-delicate-morning-2685...
Remote builder fly-builder-delicate-morning-2685 ready
Error: failed to fetch an image or build from source: Get "http://fdaa:9:cc4:a7b:ef:1425:7442:2:8080/flyio/v1/extendDeadline": connect tcp [fdaa:9:cc4:a7b:ef:1425:7442:2]:8080: connection was refused
Error: Process completed with exit code 1.