Skip to content

Commit d5beefa

Browse files
authored
Merge pull request #209 from arangodb/docs/dashboard
Dashboard design concept
2 parents 186133f + cd9101e commit d5beefa

File tree

1 file changed

+64
-0
lines changed

1 file changed

+64
-0
lines changed

docs/design/dashboard.md

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
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

Comments
 (0)