鏈接不上Docker-Kafka-broker及Kafka解決內網外網隔離的幾個重要參數

1.背景

像以前的大數據環境等都是經過Docker來搭建的，不管是在學習，測試，遷移時候無疑是最快的方式，尤爲是在多個環境下還想使用同一套環境時候,https://github.com/hulichao/docker-bigdata,搭建思路，能夠參考本倉庫，通常狀況下只要注意比虛擬機要多作個端口映射等，端口映射也即網絡方面，實際上是相對冗餘的，因此在搭建kafka的環境時候正好遇到了下面的問題，以下圖connection to node 0 colud not be establised. Broker may not be avaliable

kafka連不上broker，在虛擬機的機器上沒問題，可是本地使用idea鏈接是有問題的。

2.思路

是過後寫的博客，因此當時的一些排查問題的截圖，不一一貼出來了，只簡述一下過程和最終解決，以及引出kafka對內外網隔離時候的解決方式

2.1 首先排查各類網絡問題

好比虛擬機網絡，使用ping www.baidu.com 再檢查端口使用telnet linux121 9092 發現都沒有問題，另外查了Docker的虛擬網卡，能夠參考另一篇文章，https://blog.csdn.net/hu_lichao/article/details/109538567，發現也沒有問題

2.2 而後開始考慮是Kafka的問題

原本沒有往這個方向想，最後只好藉助google, 輸入關鍵字 kafka docker idea 連不上Broker ,以下圖

而後參考第一條，讀取關鍵的信息：Kafka的客戶端（生產者與消費者統稱）要鏈接 Broker 須要通過一層認證，不經過認證就沒法鏈接！ 而後繼續往下讀，客戶端鏈接Kafka須要兩層認證，其一是Zk上的Broker中的advertised.listeners 配置的鏈接和端口，注意：這裏較坑的一點就是，必須原樣比對 PLAINTEXT 中的內容要和Java程序中的要對應，即不考慮你是怎麼拿到虛擬機中的Docker中的kafka的鏈接，總之你要發送的bootstrap.servers 的內容要和PLAINTEXT 要一致，這就須要配置linux121 的hosts，映射到實際的ip和端口了。

java代碼

zk獲取broker信息

kafka的server.properties的配置

3.Kafka的內外網參數

根據前面的排查問題，有兩個重要參數，listeners和advertise.listeners 那這兩個參數是作什麼用的呢，這裏拿來官方的翻譯，

用於指定當前Broker向外發佈服務的地址和端口。與 advertised.listeners 配合，用於作內外網隔離。

下面介紹幾個相關參數：

listener.security.protocol.map

內外網隔離配置：監聽器名稱和安全協議的映射配置。好比，能夠將內外網隔離，即便它們都使用SSL。listener.security.protocol.map=INTERNAL:SSL,EXTERNAL:SSL 注意，每一個監聽器的名稱只能在map中出現一次。
inter.broker.listener.name

用於配置broker之間通訊使用的監聽器名稱，該名稱必須在advertised.listeners列表中。例如inter.broker.listener.name=EXTERNAL
listeners

用於配置broker監聽的URI以及監聽器名稱列表，使用逗號隔開多個URI及監聽器名稱。
若是監聽器名稱表明的不是安全協議，必須配置listener.security.protocol.map。
每一個監聽器必須使用不一樣的網絡端口。
advertised.listeners
須要將該地址發佈到zookeeper供客戶端使用，若是客戶端使用的地址與listeners配置不一樣。
能夠在zookeeper的 get /brokers/ids/<broker.id> 中找到。

在IaaS環境，該條目的網絡接口得與broker綁定的網絡接口不一樣。
若是不設置此條目，就使用listeners的配置。跟listeners不一樣，該條目不能使用0.0.0.0網絡端口。
advertised.listeners的地址必須是listeners中配置的或配置的一部分。

注意：INTERNAL 和 EXTERNAL的做用就是至關於給PLAINTEXT協議起了兩個別名，默認map中只能有一個同名的協議，故分開寫

下面是一個典型的經常使用配置：

以上是使用wolai筆記寫的，能夠使用個人邀請碼DJED4WI進行註冊喲，名額有限，來搶啦！

4.參考

• https://www.cnblogs.com/hellxz/p/why_cnnect_to_kafka_always_failure.html