Chainguard Container for kafbat-ui

Kafbat-UI is an open-source Web UI for managing Apache Kafka clusters

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/kafbat-ui:latest

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

Getting Started with Docker

To run Kafbat UI with Docker, you'll need a Kafka cluster running in KRaft mode. This example demonstrates a complete setup with both Kafka and Kafbat UI.

Step 1: Create a Docker Network

docker network create kafbat-net

Step 2: Generate a Cluster ID for KRaft Mode

KRaft mode requires a unique cluster ID. Generate one using the Kafka storage tool:

CLUSTER_ID=$(docker run --rm --entrypoint /usr/lib/kafka/bin/kafka-storage.sh \
  cgr.dev/ORGANIZATION/confluent-kafka:latest random-uuid)
echo "Generated Cluster ID: $CLUSTER_ID"

Step 3: Start a Kafka Broker in KRaft Mode

docker run -d \
  --name kafka \
  --hostname kafka0 \
  --network kafbat-net \
  -p 9092:9092 \
  -e KAFKA_NODE_ID=1 \
  -e KAFKA_LISTENER_SECURITY_PROTOCOL_MAP='CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT' \
  -e KAFKA_ADVERTISED_LISTENERS='PLAINTEXT://kafka0:29092,PLAINTEXT_HOST://localhost:9092' \
  -e KAFKA_LISTENERS='PLAINTEXT://kafka0:29092,CONTROLLER://kafka0:29093,PLAINTEXT_HOST://0.0.0.0:9092' \
  -e KAFKA_JMX_PORT=9997 \
  -e KAFKA_JMX_HOSTNAME=localhost \
  -e KAFKA_PROCESS_ROLES='broker,controller' \
  -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 \
  -e KAFKA_CONTROLLER_QUORUM_VOTERS='1@kafka0:29093' \
  -e KAFKA_INTER_BROKER_LISTENER_NAME='PLAINTEXT' \
  -e KAFKA_CONTROLLER_LISTENER_NAMES='CONTROLLER' \
  -e CLUSTER_ID="$CLUSTER_ID" \
  cgr.dev/ORGANIZATION/confluent-kafka:latest

Step 4: Start Kafbat UI

docker run -d \
  --name kafbat-ui \
  --network kafbat-net \
  -p 8080:8080 \
  -e DYNAMIC_CONFIG_ENABLED="true" \
  -e KAFKA_CLUSTERS_0_NAME="local-cluster" \
  -e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS="kafka:29092" \
  -e KAFKA_CLUSTERS_0_METRICS_PORT=9997 \
  -e SERVER_PORT=8080 \
  cgr.dev/ORGANIZATION/kafbat-ui:latest

The Kafbat UI will be accessible at http://localhost:8080.

To verify the service is running and the cluster is online:

curl -s http://localhost:8080/actuator/health | jq '.status'
curl -s http://localhost:8080/api/clusters | jq '.[] | {name: .name, status: .status}'

Step 5: Create Test Topics

Create a test topic to verify everything is working:

docker exec kafka kafka-topics \
  --create --topic test-topic \
  --partitions 3 \
  --replication-factor 1 \
  --if-not-exists \
  --bootstrap-server kafka0:29092

Produce some test messages:

echo "Hello Kafka" | docker exec -i kafka \
  kafka-console-producer \
  --bootstrap-server kafka0:29092 \
  --topic test-topic

You can now view the topic and messages in the Kafbat UI at http://localhost:8080.

Getting Started with Kubernetes

Kafbat UI can be deployed to Kubernetes using the official Helm chart. This guide demonstrates deploying Kafbat UI with a Kafka cluster in KRaft mode managed by the Confluent Operator.

Step 1: Install Confluent Operator

The Confluent Operator simplifies deploying and managing Kafka clusters in Kubernetes.

Add the Confluent Helm repository:

helm repo add confluent https://packages.confluent.io/helm
helm repo update

Install the Confluent Operator:

helm install confluent-operator confluent/confluent-for-kubernetes \
  --namespace default

Wait for the operator to be ready:

kubectl rollout status deployment/confluent-operator --timeout=60s
kubectl wait --for=condition=ready pod \
  --selector app=confluent-operator \
  --timeout=60s

Step 2: Deploy a Kafka Cluster in KRaft Mode

Create a minimal Kafka cluster with KRaft controller and demo topic:

kubectl apply -f - <<EOF
---
apiVersion: platform.confluent.io/v1beta1
kind: KRaftController
metadata:
  name: kraftcontroller
  namespace: default
spec:
  dataVolumeCapacity: 1G
  image:
    application: docker.io/confluentinc/cp-server:7.9.0
    init: confluentinc/confluent-init-container:2.11.0
  replicas: 1
---
apiVersion: platform.confluent.io/v1beta1
kind: Kafka
metadata:
  name: kafka
  namespace: default
spec:
  dependencies:
    kRaftController:
      clusterRef:
        name: kraftcontroller
  dataVolumeCapacity: 1G
  image:
    application: docker.io/confluentinc/cp-server:7.9.0
    init: confluentinc/confluent-init-container:2.11.0
  replicas: 1
---
apiVersion: platform.confluent.io/v1beta1
kind: KafkaRestClass
metadata:
  name: krc-cfk
  namespace: default
spec:
  kafkaClusterRef:
    name: kafka
  kafkaRest:
    endpoint: http://kafka.default.svc.cluster.local:8090
---
apiVersion: platform.confluent.io/v1beta1
kind: KafkaTopic
metadata:
  name: demotopic
  namespace: default
spec:
  kafkaRestClassRef:
    name: krc-cfk
  replicas: 1
  partitionCount: 4
  configs:
    cleanup.policy: "delete"
EOF

Wait for the Kafka cluster to be ready:

kubectl rollout status statefulset/kraftcontroller --timeout=120s
kubectl wait --for=condition=ready pod \
  --selector app=kraftcontroller \
  --timeout=120s

kubectl rollout status statefulset/kafka --timeout=120s
kubectl wait --for=condition=ready pod \
  --selector app=kafka \
  --timeout=120s

Verify the KafkaRestClass is connected:

kubectl get kafkarestclass krc-cfk -o jsonpath='{.status.kafkaClusterID}'

Wait for the topic to be created:

kubectl wait --for=jsonpath='{.status.state}'=CREATED \
  kafkatopic demotopic \
  --timeout=60s

Produce test messages:

kubectl exec -it kafka-0 -- bash -c \
  "seq 1 5 | sed 's/^/Message/' | kafka-console-producer \
    --topic demotopic \
    --bootstrap-server kafka.default.svc.cluster.local:9092"

Step 3: Add the Kafbat Helm Repository

helm repo add kafbat https://kafbat.github.io/helm-charts
helm repo update

Step 4: Create a values.yaml file for Kafbat UI

cat <<EOF > kafbat-ui-values.yaml
image:
  registry: cgr.dev
  repository: ORGANIZATION/kafbat-ui
  tag: latest

replicaCount: 1

envs:
  config:
    DYNAMIC_CONFIG_ENABLED: "true"
    KAFKA_CLUSTERS_0_NAME: "confluent-kafka"
    KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: "kafka:9092"

service:
  type: ClusterIP
  port: 8080
EOF

Step 5: Install Kafbat UI

helm install kafbat-ui kafbat/kafka-ui -f kafbat-ui-values.yaml

Wait for Kafbat UI to be ready:

kubectl rollout status deployment/kafbat-ui-kafka-ui --timeout=60s
kubectl wait --for=condition=ready pod \
  --selector app.kubernetes.io/name=kafka-ui \
  --timeout=60s

Verify the cluster is online:

curl -s http://localhost:8080/actuator/health | jq '.status'
curl -s http://localhost:8080/api/clusters | jq '.[] | {name: .name, status: .status}'

Step 6: Access the Kafbat UI

Port-forward the Kafbat UI service to access it locally:

kubectl port-forward svc/kafbat-ui-kafka-ui 8080:8080

The UI can now be accessed at http://localhost:8080

Documentation and Resources

• Kafbat UI Documentation
• Kafbat UI GitHub Repository
• Kafbat UI Helm Chart Repository
• Kafbat UI Quickstart
• Kafbat UI Examples

For advanced configuration options, refer to the official Kafbat UI configuration documentation.

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.