Detailed below are the software dependencies that the worker needs in order to start and run,
DEPENDENCY | REASON |
---|---|
PostgreSQL | Primary data store for the server. |
Redis | Data store used as the build queue. |
SMTP Server | Used for sending emails on build failures. |
Detailed below are the software dependencies that the worker needs in order to execute a build via that driver.
DRIVER | SOFTWARE |
---|---|
docker | The dockerd process for managing containers. |
qemu | The qemu software package for creating virtual machines. |
NAME | TYPE | DESCRIPTION |
---|---|---|
|
| The parallelism to use when running multiple builds at once. Set to |
|
| The driver that will be used for executing builds on the worker. |
|
| Configuration settings for generating names for artifacts. |
|
| The block key used for encrypting data. This must be either 16, 24, or 32 characters in length. |
|
| Salt the is used to generate secret. |
|
| Provides connection information to the PostgreSQL database. |
|
| The address of the PostgreSQL server to connect to. |
|
| The name of the database to use. |
|
| The name of the database user. |
|
| The password of the database user. |
|
| TLS configuration for connecting via TLS. |
|
| Path to the CA root to use. |
|
| Path to the certificate to use. |
|
| Path to the key to use. |
|
| Providers connection information to the Redis database. |
|
| The address of the Redis server to connect to. |
|
| The password used if the Redis server is password protected. |
|
| Provides connection innformation to an SMTP server for sending emails. |
|
| The address of the SMTP server. |
|
| The path to the root CA if connecting via TLS. |
|
| The email address to be used in the |
|
| The username for authentication. |
|
| The password for authentication. |
|
| Configuration parameters for each of the file stores the server uses. The
there must be a store configuration block for each. |
|
| The type of the store to use. Must be |
|
| The location where the files are. |
|
| The maximum size of files being stored. Set to |
|
| Configuration parameters for reach third-party provider you want to integrate with, where the |
Note: The worker does not need the
client_id
orclient_secret
details of a provider. For example,provider github {}
will suffice for GitHub integration.
pidfile "/var/run/djinn/worker.pid" log info "/var/log/djinn/worker.log" parallelism 0 driver "qemu" timeout "30m" provider github {} provider gitlab {} crypto { block "1a2b3c4d5e6f7g8h" salt "1a2b3c4d5e6f7g8h" } database { addr "localhost:5432" name "djinn" username "djinn_worker" password "secret" } redis { addr "localhost:6379" } smtp { addr "smtp.example.com:587" ca "/etc/ssl/cert.pem" admin "no-reply@djinn-ci.com" username "postmaster@example.com" password "secret" } store artifacts { type "file" path "/var/lib/djinn/artifacts" limit 52428800 } store images { type "file" path "/var/lib/djinn/images" } store objects { type "file" path "/var/lib/djinn/objects" }
To run the worker simply invoke the djinn-worker
binary. There are two flags that can be given to the djinn-worker
binary.
-config
- This specifies the configuration file to use, by default this will be djinn-worker.conf
.
-driver
- This specifies the driver configuration file to use, for configuring the drivers you want to support on your server, by default this will be djinn-driver.conf
.
The dist
directory contains files for running the Djinn Worker as a daemon on Linux systems that use systemd and SysVinit for daemon management. Use whichever suits your needs, and modify accordingly.
If deploying to a Linux system that uses systemd, then be sure to run systemctl daemon-reload
upon placement of the service file.