Excellentia
A Platform for sharing computer science knowledge and improving problem solving.
1. Introduction
Excellentia is a platform for exploring computer science knowledge, and it also hosts some probmes that help individuals to sharp their skills.
Created as a academic project, as of now, it only has backend due to time pressures.
2. Back-end
The back-end consists of:
- A Compiler, that potentially compiles a solution
- A Runner, that runs a proposed solution for a problem on some test cases and issues a Verdict (Accepted, Wrong Answer)
- A Judge, which acts as an orchestrator, it calls the compiler to compile the proposed solution's code, and then calls the runner to run the solution and check its correctness
The judge will act as the main entry point for the project.
For now, the hosted problems are The WinterCup 4.0 official problems, which was hosted on 09 April 2022, at INSAT.
The back-end is implemented using Spring Boot 3.0, and supports:
- Logging
- Metrics using Prometheus
- Health status
- Traces (Experimental)
3. Provisioning
3.1 Database
We used a MS-SQL instance as a database, it is used to store:
- Problems: the information about problems
- Runs: the information about a proposed solution
Its deployment is described at
3.2 Excellentia Server
We used an Azure Kubernetes Service instance to host the application. Its provisioning described here
3.3 Storage
To ease the deployment, we hosted a Blob Storage on which we uploaded a 7-zip file containing the test cases of all Winter Cup problems.
The name of the file is tests.7z, and it is located at the tests container.
4. Deployment
Once the provisioning is successfully completed, the application will be deployed on 2 main phases:
4.1 Dockerization
On this phase, we created 4 docker images:
excellentia-common
which acts as a common image, It has common configurationsexcellentia-judge
which is the image containing the Judge micro-serviceexcellentia-compiler
which is the image containing the Compiler micro-serviceexcellentia-runner
which is the image containing the Runner micro-service
To ease dockerization, we implemented a helper bash script at backend sub-directory that creates all images
./dockerize-all.sh
Once dockerized, we implemented a helper bash script at backend sub-directory that deploy all images to Docker Hub
./push-all-docker.sh ACCOUNT_NAME
4.2 Kubernetes Deployment
On this phase, we created a Helm chart, which is located at deployment/4-kubernetes. It contains:
- The required instances, with:
-
$2$ pods for Judge -
$2$ pods for Compiler -
$4$ pods for Runner -
$1$ Ingress pod -
$1$ Prometheus pod
-
- The shared disks (Exactly, the Persistent volumes claims):
- The disk
RUNNER_DISK
on which runs are stored - The disk
TESTS_DISK
on which tests are stored - The disk
LOGS_DISK
on which logs are stored
- The disk
- An InitContainer, that runs on the compiler pod that:
- Installs
curl
andp7zip-full
- Downloads the
tests.7z
file located at the Blob Storage - Extracts it
- Copy it to
TESTS_DISK
- Installs
- A Prometheus instance for collecting metrics
- An Ingress controller acting as a gateway
5. API
For now, we proposed the following API for consumption:
/judge/status
to get the status of the judge/judge/{problem_id}
to submit a solution for the problem identified byproblem_id
. It returns a solution verdict/actuator/health
, to check the health of the micro-service/actuator/prometheus
, to collect the metrics of the micro-service/actuator/logsfile
, to collect the logs of the micro-service