Docker Launcher: Websockets are unable to comunicate with the wsagent when the server and the browser run on different networks

In scenarios where a wsagent has two different IP addresses:

• An internal IP address that is used by Che server
• An external IP address that is used by the websockets in the browser

the creation of a new workspace and project fails.

I could reproduce that using Docker for Mac but the scenario should be reproducible wherever you have an internal/external IPs (e.g. amazon EC2). There is a workaround (rerouting the traffic to the internal IP address to the external IP address on the Docker host) and it’s described here. This issue is about removing the need to use this workaround and is related to #1482.

Reproduction Steps:

1. Run Che inside a container using Docker for Mac without setting the lo0 alias
2. Access the dashbord using the URL http://localhost:8080
3. Create a new workspace and project

Expected behavior:

The workspace and project should be created successfully. The websocket should use the URL in the address bar to contact the wsagent (with a different port).

Observed behavior:

The creations hangs after the wsagent is started:

[STDOUT] 2016-07-04 15:40:41,950[main] [INFO] [o.a.catalina.startup.Catalina 642] - Server startup in 39359 ms [STDOUT] 2016-07-04 15:40:43,204[nio-4401-exec-4] [WARN ] [i.ContainerResponse$BodyWriter 90] - Client has aborted connection. Response writing omitted.

And after a few minutes a popup message with the following error:

Workspace Connection Error It seems that your workspace is running, but we cannot connect your browser to it. This commonly happens when Che was not configured properly. If your browser is connecting to workspaces running remotely, then you must start Che with the --remote:<ip-address> flag where the <ip-address> is the IP address of the node that is running your Docker workspaces.Please restart Che with this flag. You can read about what this flag does and why it is essential at: https://eclipse-che.readme.io/docs/configuration#envrionment-variables

Opening the developers tools in Chrome I could see that the websocket is tring to connect to an host (192.168.65.2) that is not accessible from the Mac OS and that is different from the host I’ve put in the brwoser address bar (localhost)

Che version: 4.4.0-RC1-SNAPSHOT
OS and version: Mac 10.11.5 Docker version:

Client:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd
 Built:        Fri Jun 17 20:35:33 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   a7119de
 Built:        Wed Jun 29 10:03:33 2016
 OS/Arch:      linux/amd64
 Experimental: true

Che install: Docker container

Additional information:

• Problem started happening recently, didn’t happen in an older version of Che: Yes
• Problem can be reliably reproduced, doesn’t happen randomly: Yes

[l0rd]

From the point of view of a user the URL on the address bar is the perfect choice because there is no need to specify another parameter when starting Che. And it makes even more sense if you plan to use a reverse proxy.

Your solution @tylerjewell would work too but is more complicated imho.

By the way have you looked at traefikproxy? That’s the modern reverse proxy for containers and is developed by my friend @emilevauge 😃

On Monday, 4 July 2016, Tyler Jewell [e-mail] wrote:

Yeah I understood his configuration, but I am questioning if we should consider the use case and instead ask agent ip to be consistently applied inside the workspace and then allow nginx to handle the nuances of the internal mapping.

I totally understand that he wants to address the docker for Mac scenario where nginx would apply, but just question the scenario generally.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/che/issues/1644#issuecomment-230324565, or mute the thread https://github.com/notifications/unsubscribe/AAlC779uMwGBdt9fdx5KZxy4qt6um2E8ks5qSTYDgaJpZM4JEfO- .

[JamesDrummond]

Can we remove the milestone and add sprint/next-sprint?