Worker Container Requirements Reference#
This reference describes the minimal requirements for integrating a custom worker container into a Dioptra deployment using Docker Compose. These are the requirements you must satisfy regardless of whether you use the Dioptra templates or build a worker container from scratch.
Table of Contents
Environment Variables#
The worker container must provide all environment variables required by the dioptra-worker-v1 process (see dioptra-worker-v1 Reference) as well as credentials for S3-compatible artifact storage.
Variable |
Description |
|---|---|
|
MLflow tracking server URL (consumed natively by MLflow). |
|
S3-compatible endpoint URL for artifact storage (consumed natively by MLflow). |
|
Dioptra REST API base URL. |
|
Username for worker authentication with the REST API. |
|
Password for worker authentication with the REST API. |
|
S3/MinIO access key (consumed by boto3/MLflow). |
|
S3/MinIO secret key (consumed by boto3/MLflow). |
The first five variables are checked by dioptra-worker-v1 at startup; the process exits immediately if any are missing.
AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are consumed by underlying libraries (boto3/MLflow) and must be present for artifact storage operations to succeed.
Note
The Dioptra deployment template supplies these variables through a combination of env files and the docker-compose.yml environment: block.
See Deployment Template Reference and Deployment Folder Reference.
Worker Process#
The container must run the dioptra-worker-v1 command, which is provided by the dioptra-platform Python package.
This can be done in one of two ways:
Directly in the Dockerfile
ENTRYPOINTorCMD: invokedioptra-worker-v1with the required--urland queue name arguments.Via an entrypoint script: create a shell script that handles service startup ordering and then invokes
dioptra-worker-v1.
The minimal invocation is:
dioptra-worker-v1 --url <redis-uri> <queue-name>
See dioptra-worker-v1 Reference for the full command-line reference.
The Dioptra provided workers and the custom worker cookiecutter template both use an entrypoint script that reads the Redis URI from the RQ_REDIS_URI environment variable, waits for dependent services to become reachable, and then starts the worker.
Queue names are passed as positional arguments through the command: section in docker-compose.
Network#
The worker container must join the dioptra Docker network to communicate with other Dioptra services (Redis, MinIO, REST API, MLflow Tracking).
services:
custom-worker:
# ...
networks:
- dioptra
See Also#
dioptra-worker-v1 Reference –
dioptra-worker-v1process environment variables and argumentsIntegrate Custom Containers – Add the custom worker to your deployment
Create a Custom Worker Container – Build a custom worker image
Custom Worker Template Reference – Template files, entrypoint script, and health check details
Deployment Template Reference – Deployment template configuration
Deployment Folder Reference – Generated deployment files and env file descriptions