The net problem when deploy che server and che workspace in differenet VM.

[Madixin]

I have get a net problem when deploy che server and che workspace in differenet VM.

My enviroment:
Che Server VM eth0 : 10.21.25.232
Che Workspace VM eth0 : 10.21.27.16
Che version:4.5.1
Operating system：Centos 7.0.1

Reproduction Steps:
1.modified machine.docker.che_api.endpoint=http://10.21.25.232:8080/wmaster/api
2.run che server like:

docker run --name che -p 8080:8080 -v /var/run/docker.sock:/var/run/docker.sock -e DOCKER_HOST=tcp://10.21.27.106:4243 che -r:10.21.25.232

3.create project, the workspace has created, but got this error as its launched: “The workspace agent has attempted to start, but it is unable to ping the Che server at http://che-host:8080/wsmaster/api/”

It seems like the che workspace container can not ping to 10.21.25.232:8080, because it is NAT net mode in 10.21.27.16

Is there simple way to solve it?

[TylerJewell]

I think this is the same problem as #1644 and #1925 - and perhaps the fix proposed by @l0rd will be necessary to addressing the problem. #2004

Also - can you please verify that the issue happens with 4.6.2, too?

[Madixin]

I could run 4.5.1 like:
docker run --name che -p 8080:8080 -v /var/run/docker.sock:/var/run/docker.sock -e DOCKER_HOST=tcp://10.21.27.106:4243 codenvy/che:4.5.1 -r:10.21.25.232

but when comes to 4.6.2,I gote these error: Any changes?

Error: No such image or container: ceb7a86dd7dc

ERROR: !!!
ERROR: !!! You passed an unknown command line option.

ERROR: !!!

[Madixin]

I have changed the image name from to codenvy/che to codenvy/che-server , it can run che server ok.

docker run --name che -p 8080:8080 -v /var/run/docker.sock:/var/run/docker.sock -e DOCKER_HOST=tcp://10.21.27.106:4243 codenvy/che-server:4.6.2 -r:10.21.25.232

but have this problem:
[ERROR] Timeout reached. The Che server has been unable to verify that your workspace's agent has successfully booted. Either the workspace is unreachable, the agent had an error during startup, or your workspace is starting slowly. You can configure machine.ws_agent.max_start_time_ms in Che properties to increase the timeout

I think the reason is workspace container can not reach to che server

[TylerJewell]

Yes, I know the issue.

We changed the meaning of codenvy/che. You want codenvy/che-server as the image name to use the same syntax as you used to use.

codenvy/che is now for the Docker launcher.

[TylerJewell]

Ok - at least you are now running properly. The Che server attempts to reconnect to the workspace directlry. The docker daemon creates the ws and then che tries to contact it. Here is the algorithm for how Che pings the ws:

1. Use the value of che.properties property named machine.docker.local_node_host.
2. Else, use the value of CHE_DOCKER_MACHINE_HOST system environment variable.
3. Else, if server connects to Docker via Unix socket then use localhost.
4. Else, get the value that the Che server used when it connected to the Docker daemon DOCKER_HOST.

So from the container running the che server - can you figure out an internal IP address that is reachable? You can then set machine.docker.local_node_host into the che.properties and then the che server should attempt to ping the ws directly.

[Madixin]

Cool,it could work for both 4.5.1&4.6.2 if I set machine.docker.local_node_host.

But according your algorithm , if I set CHE_DOCKER_MACHINE_HOST ,it would not work(v4.6.2). Is this a defect?

By the way,is there any details to clarify why and how che server and che workspace communicate with each other.

[TylerJewell]

The algorithm for communications is documented here.
https://eclipse-che.readme.io/docs/networking

Not sure I udnerstand your other question about the environment variables.

[Madixin]

I mean if I only set CHE_DOCKER_MACHINE_HOST while not modified machine.docker.local_node_host, it would not work

And I want to known why che server need to communicate with che workspace two-way. Could che server only communicate with docker deamon?

[TylerJewell]

Che server has to communicate with workspace. Keep alives, determining internal state of the workspace, and so forth. We have no plans to support Che communicating to the workspace through the Docker container. But in theory it's possible. This would break certain portability goals that we have, however. As the docker layer is removable by our partners.

@garagatyi - he would have to comment on the CHE_DOCKER_MACHINE_HOST variable with the server. That is a server environment variable. If that value is set, it should be picked up.

[Madixin]

Thanks~~I get it~