Cannot connect to Zookeeper

[FlorianTolk]

After running docker-compose up and digging through the startup logs, I see a list of zookeeper errors pop up.

kafka_1      | [2018-10-08 18:46:35,659] INFO [ZooKeeperClient] Waiting until connected. (kafka.zookeeper.ZooKeeperClient)
kafka_1      | [2018-10-08 18:46:35,660] INFO Opening socket connection to server zookeeper/172.18.0.3:2181. Will not attempt to authenticate using SASL (unknown error) (org.apache.zookeeper.ClientCnxn)
kafka_1      | [2018-10-08 18:46:35,666] INFO Socket error occurred: zookeeper/172.18.0.3:2181: Connection refused (org.apache.zookeeper.ClientCnxn)

zookeeper_1  | 2018-10-08 18:46:37,893 [myid:] - INFO  [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@649] - Got user-level KeeperException when processing sessionid:0x16655009dce0000 type:setData cxid:0x23 zxid:0x1b txntype:-1 reqpath:n/a Error Path:/controller_epoch Error:KeeperErrorCode = NoNode for /controller_epoch

zookeeper_1  | 2018-10-08 18:46:37,997 [myid:] - INFO  [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@649] - Got user-level KeeperException when processing sessionid:0x16655009dce0000 type:delete cxid:0x37 zxid:0x1e txntype:-1 reqpath:n/a Error Path:/admin/reassign_partitions Error:KeeperErrorCode = NoNode for /admin/reassign_partitions

and

zookeeper_1  | 2018-10-08 18:46:38,012 [myid:] - INFO  [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@649] - Got user-level KeeperException when processing sessionid:0x16655009dce0000 type:delete cxid:0x3a zxid:0x1f txntype:-1 reqpath:n/a Error Path:/admin/preferred_replica_election Error:KeeperErrorCode = NoNode for /admin/preferred_replica_election

What am I doing wrong? KAFKA_ADVERTISED_HOST_NAME is set to my docker0 ip, and the rest of the files I left untouched...

[sscaling]

First of all it always helps to provide all the relevant information to reproduce the issue, including configurations (i.e. docker-compose files), commands, OS, docker versions, logs etc.

In this case, i'm assuming you're running on linux? (possibly in a VM?) due to the docker0 interface.

KAFKA_ADVERTISED_HOST_NAME is set to my docker0 ip

Most likely you want this to be the LAN NIC (eth0/en0) - e.g. 192.168.x.x / 10.10.x.x. Please see the Connectivity Guide for more info.

NoNode for /admin/preferred_replica_election

Would indicate that the broker isn't connected to zookeeper. This probably isn't related to the KAFKA_ADVERTISED_HOST_NAME configuration. Normally Broker -> Zookeeper config is just handled by sharing the same network name space + bridge network when the containers startup. Hard to diagnose any further without more information.

[FlorianTolk]

My Apologies for the incomplete report,

I am using
Ubuntu 16.04
Docker 17.03.2
docker-compose 1.8.0

Adding the full docker logs would result in an incredibly long log file. So I will instead list the steps I took (updated to go to my 172.16.xx.xx enp4so)

git clone https://github.com/wurstmeister/kafka-docker.git
Open the docker-compose.yml file and replace the KAFKA_ADVERTISED_HOST_NAME with the LAN NIC
sudo docker-compose up
From there you will see the startup log from the docker container with all of the previously stated errors.

Side note: I could not find a 192.168.xx.xx or 10.10.xx.xx so I had to assume this would be correct?

[FlorianTolk]

So, I ignored the error list, and it looks like everything works despite the error list.

The errors are still there, they don't seem to cause any real problems

[sscaling]

172.16.x.x is a Reserved Private Network address - so that is most likely correct.

You should be able to check if zookeeper is up and running by sending a status command to the open port, e.g.

$ echo "ruok" | nc localhost 2181
imok
$ echo "stats" | nc localhost 2181
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.20.0.3:44672[1](queued=0,recved=70,sent=71)
 /172.20.0.1:35878[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/1/15
Received: 72
Sent: 72
Connections: 2
Outstanding: 0
Zxid: 0x1f
Mode: standalone
Node count: 25

I guess only the full logs would have possibly helped with seeing what was causing the error message.