tl;dr - A simple port forward from the container to the host will not work... Hosts files (e.g. /etc/hosts
on *NIX systems) should not be modified to work around Kafka networking, as this solution is not portable.
1) What exact IP/hostname + port do you want to connect to? Make sure that value is set as advertised.listeners
(not advertised.host.name
and advertised.port
, as these are deprecated) on the broker.
2) Make sure that the server(s) listed as part of bootstrap.servers
are actually resolvable. E.g ping
an IP/hostname, use netcat
to check ports... If your clients are in a container, you need to do this from the container, not only your host
3) To verify the ports are mapped correctly on the host, ensure that docker ps
shows the kafka container is mapped from 0.0.0.0:<host_port> -> <advertised_listener_port>/tcp
. The ports must match if trying to run a client from outside the Docker network.
The below answer uses confluentinc
docker images to address the question that was asked, not wurstmeister/kafka
. More specifically, the latter images are not well-maintained despite being the one of the most popular Kafka docker image. If you have KAFKA_ADVERTISED_HOST_NAME
variable set, remove it (it's a deprecated property)
The following sections try to aggregate all the details needed to use another image. For other, commonly used Kafka images, it's all the same Apache Kafka running in a container.
You're just dependent on how it is configured. And which variables make it so.
wurstmeister/kafka
Refer their README section on listener configuration, Also read their Connectivity wiki.
bitnami/kafka
If you want a small container, try these. The images are much smaller than the Confluent ones and are much more well maintained than wurstmeister
. Refer their README for listener configuration.
debezium/kafka
Docs on it are mentioned here.
Note: advertised host and port settings are deprecated. Advertised listeners covers both. Similar to the Confluent containers, Debezium can use KAFKA_
prefixed broker settings to update its properties.
Others
ubuntu/kafka
requires you to add --override advertised.listeners=kafka:9092
via Docker image args... I find that less portable than environment variables, so not recommended
spotify/kafka
is deprecated and outdated.
fast-data-dev
or lensesio/box
are great for an all in one solution, with Schema Registry, Kafka Connect, etc, but are bloated if you only want Kafka. Plus, it's a Docker anti pattern to run many services in one container
- Your own
Dockerfile
- Why? Is something incomplete with these others? Start with a pull request, not starting from scratch.
For supplemental reading, a fully-functional docker-compose
, and network diagrams, see this blog by @rmoff
Answer
The Confluent quickstart (Docker) document assumes all produce and consume requests will be within the Docker network.
You could fix the problem of connecting to kafka:9092
by running your Kafka client code within its own container as that uses the Docker network bridge, but otherwise you'll need to add some more environment variables for exposing the container externally, while still having it work within the Docker network.
First add a protocol mapping of PLAINTEXT_HOST:PLAINTEXT
that will map the listener protocol to a Kafka protocol
Key: KAFKA_LISTENER_SECURITY_PROTOCOL_MAP
Value: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
Then setup two advertised listeners on different ports. (kafka
here refers to the docker container name; it might also be named broker
, so double check your service + hostnames).
Key: KAFKA_ADVERTISED_LISTENERS
Value: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092
Notice the protocols here match the left-side values of the protocol mapping setting above
When running the container, add -p 29092:29092
for the host port mapping, and advertised PLAINTEXT_HOST
listener.
So... (with the above settings)
If something still doesn't work, KAFKA_LISTENERS
can be set to include <PROTOCOL>://0.0.0.0:<PORT>
where both options match the advertised setting and Docker-forwarded port
Client on same machine, not in a container
Advertising localhost and the associated port will let you connect outside of the container, as you'd expect.
In other words, when running any Kafka Client outside the Docker network (including CLI tools you might have installed locally), use localhost:29092
for bootstrap servers and localhost:2181
for Zookeeper (requires Docker port forwarding)
Client on another machine
If trying to connect from an external server, you'll need to advertise the external hostname/ip (e.g. 192.168.x.y
) of the host as well as/in place of localhost.
Simply advertising localhost with a port forward will not work because Kafka protocol will still continue to advertise the listeners you've configured.
This setup requires Docker port forwarding and router port forwarding (and firewall / security group changes) if not in the same local network, for example, your container is running in the cloud and you want to interact with it from your local machine.
Client (or another broker) in a container, on the same host
This is the least error-prone configuration; you can use DNS service names directly.
When running an app in the Docker network, use kafka:9092
(see advertised PLAINTEXT
listener config above) for bootstrap servers and zookeeper:2181
for Zookeeper, just like any other Docker service communication (doesn't require any port forwarding)
If you use separate docker run
commands, or Compose files, you need to define a shared network
manually using compose networks
section or docker network --create
See the example Compose file for the full Confluent stack or more minimal one for a single broker.
If using multiple brokers, then they need to use unique hostnames + advertised listeners. See example
Related question
Connect to Kafka on host from Docker (ksqlDB)
Appendix
For anyone interested in Kubernetes deployments: