|
| 1 | +# ShinyProxy Operator |
| 2 | + |
| 3 | +Easily run ShinyProxy on a Kubernetes cluster |
| 4 | + |
| 5 | +**(c) Copyright Open Analytics NV, 2020-2021 - Apache License 2.0** |
| 6 | + |
| 7 | +## Why? |
| 8 | + |
| 9 | +Deploying and managing ShinyProxy can get complex when many apps are used, |
| 10 | +especially when the configuration of ShinyProxy is often updated. When |
| 11 | +restarting a running ShinyProxy instance (in order to update its configuration), |
| 12 | +users will face a disconnect from their running applications. The only solution |
| 13 | +to guarantee that users do not lose their connection to running apps, is to keep |
| 14 | +the current instance alive when updating ShinyProxy's configuration. However, |
| 15 | +manually keeping track of these instances would be too cumbersome and should |
| 16 | +therefore be automated. |
| 17 | + |
| 18 | +The ShinyProxy operator for Kubernetes is able to manage multiple ShinyProxy |
| 19 | +instances and their configuration. To give an example of the working of the |
| 20 | +operator, assume we have some ShinyProxy configuration `config1` which contains |
| 21 | +one app called `app1`. When the operator starts working, it checks whether a |
| 22 | +ShinyProxy instance exists with that configuration. If not, it starts a |
| 23 | +ShinyProxy instance and all other required configuration. Users can now start |
| 24 | +using `app1` on this instance. Some time later, the need for a second app |
| 25 | +arises. Therefore, the administrator adapts the configuration of ShinyProxy to |
| 26 | +include a second app `app2`. However, some users are still using `app1` on the |
| 27 | +old instance. These apps may have some state, which should not be lost. |
| 28 | +Therefore, the operator starts a second ShinyProxy instance using configuration |
| 29 | +`config2`. The operator ensures that users which are currently using the first |
| 30 | +instance, stay on that instance. All other users, are forwarded to the new |
| 31 | +server and can use the new application. Nevertheless, users using an old |
| 32 | +instance can choose to use the new instance, by clicking a button in the user |
| 33 | +interface. The operator stops the old instance once it has no apps running. |
| 34 | + |
| 35 | +## Building from source |
| 36 | + |
| 37 | +Clone this repository and run |
| 38 | + |
| 39 | +```bash |
| 40 | +mvn -U clean install |
| 41 | +``` |
| 42 | + |
| 43 | +The build will result in a single `.jar` file: |
| 44 | +`target/target/shinyproxy-operator-jar-with-dependencies.jar`. |
| 45 | + |
| 46 | +## Running |
| 47 | + |
| 48 | +The operator should be run in Kubernetes using the [docker image](https://hub.docker.com/r/openanalytics/shinyproxy-operator-snapshot). |
| 49 | +It can run in either `clustered` scope or `namespaced` mode. In the former the |
| 50 | +operator looks for ShinyProxy instances in all namespaces while in the latter it |
| 51 | +only manages ShinyProxy instances in its own namespace. |
| 52 | + |
| 53 | +See the [docs/deployment](docs/deployment) folder for more information. |
| 54 | + |
| 55 | +## Configuration |
| 56 | + |
| 57 | +We try to keep the configuration of the Operator itself as minimum as possible. |
| 58 | +Furthermore, we want the operator to work without configuration in most cases. |
| 59 | +Nevertheless, for some specific cases some configuration options are available. |
| 60 | +For now these options are specified using environment variables. All variables |
| 61 | +start with the `SPO` prefix, meaning **S**hiny**P**roxy**O**perator. |
| 62 | + |
| 63 | +- `SPO_MODE`: can either be `namespaced` or `clustered` (default). This |
| 64 | + specifies whether the operator should only look in its own namespace for |
| 65 | + ShinyProxy configurations or in all namespaces. |
| 66 | +- `SPO_DISABLE_SECURE_COOKIES`: when set to any value, this disables the |
| 67 | + `secure` flag on all cookies used by the Operator. |
| 68 | +- `SPO_PROBE_INITIAL_DELAY`: specifies the initial delay of the Readiness and |
| 69 | + Liveness probes. This is useful when the used Kubernetes version does not |
| 70 | + support startup probes. |
| 71 | +- `SPO_PROBE_FAILURE_THRESHOLD`: specifies the failure threshold of the |
| 72 | + Readiness and Liveness probes. This is useful when the used Kubernetes version |
| 73 | + does not support startup probes. |
| 74 | +- `SPO_PROBE_TIMEOUT`: specifies the timeout in seconds of the Readiness and |
| 75 | + Liveness probes. This is useful when the used Kubernetes version does not |
| 76 | + support startup probes. |
| 77 | +- `SPO_STARTUP_PROBE_INITIAL_DELAY`: specifies the initial delay of the StartUp probe. By default, this is 60 seconds. |
| 78 | +- `SPO_LOG_LEVEL`: configures the log level of the operator, may be one of the |
| 79 | + following: |
| 80 | + - `OFF`: disables logging |
| 81 | + - `ERROR` |
| 82 | + - `WARN` |
| 83 | + - `INFO` |
| 84 | + - `DEBUG`: default (may change) |
| 85 | + - `TRACE` |
| 86 | + - `ALL`: enables all logging |
| 87 | + |
| 88 | +Note: in our deployments where startup probes aren't supported we have success |
| 89 | +with the following configuration: |
| 90 | + |
| 91 | +- `SPO_PROBE_INITIAL_DELAY` to something between 40 and 140 depending on the |
| 92 | + performance of the cluster. |
| 93 | +- `SPO_PROBE_FAILURE_THRESHOLD` to `2` |
| 94 | +- `SPO_PROBE_TIMEOUT` to `3` |
| 95 | + |
| 96 | +## Supported Versions |
| 97 | + |
| 98 | +The first stable release of the operator (1.0.0) is compatible with ShinyProxy |
| 99 | +2.6.0. Older ShinyProxy versions are supported by running development snapshots |
| 100 | +of the operator, however, we strongly advice to upgrade to the latest version of |
| 101 | +ShinyProxy and the operator for the best experience. |
| 102 | + |
| 103 | +| ShinyProxy Version | Minimum operator version | Maximum operator version (inclusive) | |
| 104 | +|--------------------|----------------------------------|--------------------------------------| |
| 105 | +| 2.4.3 | `0.0.1-SNAPSHOT-20201215.112635` | `0.0.1-SNAPSHOT-20201215.112635` | |
| 106 | +| 2.5.0 | `0.0.1-SNAPSHOT-20210302.095930` | `0.0.1-SNAPSHOT-20210607.070151` | |
| 107 | +| 2.6.0 | 1.0.0 | TBD | |
| 108 | + |
| 109 | +## Kubernetes versions |
| 110 | + |
| 111 | +| | k8s 1.22.x | k8s >= v1.21.3 | k8s <= v1.21.2 | k8s >= 1.20.10 | k8s <= v1.20.9 | v1.19 | v1.18 | v1.17 | v1.16 | |
| 112 | +|----------------|------------|----------------|----------------|----------------|----------------|-------|-------|-------|-------| |
| 113 | +| 1.1.0³ | ✓ | ✓ | ✓² | ✓ | ✓² | ✓ | - | - | - | |
| 114 | +| 1.0.0 | - | ✓ | ✓² | ✓ | ✓² | ✓ | ✓ | ✓¹ | ✓¹ | |
| 115 | +| 0.0.1-SNAPSHOT | - | ✓ | ✓² | ✓ | ✓² | ✓ | ✓ | ✓¹ | ✓¹ | |
| 116 | + |
| 117 | +**Note:** |
| 118 | + |
| 119 | +- ¹ requires the use of `SPO_PROBE_INITIAL_DELAY` and `SPO_PROBE_FAILURE_THRESHOL` due to lack of startup probes |
| 120 | +- ² requires a workaround, see below. |
| 121 | +- ³ not yet released; this version will use the `extensions/v1beta1` version of `Ingress` which is removed in k8s v1.22, but only available from v1.19 |
| 122 | + |
| 123 | +### Workaround for bug in Kubernetes |
| 124 | + |
| 125 | +A [bug](https://github.com/kubernetes/kubernetes/issues/102464) affecting the |
| 126 | +operator was introduced in Kubernetes 1.20 and fixed in versions 1.20.10 and |
| 127 | +1.21.3. However, some deployments (e.g. using EKS) are not able to use this |
| 128 | +version. When using the affected versions, Kubernetes stops sending events for |
| 129 | +the `Service` resources after a certain amount of time. Therefore, the Operator |
| 130 | +is unaware of any events happening on services and is therefore unable to fully |
| 131 | +configure a ShinyProxy server. The bug only occurs after the operator has been |
| 132 | +running for a random time between 30 minutes and two hours. Unfortunately, the |
| 133 | +only reasonable work-around is to regularly restart the Operator. Since version |
| 134 | +`0.1.0-SNAPSHOT-20210831.075527`, it is possible to specify the |
| 135 | +`SPO_PROCESS_MAX_LIFETIME` environment variable. After the configured time (in |
| 136 | +minutes), the operator stops. The corresponding Docker container then |
| 137 | +automatically restarts the Java process. |
| 138 | + |
| 139 | +## Java Version |
| 140 | + |
| 141 | +This project requires JDK 11. |
0 commit comments