The docker-compose.yml file in this repository is fully functional to evaluate DefectDojo in your local environment.
Although Docker Compose is one of the supported installation methods to deploy a containerized DefectDojo in a production environment, the docker-compose.yml file is not intended for production use without first customizing it to your particular situation.
See Running with Docker Compose for more information how to run DefectDojo with Docker Compose.
It is recommended to use a dedicated database server and not the preconfigured MySQL database. This will improve the performance of DefectDojo
In both case, if you use a dedicated database server or if you should decide to use the preconfigured MySQL database, make sure to make regular backups of the data. For a dedicated database server follow the instructions that come with the database server. For the preconfigured MySQL you can use mysqldump, e.g. as described in How to backup a Docker MySQL database.
Media files for uploaded files, including threat models and risk acceptance, are stored in a docker volume. This volume needs to be backed up regularly.
Having taken the database to run elsewhere, the minimum recommendation is:
Per https://github.com/DefectDojo/django-DefectDojo/pull/2813, it is now easy to somewhat improve the uWSGI and celery worker performance.
By default (except in
ptvsd mode for debug purposes), uWSGI will
handle 4 concurrent connections.
Based on your resource settings, you can tweak:
DD_UWSGI_NUM_OF_PROCESSESfor the number of spawned processes. (default 2)
DD_UWSGI_NUM_OF_THREADSfor the number of threads in these processes. (default 2)
For example, you may have 4 processes with 6 threads each, yielding 24 concurrent connections.
By default, a single mono-process celery worker is spawned. This is fine until you start having many findings, and when async operations like deduplication start to kick in. Eventually, it will starve your resources and crawl to a halt, while operations continue to queue up.
The following variables will help a lot, while keeping a single celery worker container.
DD_CELERY_WORKER_POOL_TYPEwill let you switch to
As you've enabled
prefork, the following variables have
to be used. The default are working fairly well, see the
Dockerfile.django for in-file references.
DD_CELERY_WORKER_AUTOSCALE_MINdefaults to 2.
DD_CELERY_WORKER_AUTOSCALE_MAXdefaults to 8.
DD_CELERY_WORKER_CONCURRENCYdefaults to 8.
DD_CELERY_WORKER_PREFETCH_MULTIPLIERdefaults to 128.
You can execute the following command to see the configuration:
docker-compose exec celerybeat bash -c "celery -A dojo inspect stats"
and see what is in effect.
This is an experimental features that has some concerns that need to be addressed before it can be used reliably.
Import and Re-Import can also be configured to handle uploads asynchronously to aid in importing especially large files. It works by batching Findings and Endpoints by a configurable amount. Each batch will be be processed in seperate celery tasks.
The following variables have to be used.
DD_ASYNC_FINDING_IMPORTdefaults to False
DD_ASYNC_FINDING_IMPORT_CHUNK_SIZEdeafults to 100
When using asynchronous imports with dynamic scanners, Endpoints will continue to “trickle” in even after the import has returned a successful respsonse. This is becasue processing continues to occur after the Findings have already been imported.
To determine if an import has been fully completed, please see the progress bar in the appropriate test.
The Prometheus endpoint is than available under the path: