[websocktunnel-hosting] Run websocktunnel server for cloudops-based deployments
Categories
(Taskcluster :: Services, task)
Tracking
(Not tracked)
People
(Reporter: dustin, Assigned: dustin)
References
Details
Each deployment will need a websocktunnel server to handle live-logging and interactive tasks. This is a "worker-associated" service, a category outside of the other Taskcluster services.
Websocktunnel server is pretty simple to deploy but should be owned by someone other than the TC team for the releng cluster -- perhaps relops?
It also needs a dedicated hostname, and since it could host potentially malicious content that should not be a subdomain of anything with credentials.
Assignee | ||
Updated•6 years ago
|
Comment 2•5 years ago
|
||
Websocktunnel is currently used for two things:
- live log streaming from generic-worker
- interactive tasks on generic-worker
We decided that this should be deployed per-cluster, and that a single node per-cluster is sufficient. Under that model, it makes sense to add it to the existing CloudOps terraform for cluster management.
Decision from meeting was to put this directly into cloudops-infra repo, bpitts will own this
Assignee | ||
Comment 4•5 years ago
|
||
This is mostly working, but is generating incorrect URLs:
wst-client --verbose https://community-websocktunnel.services.mozilla.com dustin 80 --token <my token>
INFO[0000] connected to websocktunnel url="http://community-websocktunnel.services.mozilla.com:8000/dustin"
when in fact that should be https://community-websocktunnel.services.mozilla.com/dustin (and that URL does work!)
The relevant bit of the docs:
Use the same value for PORT as the port exposed on the host (typically 443), as the service will include that port in the URLs it generates.
So I think PORT should be set to 443, and port 443 inside the docker container should be rewritten to whatever port is convenient outside the docker container.
We could make this better, providing config for PORT to listen on and something like URL_BASE to generate URLs from. If the above is tricky, I can make a release that adds such functionality.
Comment 5•5 years ago
|
||
I'll take a crack at fixing this without requiring you to make any changes.
I'm curious though: why does the service need to support returning arbitrary ports in the URLs at all?
Assignee | ||
Comment 6•5 years ago
|
||
It needs to know its public URL, basically -- this is just an odd way to accomplish that (by gluing HOSTNAME and PORT together).
Comment 7•5 years ago
|
||
Dustin, does it generate URLs with port 443 in the for you now?
Assignee | ||
Comment 9•5 years ago
|
||
I'll work on that patch. In fact, i have it done, just need to update the tests.
Assignee | ||
Comment 10•5 years ago
|
||
https://github.com/taskcluster/websocktunnel/pull/50
Brian, does that change look useful to you?
Comment 11•5 years ago
|
||
Oh, my bad! Can you please test against stage instead of community? Stage is where I applied https://github.com/mozilla-services/cloudops-infra/pull/1495/files
Assignee | ||
Comment 12•5 years ago
|
||
Close, but it didn't figure out the https part:
INFO[0000] connected to websocktunnel url="http://websocktunnel-stage.taskcluster.nonprod.cloudops.mozgcp.net:443/dustin"
let's go with the patch rather than trying to make this work.
Comment 13•5 years ago
|
||
Sounds good to me.
Assignee | ||
Comment 14•5 years ago
|
||
https://github.com/taskcluster/websocktunnel/releases/tag/v2.0.0
give it a shot?
Comment 15•5 years ago
|
||
https://github.com/mozilla-services/cloudops-infra/pull/1503 and v2.0.0 are now in stage and ready to test at https://websocktunnel-stage.taskcluster.nonprod.cloudops.mozgcp.net dustin.
Assignee | ||
Comment 16•5 years ago
|
||
INFO[0000] connected to websocktunnel url="https://websocktunnel-stage.taskcluster.nonprod.cloudops.mozgcp.net/dustin"
woo!
I assume this needs to stay open to deploy to community & firefox-ci, but it looks great in stage!
Comment 17•5 years ago
|
||
PR is merged in and this is deployed to community.
Description
•