Config che server to Nginx,but terminal is die

[xiong305817127]

Hello, I use Nignx reverse proxy server to run my che server and che workspace link, so that the browser's entrance to look the same, and everything is running very well.

But I open a terminal in che server, a few minutes or more without operations, terminal die(The terminal websocket broken links ), unable to input and output. can only be close, to open a new one or refresh the page .

I guess whether the nginx websocket long connection timeout, no operation off within a few minutes?

If it is for this reason is there any way to avoid? In addition to configure nginx longer timeout. Or maybe something else?

thanks.

[AndrienkoAleksandr]

@xiong305817127 We have not implemented yet reconnect UI to terminal process in case websocket connection is closed. Thank you for bug report.

[monaka]

@xiong305817127
Is the version of your Che 4.x or early milestones 5.0?
I had similar issue and it seems to be fixed on recent milestones of Che 5.0.
At least Che 5.0-M7 is working behind Nginx on my cluster.

[xiong305817127]

@monaka , I am using che 4.5.1, may I ask which issue is, we can refer to modify our code?

ps. In Che 5.0-M7, I can see the ws://IP:33384/wsagent/ext/ws, send the ping and pong communication , but the ws://IP:33382/pty that without any ping and pong communication .

thanks.

[monaka]

@xiong305817127
I'm not sure which PR fixed the issue. In my case, Che version was 4.7.2.
So I guess all 4.x of Che can't use with Nginx.

[Alexpud]

I have used nginx and che as reverse proxyes and had no trouble. But if am not wrong you can configre nginx configuration files to change the connection related information.

@monaka nginx and che didn't work like i expected as well. You can't ,as far as i tested, put che instances behind sockets. I only tested the che server port like 8080, but as i recall each che instance uses a lot of ports and i am not sure if you need to use socket for them as well.

What me and my friend did was to reserve each instance to a port on the machine, and have nginx redirect the user depending on some info.

You could try some more elaborate iptable or routing on the host machine, i am not brave enough for that though.

[TylerJewell]

Red Hat is planning to start the process of looking at how to redirect browser > workspace traffice, which operates over a variety of ports over the ephemeral port range through an embedded reverse proxy, so that all traffic for Che can be managed over a single port. It's a lot of work, as when you have many workspaces all with their own servers running on ports inside containers, there is a lot of mappings to be done. I am hopeful that they can submit a lasting solution sometime in Q2.

[Alexpud]

Related to nginx and che, when i was developing a che farm i didn't se the necessity of having nginx. As far as routing goes, you can use a client application that deppending on the user, it will redirect him to his instance, i tried doing it on nginx and it was too complicated.

The nginx role on the che farm would be to restrict the access of users to other intances, like direct access to another instance dashboard for example? Because that and the usage of the REST api, are the problems i have on the che farm.

[monaka]

@xiong305817127 In that sense, we still need more ports addition to 8080.
My che server has two NIC. The one is for 8080, behind Nginx. The another is for Docker, opening many ports.
In my experience, Old versions (4.x) of Che didn't boot up their workspace on the same server above.

[TylerJewell]

We now have a prototype for how we will channel everything through a single port. This does not yet channel SSH traffic, but all primary workspace traffic. #4440 (review)

I should note that this code may or may not get committed. We haven't been able to figure out a clean way yet to solve the SSH issue and we have to evaluate the impact to custom assemblies of Che like Codenvy, still.

[garagatyi]

I believe that that PR won't help here. Problem with terminal is that it doesn't use ping pong frames to show connection activity to proxy. So to fix this particular issue (not issue with reduced number of published ports) we should implement ping frames. I have this in my branch I'm working on, but not sure if ping frames will be merged into master with this branch as well