CDS is composed of two binaries:
worker, you can find them on CDS Releases for your os/architecture.
workeris the binary used to run a CDS Job.
engineis the binary used to run all CDS µServices.
A CDS µService is a process that can be launch by the
apimust shared the same PostgreSQL and redis databases. All other CDS µServices have to communicate with
cdnservice is dedicated to receive and store CDS’s logs and artifacts.
cdnmust shared the same PostgreSQL and redis databases.
uiservice serves the CDS UI static files.
/cdsapi- proxypass to reach CDS API.
/cdshooks- proxypass that can be used by some external integrations or webhooks.
/cdshookson the CDS UI to reach this service.
With a single CDS Engine process, you can run all µServices. This is very convenient for testing CDS locally but it’s not recommended for a production installation.
The binary engine can be used to launch in different processes each µService. This is recommended for a production installation.
Each µService can be multi-instantiated, example:
$engine start api, each api shared the same PostgreSQL and redis.
$engine start cdn, each cdn shared the same PostgreSQL and redis.
$engine start ui.
$engine start hooks, each hooks shared the same redis.
$engine start vcs, each hooks shared the same redis.
$engine start elasticsearch.
$engine start repositories.
Example of an installation for a production with 18.000 jobs launched per day:
$engine start api
$engine start cdn
$engine start ui
$engine start hooks
$engine start vcs
$engine start elasticsearch
$engine start repositories
$engine start migrate