|
| 1 | +# Deployment Operator Dashboard |
| 2 | + |
| 3 | +To inspect the state of an `ArangoDeployment` you can use `kubectl get ...` to inspect |
| 4 | +the `status` of the resource itself, but to get the entire "picture" you also |
| 5 | +must inspect the status of the `Pods` created for the deployment, the `PersistentVolumeClaims`, |
| 6 | +the `PersistentVolumes`, the `Services` and some `Secrets`. |
| 7 | + |
| 8 | +The goal of the operator dashboard is to simplify this inspection process. |
| 9 | + |
| 10 | +The deployment operator dashboard provides: |
| 11 | + |
| 12 | +- A status overview of all `ArangoDeployments` it controls |
| 13 | +- A status overview of all resources created by the operator (for an `ArangoDeployment`) |
| 14 | +- Run the arangoinspector on deployments |
| 15 | +- Instructions for upgrading deployments to newer versions |
| 16 | + |
| 17 | +It does not provide: |
| 18 | + |
| 19 | +- Direct access to the deployed database |
| 20 | +- Anything that can already be done in the web-UI of the database or naturaly belongs there. |
| 21 | + |
| 22 | +The dashboard is a single-page web application that is served by the operator itself. |
| 23 | + |
| 24 | +## Design decisions |
| 25 | + |
| 26 | +### Leader only |
| 27 | + |
| 28 | +Since only the operator instance that won the leader election has the latest state of all |
| 29 | +deployments, only that instance will serve dashboard requests. |
| 30 | + |
| 31 | +For this purpose, a `Service` is created when deploying the operator. |
| 32 | +This service uses a `role=leader` selector to ensure that only the right instance |
| 33 | +will be included in its list of endpoints. |
| 34 | + |
| 35 | +### Exposing the dashboard |
| 36 | + |
| 37 | +By default the `Service` that selects the leading operator instance is not exposed outside the Kubernetes cluster. |
| 38 | +Users must use `kubectl expose service ...` to add additional `Services` of type `LoadBalancer` |
| 39 | +or `NodePort` to expose the dashboard if and how they want to. |
| 40 | + |
| 41 | +### Readonly behavior |
| 42 | + |
| 43 | +The dashboard only provides readonly functions. |
| 44 | +When modifications to an `ArangoDeployment` are needed (e.g. when upgrading to a new version), the dashboard |
| 45 | +will provide instructions for doing so using `kubectl` commands. |
| 46 | + |
| 47 | +In doing so, the requirements for authentication & access control of the dashboard itself remain limited, |
| 48 | +while all possible authentication & access control features of Kubernetes are still available to ensure |
| 49 | +a secure deployment. |
| 50 | + |
| 51 | +### Authentication |
| 52 | + |
| 53 | +The dashboard requires a username+password to gain access, unless it is started with an option to disable authentication. |
| 54 | +This username+password pair is stored in a standard basic authentication `Secret` in the Kubernetes cluster. |
| 55 | + |
| 56 | +### Frontend technology |
| 57 | + |
| 58 | +The frontend part of the dashboard will be built with React. |
| 59 | +This aligns with future developments in the context of the web-UI of the database itself. |
| 60 | + |
| 61 | +### Backend technology |
| 62 | + |
| 63 | +The backend of the dashboard contains an HTTPS server that serves the dashboard webpage (including all required web resources) |
| 64 | +and all API methods it needs. |
0 commit comments