Your first Kafka consumer with Redpanda Connect
This tutorial builds a working Kafka consumer without writing or compiling any code. By the end you will have a Redpanda Connect pipeline that reads messages from a Kafka topic and prints each one to the terminal. It assumes no prior Redpanda Connect experience. You need about five minutes and Docker.
What Redpanda Connect is
Redpanda Connect (formerly Benthos) is a stream processor you configure instead of program. A pipeline has three parts: an input that reads data, an optional pipeline of processors that transform it, and an output that writes it somewhere. You declare all three in a YAML file, and the runtime does the rest. There is no service to build and no dependency to manage.
Prerequisites
You need two things:
- Docker, running.
rpk, the Redpanda CLI. On macOS:brew install redpanda-data/tap/redpanda. Other platforms are covered in the Redpanda install docs.
rpk bundles both a local Redpanda broker and Redpanda Connect, so it is the only tool this tutorial uses.
Step 1: Start a local broker
rpk container start
This starts a single-node Redpanda broker in Docker and points rpk at it. The output lists the broker address. For a single node it is usually 127.0.0.1:9092. Note the address it prints, because you will use it in the config.
Step 2: Create a topic
rpk topic create greetings
This creates a topic named greetings with one partition, which is enough for a consumer demo.
Step 3: Write the consumer
Create a file named connect.yaml:
input:
redpanda:
seed_brokers: ["localhost:9092"]
topics: ["greetings"]
consumer_group: "tutorial-consumer"
start_offset: earliest
output:
stdout:
codec: lines
The input needs four settings, plus one on the output:
seed_brokersis where the consumer connects. Use the address from step 1.topicsis the list of topics to read. Here it is justgreetings.consumer_groupnames the group. Redpanda tracks how far this group has read, so a restart resumes instead of starting over.start_offset: earliesttells a brand-new group to begin at the oldest available message. A group that has already committed an offset resumes from there instead.codec: lineson the output prints each message on its own line.
Step 4: Run it
rpk connect run connect.yaml
Redpanda Connect starts, connects to the broker, and waits for messages. The startup log ends with a line saying the input is consuming. Leave this terminal running.
Step 5: Send a message
Open a second terminal and produce a message:
echo '{"name":"world"}' | rpk topic produce greetings
Switch back to the first terminal. The consumer prints the message:
{"name":"world"}
That is the full path from producer to terminal: a producer writes to the topic, the consumer reads it, and the stdout output prints it. Send a few more messages and watch each one appear.
Stop the consumer with Ctrl+C and run it again. It does not reprint the old message, because the tutorial-consumer group already committed past it. To replay from the start, change consumer_group to a new name, or reset the group’s offsets.
Optional: Transform before logging
Right now the consumer prints the raw JSON. Add one processor to transform each message before it reaches the output. Put a pipeline block between the input and output:
input:
redpanda:
seed_brokers: ["localhost:9092"]
topics: ["greetings"]
consumer_group: "tutorial-consumer-v2"
start_offset: earliest
pipeline:
processors:
- mapping: 'root = "hello " + this.name'
output:
stdout:
codec: lines
The mapping processor runs a Bloblang expression on every message. This one reads the name field and replaces the whole message with a greeting. The consumer_group is a new name, so the consumer re-reads the topic from the start. Run it again, send {"name":"world"} once more, and the output is now:
hello world
The input reads, the pipeline transforms, the output writes. That is the structure of every Redpanda Connect pipeline, from this one to a production stream.
Clean up
rpk container purge
This stops and removes the local Redpanda container.
Where to go next
You changed the behavior of a Kafka consumer twice without compiling anything: once by pointing it at a topic, and once by adding a transform. Swap the redpanda input for a file or an HTTP source, or swap the stdout output for a database or another topic, and the same three-part structure holds. For deeper Kafka material, see the other posts on this blog.