feat: setting up a production instance

[acollign]

This PR adds a Docker set up that makes possible running netrunner in production. It implements #7516.

[acollign]

I am creating a draft PR to gather early feedback about this contribution.

I have also documented the set up. Since I wanted to contribute to the wiki which does not allow creating PR against the project wiki, please see this PR in my fork https://github.com/acollign/netrunner-wiki/pull/1/files. Feel free to comment the documentation.

I hope someone will be able to follow the steps and validate that both the documentation and the Docker set up are good.

[acollign]

I've implemented a new strategy which consists of managing the docker-compose file used in production via a template and a new lein command called generate-docker.

The complete steps are documented in a wiki PR [0]. The process is essentially the following:

• checkout the repo
• generate the production docker compose file, either with default values or customised ones
• build the image
• (recommended) customise configuration
• launch the docker infrastructure
• perform data provisioning
• (recommended) re-generate the docker compose file to close the MongoDB port

@NBKelly would you consider this contribution? Thanks in advance for your feedback.

[0] https://github.com/acollign/netrunner-wiki/pull/1/files

[NBKelly]

Roughly looks alright to me, but I'm actually clueless about this type of thing, so it might need @NoahTheDuke or @butzopower (I think he's roughly familiar with docker) to look over it.

[xdg]

(N.B. I have certain biases as a MongoDB employee.) Relevant to this PR vs #7766, I think it would be valuable to abstract the MongoDB deployment. In my production deployments, I target an external MongoDB Atlas cluster, which makes the data persistent (and durably replicated) independent of the web host. For example, I have shut down the MITM Showdown jnet clone, but the database continues to exist and I can relaunch the MITM showdown server in the future without having to manually manage the DB data directory.

Possibly, a way forward could be to focus first on a PR generating useful Dockerfiles. Another PR could build upon that to provide a set of docker compose files. To the greatest extent possible, we should decouple those two things so that neither one depends too heavily on assumptions in the other.

My PR #7766 only does Dockerfiles, so I suggest we look there for whether I've made any assumptions that would preclude what you want to do with compose files or if I can change anything based on a better approach here. If we can agree on those Dockerfiles, we can merge that PR and then rebase this PR on top of those changes.

Some difference I can see at a quick glance about the production Dockerfiles in the two PRs:

• My uberfile execution maps /app/config into the classpath so that compose can externally mount a config file. This PR executes a wrapper to write an externally mounted config into the jar file. I don't think the addition to the jar file is necessary and we can avoid that extra step and extra script file.
• There are slight differences in how npm files are compiled, probably not material, but I'm not an expert.
• This PR updates the openjdk slim image during build and cleans up after. I don't know how important this is -- I would tend to rely on the upstream maintainers to keep their image up to date. But it's a trivial change to make.

My PR also includes two more Dockerfiles so that deployments can be completely independent of the repository:

• Creating a docker image to serve resources so that users don't have to manually clone the repository or copy the resource directory to the web server.
• Creating a docker image to do database initialization without needing the repo or corresponding build tools installed.

I personally think those two images simplify deployment. But they can coexist with this PR's approach to generating compose files and building images using docker compose.

I prefer my approach of building images separate from docker compose. But I don't have any strong reasons for why people shouldn't use the approach in this PR if it fits their brain better.