Split up Server into Renderer/API for Staging

[FinnIckler]

Recreated so I can deploy from it

[FinnIckler]

API server is still using Webbrick for some reason (maybe puma has to be in the gem file and not just installed by doing gem install puma in the dockerfile 😄 ), but I think everything else works? I'll check the routes tomorrow

[FinnIckler]

mh.. Ok I did a little bit of testing and it looks like we do need sessions because we use sessions in APIs all the time to check for current_user. Mainly stuff that's related to the user like /me/token or permissions

[dunkOnIT]

Per discussion in Slack call

[gregorbg]

As far as I can see, this PR does nothing to set WEB_CONCURRENCY on the individual containers. So every service that is spun up will run 8 workers?! Or am I overlooking something in the diff?

[FinnIckler]

no. We are still setting web concurrency here worker_count = Integer(ENV.fetch("WEB_CONCURRENCY") { Concurrent.available_processor_count }), meaning staging will run 2 workers + 1 API worker

[FinnIckler]

The next PR will be the "set everything to 1 cpu and disable web concurrency PR". It's also important to say that this is staging only so we can run the load test with this setup

[gregorbg]

Ah, okay. So instead of setting the env variable to 1, you're simply provisioning the infrastructure to only even provide one core in the first place.

If you have this on your radar as a follow-up, then that's totally fine by me.