The Backend exposes the REST API for an Organization and executes compute tasks (in a subsystem we call compute engine).
We use this service to store images built from user-provided Functions. Make sure to assign a large enough volume to avoid rebuilding images over and over due to eviction.
This Pod is managed by a Job running on chart installation or update. It uploads container Images to the docker-registry to make them available for future use in Functions.
MinIO is an object storage service and stores all assets registered on the Organization. You should back up the data of this Pod.
This is the database supporting the Backend. You should back up the data of this Pod.
This is an organization-specific message broker to support Celery tasks.
This component will consume events from the Orchestrator. It should be able to access the Orchestrator over gRPC. It handles events and triggers appropriate responses such as starting compute tasks. On startup, it will also register the Organization on the Orchestrator.
This Pod is managed by a Job running on chart installation or update to deal with database schema changes. This Pod also performs user creation.
- scheduler, scheduler-worker
Those are Celery components, handling scheduled tasks.
This is a Django application exposing the REST API through which users interact with Substra.
This is the service processing Celery tasks. It handles Function images builds and running compute tasks. This is where you will find logs related to task processing.
The Backend should be able to reach its Orchestrator. If Organizations share Models, involved Backends must be able to communicate with each other.
We use Helm charts as a way to package our application deployments. If you want to deploy the Backend you can use the Helm chart substra-backend.