Skip to content

Latest commit

 

History

History
77 lines (42 loc) · 3.38 KB

CONTRIBUTING.md

File metadata and controls

77 lines (42 loc) · 3.38 KB
Raw

Contribution guide

Overview

The project uses different microservices to ensure a scalable service and is deployed using k3s. All the services are written in Go.

Development environment

For running everything locally the following setup is recommended:

Frontend

npm run start starts the React.js development server. In the package.json the backend server can be configured.

Microservices

Build the Docker containers each time and delete the deployment. Important there that the --docker is used, so that k3s will consider the local Docker images. See also here how to forward a local Kubernetes Pod port to your Host localhost.

Microservices overview

RabbitMQ

RabbitMQ as a queue is used to distribute the worker jobs to its workers.

Minio

Minio is used to store the artifacts (screenshots, videos, downloads) and delete them automatically after a few minutes.

Etcd

Etcd is used to store the shared snippets.

Squid

The Kubernetes Pods are isolated from the external internet and only http traffic is allowed. This gets proxied over the Squid proxy.

File

The worker Pods only have access to the queue, file service, and squid proxy. The file proxy does upload the files to Minio after doing validation.

Control

The control microservice is the server that receives requests from the user. It does create the corresponding workers, sends the messages to the queue, and responds to the user the response payload. Also it does store and serve the user snippets from Etcd.

Worker

For each of the languages, there are individual Docker images and worker implementations since each language gets executed differently.

Generate / Update autocompletion

  • Execute the update_pw.mjs script.

Infrastructure evolution

1st iteration

Classic frontend/backend architecture using React.js and express as a backend. The problem was that the backend also executed the arbitrary code from the user and took care of storing the snippets. Also, the system in a whole was not scaleable. So it had database access which was non-ideal.

2nd iteration

See this Gist. I started using a microservice architecture using k3s and was able to scale up/down the different deployments individually. At this moment it only supported JavaScript snippets.

3rd iteration

The worker infra got rewritten, since the workers would share a lot of code each time: uploading artifacts to the storage server, listening for RabbitMQ messages, etc. For that, a Go daemon was created which took care of that which all the workers now use and only slightly extend the execution logic. In this iteration support for Java, .NET and Python was added.

Updating Playwright

  1. Execute node update_pw.mjs
  2. Create and merge the PR
  3. Wait until PR is built on the main branch
  4. Exeute the following on the host:
  • k3s crictl img
  • k3s crictl rmi <image-ids>
  • kubectl delete pod -l io.kompose.service=control

Then the new version should be live.