search

pachyderm / pachyderm

Data-Centric Pipelines and Data Versioning
https://www.pachyderm.com/
Apache License 2.0
6.19k stars 566 forks source link

web socket error showing #3232

Open anishvarghese opened 6 years ago

anishvarghese commented 6 years ago

We are testing the pachyderm over minikube in digital ocean machine, successfully installed but trying to start the service over http://localhost:30080/ getting an error as follows

WebSocket connection to 'ws://localhost:30081/' failed: Error in connection establishment

root@pachyderm:~# kubectl version Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.3", GitCommit:"435f92c719f279a3a67808c80521ea17d5715c66", GitTreeState:"clean", BuildDate:"2018-11-26T12:57:14Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

All services are working fine

JoeyZwicker commented 6 years ago

Thanks for submitting @anishvarghese and sorry that we were slow to respond on slack. We'll get back to you shortly with a debug path. Are the other Pachyderm pods running and working successfully? It's only the dashboard that's causing issues?

anishvarghese commented 6 years ago

Hi Joey, Thank you for quick response. My Pachyderm pods are working fine. Finally I found out the issue , I am trying to access the Pachyderm dashboard using the URL localhost: 30080 at the same time a call goes to a web-socket ws:localhost:30081

I deployed my Pachyderm in a digital ocean environment and to access the above I have created two ssh tunnels to my local machine for port 30080 and 30081 respectively and get it working.

Let me know if there any possibility to access the ports 30081 and 30080 in my Digital ocean's public IP instead of localhost or any possibility of access this over a domain using nginx ??

JoeyZwicker commented 6 years ago

@gabrielgrant Can give you some guidance there

gabrielgrant commented 5 years ago

@anishvarghese hey, sorry for the slow reply. if you're running a "local" deployment of pachyderm on a digital ocean droplet, then yes, the most straightforward thing to do is just to access the dash via droplet's ip directly at http://:30080 -- this will automatically connect to the websocket port on the same IP.

If you have your local kubectl pointed at the kubernetes cluster into which pach is deployed, you can also use pachctl port-forward -- this will basically just set up the tunnels that it sounds like you've created manually, so you're able to access the dash via http://localhost:30080

While using port-forward probably doesn't make sense in this case, it can be useful in cloud deployments where access to arbitrary ports/nodes is more tricky to set up

Rohithzr commented 5 years ago

coming to this issue. I have deployed pachyderm on kubernetes and facing the same issue. is there a method to instruct pachyderm to connect to a different path like /ws for websockets? currently pachyderm is trying wss://domain:30081 and i dont want to expose this port

gabrielgrant commented 5 years ago

@Rohithzr unfortunately there isn't currently support for moving the websocket to a sub-path, it expects to connect to connect at the root. If you'd like to expose a port other than 30081, though, you can manually specify which host/port the websocket connects on by appending host and/or port query params to the dash address.

Rohithzr commented 5 years ago

can I implement something like https://pach.domain.com https://pach-socket.domain.com

if yes, what should I change in the kubernetes.

gabrielgrant commented 5 years ago

@Rohithzr you can expose the HTTP and WebSocket server on separate domains, but in order to access the dash, you'd need to put https://pach.domain.com?host=pach-socket.domain.com in the browser's address bar.

Setting this up would likely involve using a Kubernetes Ingress Controller, and pointing the domains at the right gateway, which would be provider-specific.

Rohithzr commented 5 years ago

ok i think we can achieve that somehow, but pahydrrm should think of a good way to handle this instead of a query param. ill try and implement this and let you know.

gabrielgrant commented 5 years ago

this looks like it has useful summary of the process: https://blog.cloud66.com/setting-up-secure-endpoints-in-kubernetes/