WIP: Dockerize the application

[Maelstromeous]

Closes #2

TODO:

• Test app effectively using a locally hosted version
• Get crons to fire locally

[vercel]

@Maelstromeous is attempting to deploy a commit to the aerotow's projects Team on Vercel.

A member of the Team first needs to authorize it.

[aerotow]

hi @Maelstromeous , thanks for getting this rolling. Is it already working? Or is this a WIP? Would like to not merge to master before this being finished including a tutorial in the main readme

[Maelstromeous]

Hey @aerotow, PR is a draft and is WIP atm :) I'll ping you when it's ready for review. I like doing drafts so people can peer in on what my intent is and offer suggestions. Also I reached out to you in Reddit chat, you probably missed it, can also talk here.

[Maelstromeous]

I was hoping we could leverage some sort of internal cron rather than requiring an external service to do it, but out of scope for this PR.

[aerotow]

Teiggering the api every 30 mins will be critical also in the docker env. Without it, the app basically has no functionality as it then does not change the temperature over time

[Maelstromeous]

I can make it work, but please note #4, it may create two pathways to operating cronjobs, ideally it should be done in the codebase itself with a user defined crontab.

I'm not massively familar with NextJS, I know this is 100% possible in NestJS though (I'm not suggesting we swap to that).

[Maelstromeous]

Currently majorly struggling getting the migrations to run within the container. Banging my head against a wall with this one...

es-app  | > 8@0.2.0 db:generate /app
es-app  | > drizzle-kit generate
es-app  | 
es-app  | No config path provided, using default 'drizzle.config.ts'
es-app  | Reading config file '/app/drizzle.config.ts'
es-app  | 
es-app  | You installed esbuild for another platform than the one you're currently using.
es-app  | This won't work because esbuild is written with native code and needs to
es-app  | install a platform-specific binary executable.
es-app  | 
es-app  | Specifically the "@esbuild/darwin-arm64" package is present but this platform
es-app  | needs the "@esbuild/linux-arm64" package instead. People often get into this
es-app  | situation by installing esbuild on Windows or macOS and copying "node_modules"
es-app  | into a Docker image that runs Linux, or by copying "node_modules" between
es-app  | Windows and WSL environments.
es-app  | 
es-app  | If you are installing with npm, you can try not copying the "node_modules"
es-app  | directory when you copy the files over, and running "npm ci" or "npm install"
es-app  | on the destination platform after the copy. Or you could consider using yarn
es-app  | instead of npm which has built-in support for installing a package on multiple
es-app  | platforms simultaneously.
es-app  | 
es-app  | If you are installing with yarn, you can try listing both this platform and the
es-app  | other platform in your ".yarnrc.yml" file using the "supportedArchitectures"
es-app  | feature: https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures
es-app  | Keep in mind that this means multiple copies of esbuild will be present.
es-app  | 
es-app  | Another alternative is to use the "esbuild-wasm" package instead, which works
es-app  | the same way on all platforms. But it comes with a heavy performance cost and
es-app  | can sometimes be 10x slower than the "esbuild" package, so you may also not
es-app  | want to do that.
es-app  | 
es-app  |  ELIFECYCLE  Command failed with exit code 1.

I've tried every combination I can think of:

• Running the docker-compose service with platform: linux-amd64 and even arm64
• Using FROM --platform=linux/arm64 in the Dockerfile
• Forcing the arch of the build and the platform in the docker-compose file
• RMing the pnpm-lock.yaml file after file copy

I think there's something wrong with the lockfile where it refuses to run under AMD64 images, which is what most people will be running them on servers under.

I may have to build a small pipeline to build both ARM and x64 copies of the image and have docker correctly pick the right one. But, I believe due to the fact in the lockfile it's targeting darwin (arm), it's getting it's knickers proper in a twist.

[Maelstromeous]

Nvm realised what I was doing... I was volume mounting the container's /app directory with the local directory, done that so many times in app development in the past I totally didn't realise I was effectively re-mounting node_modules despite building them in the image.

I may need more sleep.

[Maelstromeous]

Current challenge is now to swap out the Vercel postgres driver to use a local postgres database connection. It appears it is not a simple process as it really should be. Reading this thread, I'm not the only one who's hit this issue.

Unless there's a simplistic way of resolving that after a recharged brain tomorrow, I may abandon this.

[Maelstromeous]

@aerotow Got it into a state now where the app will run the migrations and effectively talk to the database without any errors.

However, when I run the app locally, even with pnpm dev it hangs when attempting to log in with my Eightsleep creds. Can you offer any insights on how to debug this?

You should be able to replicate it by simply doing a git pull on my branch and running docker compose up -d then visiting http://localhost:3000.

[Maelstromeous]

I've narrowed it down to saving the EightSleep tokens to the database, will investigate further. There's a network timeout.

[Maelstromeous]

Now more properly swapping out the database client for a local postgres version for Drizzle. Apologies for the verbosity!

TODO:

• Test app effectively using a locally hosted version
• Get crons to fire locally