Sign inSign up

qalita/cli

By qalita

•Updated 26 days ago

QALITA Command Line Interface (CLI) is a tool intended to be used by Data Engineers.

Image
Data science
Databases & storage
Monitoring & observability
0

2.3K

qalita/cli repository overview

⁠QALITA CLI

The QALITA CLI & Worker image, ready to use in any environment: run data-quality workers, execute analysis packs, and talk to your QALITA Platform⁠. Also available on PyPI as qalita⁠ and on ghcr.io/qalita/cli.

Image renamed — this image lives at qalita/cli. The legacy qalita/qalita-cli repository is frozen and no longer receives updates: update your pulls and deployment scripts.

⁠Tags

  • latest — most recent release.
  • x.y.z — pinned release. Use the tag matching your QALITA Platform version (see the compatibility matrix in the documentation).

⁠Image layout — read this first

The container runs as the non-root user qalita (uid 10001), as required by least-privilege policies (runAsNonRoot). Everything the worker persists — registration file .worker, sources-conf.yaml, jobs/, logs — lives under /home/qalita/.qalita.

Mount your volume there, and give the host directory to uid 10001:

sudo chown -R 10001:10001 /srv/qalita

A host directory owned by root and bind-mounted into the container is readable but not writable by uid 10001. The symptom is a loop of [Errno 13] Permission denied messages and a worker that never registers. The chown above fixes it.

⁠Quick start

The entrypoint prepends qalita, so pass any CLI command directly:

docker run qalita/cli <your_qalita_cli_command>

⁠Run a worker (recommended pattern)

The trailing worker run command makes the worker run in the foreground — its whole output lands in docker logs — while the supervision UI runs in the background:

docker run -d --name qalita-worker --restart unless-stopped \
  -v /srv/qalita:/home/qalita/.qalita \
  -e QALITA_WORKER_NAME=worker-1 \
  -e QALITA_WORKER_MODE=worker \
  -e QALITA_WORKER_ENDPOINT=https://backend.example.com:3080 \
  -e QALITA_WORKER_TOKEN='<token>' \
  -e QALITA_WORKER_UI=true \
  -e QALITA_WORKER_UI_PORT=7070 \
  -e QALITA_WORKER_UI_HOST=0.0.0.0 \
  -p 7070:7070 \
  qalita/cli worker run

Follow the startup with docker logs -f qalita-worker — expect Authenticated as <email> then Worker '<name>' registered with ID <n>.

⁠Private PKI / internal CA

Neither the REST stack nor gRPC read the OS trust store. On-premise platforms using an internal root CA must mount the PEM bundle (root + intermediates) in the volume and set both variables:

  -e REQUESTS_CA_BUNDLE=/home/qalita/.qalita/certs/ca-bundle.pem \
  -e GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=/home/qalita/.qalita/certs/ca-bundle.pem \

⁠Key environment variables

VariableRequiredPurpose
QALITA_WORKER_NAMEyesWorker name in the platform
QALITA_WORKER_MODEyesworker (long-running) or job (one-shot)
QALITA_WORKER_ENDPOINTyesPlatform backend API URL
QALITA_WORKER_TOKENyesAPI token (Data Engineer role or higher)
QALITA_GRPC_ENDPOINTnoExplicit gRPC endpoint override (e.g. grpcs://host:3011)
QALITA_HOMEnoState directory inside the container (default /home/qalita/.qalita), honored by CLI ≥ 2.18.2
REQUESTS_CA_BUNDLE, GRPC_DEFAULT_SSL_ROOTS_FILE_PATHnoInternal CA bundle for private PKI (see above)

⁠Documentation

Full guide — UI-only mode, chaining commands, logs location, troubleshooting: QALITA CLI documentation⁠.

Tag summary

Content type

Image

Digest

sha256:0916e56f5…

Size

370.7 MB

Last updated

26 days ago

docker pull qalita/cli