Skip to content

Commit

Permalink
Merge pull request #209 from arangodb/docs/dashboard
Browse files Browse the repository at this point in the history
Dashboard design concept
  • Loading branch information
ewoutp authored Jul 2, 2018
2 parents 186133f + cd9101e commit d5beefa
Showing 1 changed file with 64 additions and 0 deletions.
64 changes: 64 additions & 0 deletions docs/design/dashboard.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# Deployment Operator Dashboard

To inspect the state of an `ArangoDeployment` you can use `kubectl get ...` to inspect
the `status` of the resource itself, but to get the entire "picture" you also
must inspect the status of the `Pods` created for the deployment, the `PersistentVolumeClaims`,
the `PersistentVolumes`, the `Services` and some `Secrets`.

The goal of the operator dashboard is to simplify this inspection process.

The deployment operator dashboard provides:

- A status overview of all `ArangoDeployments` it controls
- A status overview of all resources created by the operator (for an `ArangoDeployment`)
- Run the arangoinspector on deployments
- Instructions for upgrading deployments to newer versions

It does not provide:

- Direct access to the deployed database
- Anything that can already be done in the web-UI of the database or naturaly belongs there.

The dashboard is a single-page web application that is served by the operator itself.

## Design decisions

### Leader only

Since only the operator instance that won the leader election has the latest state of all
deployments, only that instance will serve dashboard requests.

For this purpose, a `Service` is created when deploying the operator.
This service uses a `role=leader` selector to ensure that only the right instance
will be included in its list of endpoints.

### Exposing the dashboard

By default the `Service` that selects the leading operator instance is not exposed outside the Kubernetes cluster.
Users must use `kubectl expose service ...` to add additional `Services` of type `LoadBalancer`
or `NodePort` to expose the dashboard if and how they want to.

### Readonly behavior

The dashboard only provides readonly functions.
When modifications to an `ArangoDeployment` are needed (e.g. when upgrading to a new version), the dashboard
will provide instructions for doing so using `kubectl` commands.

In doing so, the requirements for authentication & access control of the dashboard itself remain limited,
while all possible authentication & access control features of Kubernetes are still available to ensure
a secure deployment.

### Authentication

The dashboard requires a username+password to gain access, unless it is started with an option to disable authentication.
This username+password pair is stored in a standard basic authentication `Secret` in the Kubernetes cluster.

### Frontend technology

The frontend part of the dashboard will be built with React.
This aligns with future developments in the context of the web-UI of the database itself.

### Backend technology

The backend of the dashboard contains an HTTPS server that serves the dashboard webpage (including all required web resources)
and all API methods it needs.

0 comments on commit d5beefa

Please sign in to comment.