Architecture
Overview
For deployment, Lapdev has two different main components: the controller and the workspace host.
Controller: The controller handles user facing traffic from a web interface for the management of workspaces and the workspace SSH or HTTP proxy traffic. All Lapdev resources are managed by the controller. For scaling, you can simply add more controller servers and put them behind a load balancer. You can learn more details on scaling here.
Workspace Host: The workspace host is where all the workspaces will be running. In a single node deployment, you can put the controller and workspace host on one server. When your team grows and needs more workspace resources, you can horizontally scale Lapdev by adding more workspace hosts. The controller will manage the scheduling of all the created workspaces and spread them on the different workspace hosts.
Internal Components
Lapdev consists of the following internal components:
Dashboard: the web interface to manage the Lapdev resources, where the users can manage workspaces, projects etc.
API: The Restful API interface to manage all Lapdev resources, and the dashboard effectively sends all user requests to the API.
Conductor: The conductor schedules all the tasks that happen on the workspace host. E.g., spin up a new workspace, run a prebuild for a project etc.
Proxy: The proxy tunnels all workspace traffic between the user and the workspace.
WS: The workspace service runs on each workspace host. It accepts requests from the conductor and does the actual work on the workspace host.
When a user creates a workspace, the internal components interact as follows:
In the web interface provided by Dashboard, the user creates a new workspace.
Dashboard authenticates the user with the API, and sends the workspace creation request to the API.
The API sends the workspace creation request to the Conductor. The Conductor picks the best workspace host to run the workspace and connect to the WS service on the workspace host.
The WS service will build the workspace container image based on the devcontainer information stored in the repository of the workspace, and start a new workspace container based on the built image.
The workspace is up and running. Now the user can SSH into the workspace, and the traffic is tunnelled by the Proxy service. The Proxy can also tunnel the HTTP traffic if the workspace serves it.
Simplicity
One of Lapdev's design goals is to simplify user installation and maintenance. To accomplish this, it is important to minimise the number of external dependencies. The more external dependencies there are, the more installation and maintenance the user will require. Additionally, having fewer external dependencies reduces the troubleshooting surface when something does not work as expected.
For external dependencies, Lapdev only uses PostgreSQL for the database, and Podman for the container runtime.
Last updated
