Configurations
Configuration File

Configuration File

Seele's configuration file uses the TOML (opens in a new tab) format and is named config.toml. When the program starts, it will try to read the configuration file in the current directory. If the file does not exist, the program will exit. When using the Docker image provided by Seele, the default current directory is /etc/seele. Therefore, you need to mount the configuration file in this folder for the program to read the configuration file successfully.

The configuration items in the configuration file are shown in the table below:

NameTypeOptionalDescription
log_levelstringYesLog level output to the console, default is warn.
Available values: debug, info, warn, error, off
work_modestringYesSeele's work mode, see below.
Available values: bare, bare_systemd, containerized
Default value: containerized
thread_countsobjectYesThread count used by the judge system, see below
pathsobjectYesDirectories for some folders and programs, see below
telemetryobjectYesObservability configuration, see below
healthzobjectYesHealth probe configuration, see below
httpobjectYesBuilt-in HTTP client configuration, see below
exchangeobjectYesSee Exchange Configuration
composerobjectYesSee Composer Configuration
workerobjectYesSee Worker Configuration

work_mode Configuration

Specifies the mode in which Seele runs, which is related to the working principle of the judge system.

  • When running the judge system program as a regular user, specify bare.
  • When using Systemd to run the judge system program, specify bare_systemd.
  • When deploying Seele's container image to platforms like Docker or Kubernetes, specify containerized (this value is the default).

thread_counts Configuration

To ensure judge fairness, Seele strictly binds each thread to different CPU cores when starting.

By default, let N be the number of CPU cores in the system. Seele will use one of the cores to run the main thread, use another core to run one auxiliary thread (called Worker thread), and use the remaining N-2 cores to run N-2 auxiliary threads (called Runner threads). The judge system will use Runner threads to run secure sandboxes, see Overall Architecture.

Users can change the number of Worker threads and Runner threads by modifying the thread_counts properties shown in the table below:

NameTypeOptionalDescription
workernumberYesNumber of Worker threads
runnernumberYesNumber of Runner threads

paths Configuration

The properties of this configuration are shown in the table below:

NameTypeOptionalDescription
rootstringYesDefault value is /etc/seele. Root folder path for storing persistent files required by the judge system
tmpstringYesDefault value is /tmp. Root folder path for storing judge task folders
runjstringYesDefault value is /usr/local/bin/runj. Path of the secure sandbox program
skopeostringYesDefault value is /usr/bin/skopeo. Path of the skopeo program
umocistringYesDefault value is /usr/bin/umoci. Path of the umoci program

telemetry Configuration

Observability-related configuration. Seele uses the SDK provided by OpenTelemetry (opens in a new tab) to export Tracing and Metrics data. In practice, we usually collect the observability data exported by Seele through the Collector (opens in a new tab) provided by OpenTelemetry, then classify and send it to different observability databases for storage, such as Jaeger, Tempo, and Prometheus, and finally query the data through front-end tools like Grafana.

The properties of telemetry are shown in the table below. When telemetry is not configured, Seele will disable observability features.

NameTypeDescription
collector_urlstringURL of the Collector. Currently, only Grpc protocol is supported
histogram_boundariesnumber[]Boundary configuration for Histogram type metrics. See Observability

healthz Configuration

Seele provides an HTTP health probe for Kubernetes to detect the running status of the judge system and restart it promptly when problems occur. This probe currently only integrates the health status check of Amqp Exchange. If you are not using it, the health probe is meaningless.

Seele will start the HTTP health probe after the startup initialization is completed. If you have configured preloaded container images, you need to configure the Kubernetes probe to wait for enough time.

The properties of this configuration are shown in the table below:

NameTypeDescription
enabledbooleanEnable health probe HTTP endpoint
portnumberPort number of the HTTP endpoint

http Configuration

This configuration controls various parameters of Seele's built-in HTTP client. The latter is currently used for: adding file tasks to download files via HTTP URL, uploading files via HTTP URL. Its properties are shown in the table below:

NameTypeDefault ValueDescription
user_agentstringseele/Version NumberUser-Agent value in the HTTP request header
connect_timeout_secondsnumber8TCP connection request timeout for HTTP requests
timeout_secondsnumber60Timeout for HTTP requests
pool_idle_timeout_secondsnumber600Duration to retain pooled TCP connections
pool_max_idle_per_hostnumber8Maximum number of TCP connections that can be pooled per host