Fix deployment to Minishift with the default behavior, in particular:
- increase timeout of waiting for Postgres start
- remove the second check of Postgres after the first one (didn't get why there were 2 of them)
- fix bugs in checking for Postgres status
- fix TLS configuration for Minishift
- renamed deployment configuration
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
* Ping the wsagent URL (possibly external), not the *internal URL*.
* Use `getProperties().getInternalUrl()` when `getUrl()` returns `null`
* Add a new provider for an optional routing suffix for workspaces to be
used in the external URLs of created workspace agents in the
use-cases where a custom server evaluation strategy is used (Openshift,
Traeffik, etc ...).
* Add 2 new macros for the custom server evaluation template which are:
- `user`: the current environment context user if any,
- `workspacesRoutingSuffix`: the suffix returned by the available
`WorspacesRoutingSuffixProvider` if any.
Both values can null, in which case they are not added to the ST
variables, so that it is possible to test on their existence in the
template. For example:
```
<if(workspacesRoutingSuffix)><user>-che.<workspacesRoutingSuffix><else><externalAddress><endif>
```
* Add a new provider to get workspace-related Openshift configuration containing:
- the `io.fabric8.kubernetes.client.Config` object to connect the right
Openshift cluster / namespace in which workspaces will be created
- The name of the namespace in which workspaces are cteated
- A boolean that tell if the workspaces will be created in a different
cluster as the che-server.
These data returned by the subclasses of the new provider can of course
depend on the current user (and this will be the case for multi-tenancy)
* Also support the `application/vnd.api+json` content type in responses
* Now use the new providers to connect to the right clutser / namespace
* Allow the Docker connector to return the API endpoint...
The base `DockerConnector` class returns `null` as the endpoint, thus
keeping the previous behavior.
However the `OpenshiftConnector` implementation now returns the API
endpoint without the need for any environment variable:
Indeed in the case of Openshift, the API endpoint is either based on:
- the internal fully-qualified name of the `che-host` service if
workspaces are to be hosted on the same Openshift cluster,
- the external URL of the `che` route if workspaces may be hosted on a
distinct Openshift cluster.
* If related properties or env variables are void, use the connector to retrieve
the API endpoint.
* Required changes for multi-tenancy in deployment script
* Allow overriding the agent log directories in a clean way so that we don't need
to replace the `XXXWsMasterModule` class only
to override the `run_command` binding.
* Move some local-docker-related configuration into a separate `dynamodule`.
This avoid the need to override the `WsMasterModule` class and comment
these bindings in derived assemblies that use a distinct implementation
or don't need Traeffik (such as for Openshift deployments).
* Return `OpenShiftException` when workspaces namespace cannot be reached
* Add multi-tenancy options to the deploy script
* Add the `CHE_EPHEMERAL` and `CHE_USE_ACME_CERTIFICATE` options
* Fix the name of the used docker image for multi-tenant
Signed-off-by: David Festal <dfestal@redhat.com>
Multi-user Eclipse Che (#6441)
#### How to run it.
```docker run -it -e CHE_MULTIUSER=true -e CHE_HOST=<your ip> -e CHE_KEYCLOAK_AUTH-SERVER-URL=http://<your ip>:5050/auth -v /var/run/docker.sock:/var/run/docker.sock -v ~/.che-multiuser:/data eclipse/che:nightly start --skip:pull --skip:nightly```
#### How to manage it
- Keycloak configured with two realms. ```Master``` and ```che```. Also we have one user admin/admin in both realm. Admin user in master realm is - super admin.
- Eclipse Che configured for che realm
- We enabled user registration in ```Che``` realm
#### Known limitation
- swagger would not work. We need to upgrade a version. to support openid authentification https://github.com/eclipse/che/issues/6015
- It's working on local docker. We are going to provide scalable version based on OpenShift on next versions.
- Invitation of non-existent users to Eclipse Che organization https://github.com/eclipse/che/issues/6335
#### How to run it when it is in a branch
To run an multiuser Che version, the following steps are required after building the branch:
- Rebuild init, cli and che images (in the given sequence). To do that, proceed to folder _dockerfiles/<image_name>_ and run _build.sh_
- Run Che in a usual way using cli, with additional parameters: `-e CHE_MULTIUSER=true` and `--skip:pull --skip:nightly`
Full command example:
`docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /home/user/.che:/data -e CHE_MULTIUSER=true eclipse/che-cli:nightly start --skip:pull --skip:nightly`
- MacOS users may need to edit _che.env_ file in the data folder, changing `CHE_HOST` and `CHE_KEYCLOAK_AUTH__SERVER__URL` values to their specific IP.
When start is succeeded, the following docker containers should be created:
- che, exposing 8080 port;
- che_keycloak, exposing 5050 port;
- che_postgres, exposing 5432 port;
Max Shaposhnik