Allow running the webserver portion standalone. #184
Conversation
|
I'm going to stick this behind #186 as it's likely going to be impacted by it. |
| @@ -299,3 +299,6 @@ ircBridge: null | |||
|
|
|||
| # The allowed channel prefix of the bot | |||
| #channelPrefix: '#conference-' | |||
|
|
|||
| templatesPath: ./srv | |||
| runMode: normal | |||
There was a problem hiding this comment.
I would have been tempted to make this a CLI argument instead so you don't need two config files, but is that reasonable?
There was a problem hiding this comment.
At the moment it's both an env file and a config argument, the idea being we have one config for both processes and just switch on a env...however I think the config field is probably pointless. Let's just have an env flag for easy kubernetes-ing.
| // Use first returned IP. | ||
| hostname: ip[0], |
There was a problem hiding this comment.
this doesn't seem to match the commit comment, also I don't see how this makes sense at current as it seems like it'd just choose the first character... (maybe it will be obvious with later commits).
Half-Shot
force-pushed
the
hs/split-out-webserver
branch
from
a38224c
to
6128c73
Compare
Half-Shot
force-pushed
the
hs/split-out-webserver
branch
from
6128c73
to
5983d50
Compare
This is currently a draft as I work on the interdependencies between the backend parts and the frontend, and figuring out how to handle both.
I had quite a few challenges actually getting this going on my laptop, so I made a few bold decisions which are documented in my commits. Nothing hair raising, but quite a few major bumps as our dependencies had started to rot. Ideally this would land in a different PR, but I'd rather not overcomplicate things at present.
The new system works by specifying a runmode in your config or env vars, which allows the service to either run "normally" or in a "webserver" configuration. This means that when we run this in a kube environment, we just supply a different env.