This document describes the overall system architecture of Sider Enterprise and its requirements.
Sider Enterprise runs along with these services:
- GitHub Enterprise Server
This is an architecture diagram that could help you understand the Sider Enterprise system.
Sider Enterprise itself consists of two components: sideci and Runners. These two components will run on Docker.
sideci is a core component, which is responsible for these features:
- Handle any requests from end-users
- Handle any webhook requests from GitHub Enterprise Server
- Request Runners to perform analyses
- Store data on MySQL
- Get Runners traces on MinIO
- Store cache and background job data on Redis
The processes of sideci are divided into two types of roles: sideci-web and sideci-worker. You might have to consider these roles when you try to set up Sider Enterprise as a cluster system. To learn more about clustering, see Clustering.
We recommend that you put the load balancer in front of sideci-web. sideci-web is an application server and is not good at handling many HTTP requests. Moreover, you can secure connections between sideci-web and end-users as long as you set up your load balancer to listen for HTTPS.
Runners, on the other hand, are the collection of "runner" and perform analyses for users' source code. They will fetch users' source code from GitHub Enterprise Server and may try to access the internet because some runners require the dependency resolution. After the analysis, each runner will upload its result to MinIO. Runners are invoked via Docker API by sideci, and they are not daemon processes, unlike sideci.
The necessary storage space largely depends on the number of analyses. If your organization has many developers, and they actively change their source code, the required storage space could be huge.
Sider Enterprise mainly consumes the storage space via Docker, MySQL, and MinIO, so you may have to care about the disk space for each service. It is assumed that each service should have 500 GiB storage size on its own at least, but this is a too rough estimate that we could recommend what is the best storage size.
Sider Enterprise services should run on any x86_64-compatible machine.
The number of required CPU cores is dependent on the number of analyses. If you run sideci-web, sideci-worker, and Runners on the same host, we recommend you prepare at least 8 cores for the machine. However, 8 cores might be insufficient if your workload is too heavy.
At least, you should respectively prepare 1 GiB RAM for a single sideci-web and 2 GiB RAM for a sideci-worker. Furthermore, Runners should have 1 GiB RAM for each container. It depends on your usage of Sider Enterprise, but we recommend that you should prepare more than 32 GiB RAM as the total amount.
There are no operating systems requirements as long as they support Docker. However, we recommend using Linux based operating systems because we have not yet tested on other OSs.
Although we recommend using the latest version of Docker, your Docker Engine must support at least Docker Engine API v1.25 or higher.
Sider Enterprise requires MySQL 5.7. You cannot use MySQL 5.6 or older. MySQL 8.0 may work, but we do not support the use of this version. Learn more MySQL for other MySQL relevant things.
Redis 5.0 is required for Sider Enterprise. Our dependant library may be compatible with Redis 6.0, but we have not tested with it, so we cannot provide efficient supports for this version. See Redis for more details.
Sider Enterprise requires MinIO in order to store the traces generated by Runners. At least, the version of MinIO must be
RELEASE.2019-08-14T20-37-41Z or higher. You can see how to configure MinIO on MinIO.
If your server is running on Amazon Web Services, you can use Amazon S3 instead of MinIO, since Sider uses Amazon S3. See Amazon S3 if you want to configure it.
Sider Enterprise is compatible with the supported versions of GitHub Enterprise Server. Learn more GitHub Enterprise Server for how to integrate it with Sider Enterprise.