docs: Spaceport docs formatting and editorial #495
Conversation
|
|
||
| In this case, external is true, the router will not start an internal spaceport task but will attempt to connect to an external process at the specified listener address. This mode of operation is intended for production environments where, for example, configuration of sensitive key data or allocation of reporting resources, can be centralised and tightly controlled. The listener parameter is ignored for an external spaceport. The collector parameter specifies the address of the shared spaceport. | ||
| To enable the external spaceport, another Router can be run to act as the collector with the exclusive role of processing Studio data. To configure this, the "collector" should have `external` set to `false` and an appropriate `listener` address and port combination. Routers exporting Studio data should have `external` set to `true`, `listener` unspecified, and their `collector` property configured to point to the collector Router. |
There was a problem hiding this comment.
I hadn't really thought about the notion of running a spaceport in a separate router, although of course that is possible.
We do have a separate binary spaceport which has a minimalist CLI and is intended to be run when a standalone collector is required. The thinking here isn't fully baked, because we don't even include spaceport (the binary) in our releases yet...
There was a problem hiding this comment.
Yeah, that's a really good callout and good to capture here; I considered that briefly when writing this and went with what I suggested mostly for packaging and convenience purposes in the near-term.
I think we can pull this back out again in the future, and this PR + this conversation acts as a good artifact for now!
This recaptures some of the bits that I submitted too late on #445, and expands on it a bit too. Feedback welcome.
Follows up: #445
Follows up: #309
Relates to: #66
Relates to: #444