Deploy-ready image

[pedrolucasp]

The current version of the containerized application is not suitable for deployment. We need a better, more suitable image for deploying. It might even be wise to generate one and push it into a container registry. Multi-staged builds are already being used on our Dockerfile, which is a nice step ahead.

[tbergmueller]

From @pedrolucasp via Slack:

Oh yeah, just one last thing, I'm a bit concerned with our deploy-ready image, since it shouldn't do much other than build the application and that's it. Migration shouldn't even be happening on the npm start command, as that step should happen during the deploy of the new version. So ideally, the steps should be more or less:
- New version is tagged, kicks off a CI build which builds the image and drops it on some container registry
- Enters into a pipeline where it tells to pull that image some place (it depends here on the infra you'll use)
- Runs the migrations against the production/staging DB
- If all went well, spin everything up
- If the migrations failed, abort everything

[tbergmueller]

From #40

I'd suggest to:

• First move the application's code out of /srv, so that there is clean separation between code (read-only) and data (read-write). FHS standard places would be /opt/digitalsoul (if node_module contains architecture-specific stuff) or /usr/share/digitalsoul/app (if it's 100% interpreted code).
• Cosmetic, adding to the previous point: Move /srv/app/nftdata one folder up (can be done by editing the deployment yaml)
• Create a routine that runs regularly and deletes tmp files older than say 24h from the temp folder
• Ensure that the folder name of .next is user-controllable, e.g. through an env var
• If the contents of .next need to be persisted or if they are large, then also place it into the nftdata folder by setting the env var. Ensure that user uploads live in a separate folder and cannot collide with application-internal data.

[tbergmueller]

From #41 : consider builder and runner targets; can we clean up the .next/cache linking to just have it in runner and maybe also use the runner during docker-compose (which is development)