All source code for the common portal development can be found here: https://github.com/panosc-portal
The aim of this first iteration is to produce an application based on micro-services that allows a user to create/access remote desktops or notebook servers.
The prototype using a simplified/minimal architecture aims to:
- validate some of the core services
- determine problems early in development
- provide minimal functionality of core services
- provide a basis for adding new services
- Determine which services need to be added in the next stage
|UI||js or ts/react||Login|
Select a remote desktop or notebook server image (single option for each)
|Connect to the instantiated server|
|See current running instantiated servers|
|Backend||node/loopback (TBD)||Manage remote desktop and notebook server images (single image of each)|
|Manage running instances|
|Attach to instance|
The following presentation shows the architecture of the application based on a minimal number of micro services with remote desktop and notebook instances being deployed to Kubernetes and OpenStack servers:
Details of each micro service are shown below:
|Reverse Proxy||The Reverse proxy provides an initial facade to some of the high-level micro services. In this case requests to the API Service, the Desktop Service and the Notebook Service are all forwarded by the reverse proxy.|
The API Service provides a main point of entry to the application and facade to APIs of underlying micro services.
User authentication is delegated to the Account Service.
The management of images (Remote Desktop and Notebook Servers) and instances is delegated to the Cloud Service.
An initial implementation will provide OpenID Connect authentication and authorisation.
A User table in a local database will store information about connections.
The account service also provides information about the Roles of the connected user.
The Cloud Service performs two main tasks: firstly, a catalogue of images/instances (Remote Desktop and Notebook) and instances and secondly proxy to concrete Cloud Providers.
All metadata associated to images and instances from all providers is stored in a local database which is used to populate UIs.
A user-initiated request to instantiate an image is then forwarded to the relevant provider which will in turn create a container or VM. The IP:PORT of the instance is returned to be stored in the instances table of the Cloud Provider database.
The Cloud Service will regularly poll all active instances to obtain their states: the state is then stored in the local database (a UI is then able to show current instance states).
Each concrete virtualisation host (eg Kubernetes, Slurm, OpenStack, ProxMox) is represented by a Cloud Provider with an implementation specific to that platform.
In its most basic form, each Cloud Provider can return a list of images/templates, a list of flavours and manage (create, start, stop, destroy) running instances.
A common API provides unified access to these providers from the Cloud Service.
Certain providers will require a local database, for example OpenStack manages flavours and images internally but this is not part of Kubernetes.
The Desktop service acts as a relay between the guacd service on a running instance and a web-socket to the browser client.
Both guacd and web-socket connections are managed here.
Given an instance ID, it uses the Cloud Service to obtain the IP:PORT of the guacd server.
The Notebook Service acts as a proxy to the Notebook Server on a running server.
Given an instance ID, it uses the Cloud Service to obtain the IP:PORT of the Notebook Server.