摘要：在用自定義網(wǎng)絡(luò)跑容器的時(shí)候發(fā)現(xiàn)一個(gè)問(wèn)題的自定義網(wǎng)絡(luò)啟動(dòng)會(huì)延遲大概秒換句話(huà)說(shuō)就是如果你使用自定義網(wǎng)絡(luò)在一個(gè)容器啟動(dòng)時(shí)想訪(fǎng)問(wèn)另外一個(gè)容器會(huì)失敗但是如果你先等待秒再訪(fǎng)問(wèn)的話(huà)就一切正常如果你使用自定義網(wǎng)絡(luò)在一個(gè)容器啟動(dòng)時(shí)另外一個(gè)容器會(huì)卡住一段時(shí)間。

在用自定義Docker網(wǎng)絡(luò)跑容器的時(shí)候發(fā)現(xiàn)一個(gè)問(wèn)題：Docker的自定義網(wǎng)絡(luò)啟動(dòng)會(huì)延遲大概40秒！

換句話(huà)說(shuō)就是：

如果你使用自定義網(wǎng)絡(luò)在一個(gè)容器啟動(dòng)時(shí)想訪(fǎng)問(wèn)另外一個(gè)容器會(huì)失?。〉侨绻阆鹊却?0秒再訪(fǎng)問(wèn)的話(huà)就一切正常！
如果你使用自定義網(wǎng)絡(luò)在一個(gè)容器啟動(dòng)時(shí)ping另外一個(gè)容器會(huì)卡住一段時(shí)間。

解決：加上啟動(dòng)腳本檢測(cè)網(wǎng)絡(luò)是否就緒！

可以用類(lèi)似下面的腳本檢測(cè)服務(wù)是否就緒，或者干脆檢查dmesg消息也可以

until nc -z zk 2181; do echo "waiting for zk to be ready"; sleep 0.5; done

在用自定義Docker網(wǎng)絡(luò)跑Kafka的時(shí)候發(fā)現(xiàn)一個(gè)現(xiàn)象：zk服務(wù)正常，但是 Kafka始終報(bào)告連接不上zk

$ docker run --net=br --ip=192.168.33.88 --name=zk -h=zk -d wurstmeister/zookeeper
$ docker run --net=br --ip=192.168.33.91 --name=kf1 -h=kf1 
 -e KAFKA_ZOOKEEPER_CONNECT=zk 
 -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 
 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kf1:9092 
 -e KAFKA_BROKER_ID=1 
 --link zk:zk 
 -it wurstmeister/kafka

運(yùn)行后始終報(bào)錯(cuò)：

java.net.NoRouteToHostException: No route to host
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
    at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
    at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1141)

而如果你不用自定義網(wǎng)絡(luò)的話(huà)則一切正常！

$ docker run --name=zk -h=zk -d wurstmeister/zookeeper
$ docker run --name=kf1 -h=kf1 
 -e KAFKA_ZOOKEEPER_CONNECT=zk 
 -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 
 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kf1:9092 
 -e KAFKA_BROKER_ID=1 
 --link zk:zk 
 -it wurstmeister/kafka

那么問(wèn)題在哪里呢？經(jīng)過(guò)跟蹤后終于發(fā)現(xiàn)問(wèn)題在于Docker的自定義網(wǎng)絡(luò)啟動(dòng)會(huì)延遲大概40秒！需要等容器實(shí)例dmesg中出現(xiàn)下列消息的時(shí)才能正常訪(fǎng)問(wèn)網(wǎng)絡(luò)中的其他容器實(shí)例，這個(gè)等待時(shí)間大概是40秒

[ 1077.847733] docker1: topology change detected, propagating

問(wèn)題找到了，搜索了一圈也沒(méi)有找到怎么讓這個(gè)延遲時(shí)間消失的解決方法，好吧，用土辦法：既然是因?yàn)榫W(wǎng)絡(luò)還沒(méi)準(zhǔn)備好，那就等它準(zhǔn)備好！

可以用類(lèi)似下面的腳本檢測(cè)服務(wù)是否就緒，或者干脆檢查dmesg消息也可以

until nc -z zk 2181; do echo "waiting for zk to be ready"; sleep 0.5; done

那么只要在Docker容器真正開(kāi)始運(yùn)行之前先運(yùn)行上面的腳本檢測(cè)網(wǎng)絡(luò)是否就緒就可以了，查了一下wurstmeister/zookeeper正好有一個(gè)CUSTOM_INIT_SCRIPT參數(shù)可以干這個(gè)事，妥了！

$ docker run --net=br --ip=192.168.33.88 --name=zk -h=zk -d wurstmeister/zookeeper
$ docker run --net=br --ip=192.168.33.91 --name=kf1 -h=kf1 
 -e KAFKA_ZOOKEEPER_CONNECT=zk 
 -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 
 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kf1:9092 
 -e KAFKA_BROKER_ID=1 
 -e CUSTOM_INIT_SCRIPT="until nc -z zk 2181; do echo "waiting for zk to be ready"; sleep 1; done" 
 --link zk:zk 
 -it wurstmeister/kafka

waiting for kafka to be ready
waiting for zk service ready
......
[2017-12-11 09:04:51,046] INFO [Partition user_events-0 broker=1] No checkpointed highwatermark is found for partition user_events-0 (kafka.cluster.Partition)
[2017-12-11 09:04:51,047] INFO Replica loaded for partition user_events-0 with initial high watermark 0 (kafka.cluster.Replica)
[2017-12-11 09:04:51,050] INFO [Partition user_events-0 broker=1] user_events-0 starts at Leader Epoch 0 from offset 0. Previous Leader Epoch was: -1 (kafka.cluster.Partition)
[2017-12-11 09:04:51,087] INFO [ReplicaFetcherManager on broker 1] Removed fetcher for partitions user_events-0 (kafka.server.ReplicaFetcherManager)
[2017-12-11 09:04:51,087] INFO [Partition user_events-0 broker=1] user_events-0 starts at Leader Epoch 1 from offset 0. Previous Leader Epoch was: 0 (kafka.cluster.Partition)

另外：

這個(gè)方法也適用于啟動(dòng)時(shí)需要依賴(lài)其他服務(wù)就緒的情況，比如等待數(shù)據(jù)庫(kù)就緒等

或者某些容器服務(wù)初始化時(shí)間較長(zhǎng)，另外的容器需要等它就緒等

https://github.com/SixQuant/e...