Page tree
Skip to end of metadata
Go to start of metadata

Source code

All source code for the common portal development can be found here: https://github.com/panosc-portal

Objectives

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

Features

ElementLanguage/frameworkFeatures
UIjs or ts/reactLogin

Select a remote desktop or notebook server image (single option for each)


Connect to the instantiated server
See current running instantiated servers
Backendnode/loopback (TBD)Manage remote desktop and notebook server images (single image of each)
Manage running instances

List images


List instances
Instantiate image
Attach to instance


Architecture

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:


Minimal Architecture.pptx

Details of each micro service are shown below:


Microservice/entityDescription
Reverse ProxyThe 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.
API Service

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.

Account 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.

Cloud Service

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).

Cloud Provider

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.

Desktop Service

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.

Notebook Service

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.

  • No labels