Split deploy script into different areas:
- where defaults for each flavor are set
- where variables common to all flavors are set
(may depend on flavor dependent defaults)
- where Che deployment YAML file is customized with sed
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
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>
* Add ability to set OAUTH token for che-server
* Add ability to configure OpenShift project where workspaces objects will be created for OCP and Minishift flavors
* Add ability to deploy che on ocp with local yaml file
* Add missed sed command for deploying with OCP flavor
* Replace null values with defaults
In some cases OpenShift API responses that config map is not valid.
Maybe it is because of version of APIs. It is a problem for OCP instance with openshift v3.5.5.31 and kubernetes v1.5.2+43a9be4
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;
It is needed since it is secured by permissions system which requires
an authenticated user.
Also, use base API endpoint for checking Che in OpenShift deploy
script since system state API which was used before is secured now.
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
* Allow deploying the Keycloak and Postgres servers to Minishift and Openshift Online.
This is related to https://github.com/redhat-developer/rh-che/issues/303
and https://github.com/redhat-developer/rh-che/issues/302
* Make the Che directory readble for any users
* Modify `deploy_che.sh` to support `multi-user` images
* Move the scripts to `che-init` and enhance `deploy-che.sh` to start the secondary server if necessary and wait for postgres to be available.
* Wait for Postgres to be available before starting Keycloak
* Clean scripts through spellcheck and add missing licenses
* Change the health check to `/api` instead of `/api/system/state` since, with the new permission work, accessing `/api/system/*` requires the user to have specific system rights.
* Fixes after comments on PR
* Use the new official `keycloak-openshift` image and manage web-origins
* Make Keycloak memory limits consistent with official requirements defined
[here](http://www.keycloak.org/docs/latest/server_installation/topics/installation/system-requirements.html)
Signed-off-by: David Festal <dfestal@redhat.com>
Roman Iuvshyn