Workspace container exposed to IP 0.0.0.0 instead of CHE_HOST

[nsymms]

Running che via nightly docker cli, the server starts up OK and asks to create its first workspace. The workspace is created OK, but you can see with "docker ps" that its ports are exposed to 0.0.0.0 instead of the IP specified in environment variable CHE_HOST. During the "Starting Workspace Agent" stage, the server cannot contact the workspace and complains with an error "Client has aborted connection" in the log window and "Workspace Connection Error" window on the page.

If I stop the workspace and start it again, it starts again but the server still cannot reach it.

Reproduction Steps:

1. Start Che in a new data space. I use: docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /home/me/che-data:/data -e CHE_HOST=10.2.4.1 -e CHE_PORT=8085 eclipse/che:nightly start
2. Create new workspace.
3. Notice that the workspace cannot be reached by the server.

Che version:
latest nightly - is that 5.1.0 ??

OS and version:
Ubuntu 14.04 (also tested on 16.04)

Docker version:
1.12.5

Che cli.log output:
Attached
cli.zip

[TylerJewell]

We have some big changes happening in nightly. So you are technically running 5.2.0-SNAPSHOT. There are two major PRs that will be merged that will be changing some of hte way that workspace connections are working.

Can you clear all docker images and run with 5.1.0 - "eclipse/che:5.1.0", please?

[nsymms]

I get the same result using 5.1.0.
I've actually been seeing this behavior for more than a week now. I was very busy on other projects and didn't have time to thoroughly test & report it.

[TylerJewell]

Ooops - sorry, I think you stumbled into a known issue that has a PR to fix it. It was a minor regression due to a refactoring for 5.0.0. Right now, if you are on an external system you have to add in CHE_DOCKER_EXTERNAL_IP=. This should be automatically set, but a refactoring got it removed. Let me dig up the PR that fixes this.

[TylerJewell]

#3657
#3812

[nsymms]

I just tried adding that env var with 5.1.0 and it did not help. The workspace still starts with IP 0.0.0.0 on the exposed ports.
I'm trying with nightly now.

[TylerJewell]

Trying with nightly will probably not fix it - the fix for this was merged 9 minutes ago. But in the mean time there is an extra env variable that has to be set. I have to dig it up - I must have got it wrong. Maybe it is CHE_DOCKER_EXTERNAL_HOST.

[nsymms]

Neither of those env variables or CHE_DOCKER_MACHINE_HOST solved the problem.
I don't understand why the server cannot contact the workspace if its container has ports mapped to 0.0.0.0. That should include everything.

Also, I'm not on an external system. Everything is running on the same machine. I just have two IP addresses, for two different internal networks. I want to have che exposed to only one of those. So maybe I'm not using the proper environment variables? They worked for previous versions, like 5.0.1.

[TylerJewell]

Hmmm. Ok, thanks for explaining. @benoitf @garagatyi - ideas?

[TylerJewell]

@nsymms - my apologies, was doing too much at the same time today. I looked up the variable to configure, and of course, I typed it wrong both times. The variable is CHE_DOCKER_IP_EXTERNAL. Try setting this to the same value as CHE_HOST. This may not entirely solve your problem, but I'd like to see if it is still existing with this mapping.

[nsymms]

Wow. That env var did it. After playing with this for so long, I was skeptical, to be honest. :)

[TylerJewell]

I was too - super sorry about that. If I had been more patient when you first asked the question, I would have gotten the variable correct the first time.

[TylerJewell]

What are you looking at Che for?

[nsymms]

Mostly Node/angular development for now, 2-3 person team. Maybe other things later.

[TylerJewell]

You know that we give away Codenvy (same CLI syntax) free on a fair source license for up to 3 people? You can run it on as many servers as you want and it has team-management built in with authentication. "docker run codenvy/cli:5.1.1 start". The volume mappings are the same and Codenvy is an enterprise version of Che that inherits from the same CLI Docker images.

[nsymms]

I got an email about that today; will definitely give it a look. It's almost exactly what we need right now.