Closed Bug 1573985 Opened 6 years ago Closed 5 years ago

[websocktunnel-hosting] Run websocktunnel server for cloudops-based deployments

Categories

(Taskcluster :: Services, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

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.

Summary: Run websocktunnel server for cloudops-based deployments → [websocktunnel-hosting] Run websocktunnel server for cloudops-based deployments

Coop's going to try to get this started..

Assignee: nobody → coop

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.

Assignee: coop → nobody
Component: Operations and Service Requests → Services

Decision from meeting was to put this directly into cloudops-infra repo, bpitts will own this

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.

Flags: needinfo?(bpitts)

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?

Flags: needinfo?(bpitts)

It needs to know its public URL, basically -- this is just an odd way to accomplish that (by gluing HOSTNAME and PORT together).

Dustin, does it generate URLs with port 443 in the for you now?

Flags: needinfo?(dustin)

It looks the same :(

Flags: needinfo?(dustin)

I'll work on that patch. In fact, i have it done, just need to update the tests.

Assignee: nobody → dustin

https://github.com/taskcluster/websocktunnel/pull/50

Brian, does that change look useful to you?

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

Flags: needinfo?(dustin)

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.

Flags: needinfo?(dustin)

Sounds good to me.

Blocks: 1588863
Flags: needinfo?(dustin)
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!

Flags: needinfo?(dustin)

PR is merged in and this is deployed to community.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.