sentry-taskbroker

packaged by Chainguard

Chainguard Container for sentry-taskbroker

Sentry's task broker, which consumes task activations from Kafka and serves them to workers over gRPC

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/sentry-taskbroker:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

Chainguard's sentry-taskbroker image is comparable to the upstream taskbroker image that self-hosted Sentry runs (ghcr.io/getsentry/taskbroker), with the following differences:

• It keeps upstream's layout: the broker runs as /opt/taskbroker from the /opt working directory, reads its release from /opt/VERSION, and keeps its SQLite store in /opt/sqlite. The binary is also available at /usr/bin/taskbroker.
• It runs as the nonroot user (UID 65532) instead of root. /opt/sqlite is owned by that user, so a new volume mounted there is writable. A volume created by the upstream image is owned by root; change its ownership before switching images, for example with docker run --rm -u root -v <volume>:/opt/sqlite cgr.dev/chainguard/busybox:latest chown -R 65532:65532 /opt/sqlite. In self-hosted Sentry the volume name ends in sentry-taskbroker (docker volume ls --filter name=sentry-taskbroker).
• It sets TASKBROKER_DB_PATH=/opt/sqlite/taskbroker-activations.sqlite, the path self-hosted Sentry uses, because the upstream default store (./taskbroker-inflight.sqlite) would resolve to /opt, which the nonroot user cannot write. A store.sqlite.path in a configuration file still takes precedence.
• /opt/VERSION contains taskbroker@<version>+<commit> rather than a bare commit SHA, so the release the broker logs and reports to Sentry includes the version number.
• Like other Chainguard Containers, it has a minimal design with no shell or package manager, and it has few to zero CVEs.

Getting Started

The broker consumes task activations from Kafka and serves them to workers over gRPC on port 50051. Its topics are set in a configuration file, as in self-hosted Sentry, because topic names such as taskworker-dlq contain hyphens, which environment variable names cannot.

Write a configuration that consumes the taskworker topic and sends failed tasks to taskworker-dlq:

mkdir -p taskbroker
cat > taskbroker/config.yml <<'YAML'
kafka_topics:
  taskworker:
    cluster: default
    consumer_group: taskworker
  taskworker-dlq:
    cluster: default
    consumer_group: taskworker
    produce_only: true
create_missing_topics: true
YAML

Start a single-node Kafka and the broker, passing the Kafka address as an environment variable and the configuration with -c:

docker network create sentry

docker run -d --name kafka --hostname kafka --network sentry \
  -e KAFKA_NODE_ID=1 \
  -e KAFKA_PROCESS_ROLES=broker,controller \
  -e KAFKA_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093 \
  -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092 \
  -e KAFKA_CONTROLLER_LISTENER_NAMES=CONTROLLER \
  -e KAFKA_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT \
  -e KAFKA_CONTROLLER_QUORUM_VOTERS=1@localhost:9093 \
  -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 \
  -e CLUSTER_ID=MkU3OEVBNTcwNTJENDM2Qk \
  cgr.dev/ORGANIZATION/kafka:latest

docker run -d --name taskbroker --network sentry -p 50051:50051 \
  -e TASKBROKER_KAFKA_CLUSTERS__DEFAULT__ADDRESS=kafka:9092 \
  -v "$PWD/taskbroker:/etc/taskbroker:ro" \
  cgr.dev/ORGANIZATION/sentry-taskbroker:latest /opt/taskbroker -c /etc/taskbroker/config.yml

Once Kafka is reachable, the broker creates its topics and logs that its gRPC server is listening:

docker logs taskbroker 2>&1 | grep "GRPC server"

The broker reports its health through the standard gRPC health service for sentry_protos.taskbroker.v1.ConsumerService, which you can use as a Kubernetes grpc readiness probe.

Configuration

Self-hosted Sentry keeps the broker's SQLite store on a volume at /opt/sqlite, where the image's TASKBROKER_DB_PATH already points. Mount a volume there so pending tasks survive a restart:

docker run -d --name taskbroker --network sentry -p 50051:50051 \
  -e TASKBROKER_KAFKA_CLUSTERS__DEFAULT__ADDRESS=kafka:9092 \
  -v taskbroker-sqlite:/opt/sqlite \
  -v "$PWD/taskbroker:/etc/taskbroker:ro" \
  cgr.dev/ORGANIZATION/sentry-taskbroker:latest /opt/taskbroker -c /etc/taskbroker/config.yml

To require workers to sign their requests, set TASKBROKER_GRPC_SHARED_SECRET to a JSON list of secrets, such as '["a-long-random-secret"]', and give the workers the same secret.

To use this image in self-hosted Sentry, set TASKBROKER_IMAGE in your .env file to cgr.dev/ORGANIZATION/sentry-taskbroker:latest.

Documentation and Resources

• taskbroker on GitHub
• Self-hosted Sentry documentation
• Self-hosted Sentry configuration for taskbroker

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.