Added support for running node server in Docker

[m0ngr31]

Scope

This is the initial work to allow a user to run the server in a Docker/Podman container. This can be automated with Github Actions to deploy images to Docker Hub or GHCR automatically on release.

Would be a big help for those of us who run all self-hosted software on a dedicated server.

Once this is approved, it'd be willing to help with adding instructions so that it's easy to run for people. I can also help getting the Github actions setup (for autopublishing and multi-arch build).

Test Plan

I've run this locally and it seemed to work okay. I just discovered this project yesterday so I'll need to put it through its paces more

Checklist

• I have run Prettier to reformat any changed files
• I have verified my changes work

[RDIL]

Thanks for this!! Been meaning to add a Docker setup for a while.

[RDIL]

Since we have multiple things which will need to be persisted between container restarts (userdata, contractSessions, contracts, options.ini, etc), maybe we just make the working directory a volume?

[m0ngr31]

The idea of this was to copy what was needed into volume being passed in at runtime for persistent data. So you'd pass in like: -v ./config:/app as part of your Docker start command.

Ideally we could update the server with an environment variable or something so that persistent data could go into a custom directory

[AnthonyFuller]

Personally, I think it'd be great to have a Docker container for Peacock. I have a few issues with what you've done:

• Installing node from a package manager does not guarantee that it is our required node version (see .nvmrc).
• It should not be doing a build step, it should be using the linux version of a release (needs to be a known build and then we can release containers for each version).
• There is no way to configure options.ini or to control the volume (granted this partly requires some Peacock changes, which now that I think about them, are not a bad idea).

[m0ngr31]

* Installing node from a package manager does not guarantee that it is our required node version (see `.nvmrc`).

You're totally correct about this. I will modify that.

* It should not be doing a build step, it should be using the linux version of a release (needs to be a known build and then we can release containers for each version).

If this is automatically run on an action as part of a release, wouldn't it end up being the same either way? I can try and familiarize myself with your actions and see if I can make it work like this from the build artifacts?

* There is no way to configure `options.ini` or to control the volume (granted this partly requires some Peacock changes, which now that I think about them, are not a bad idea).

That's where documentation would come in. With the current setup, it's building everything in /app_build and then at runtime it's copying that into /app which would be mounted as a volume when you're running the container. If the persistent data could be configured to a different directory we could skip that step

[m0ngr31]

@AnthonyFuller @RDIL

Okay, I've updated the container build to use the artifact created by Cirrus CI. It'd need some tweaking based on your credentials for Docker Hub/GHCR and to make sure it is able to build the container inside of another container. I don't have access to your CI, so I might need some help.

But otherwise - this container would allow a user to have a persistent volume and keep using whatever version the container builds from

[m0ngr31]

Okay, after 30 commits I finally got it working to build the container in Cirrus. I'll need your help with getting the vars setup but then it should be good

[RDIL]

what's this for?

[m0ngr31]

Oh that's a directory I had made for mounting the container in while testing. I can remove that line if needed