最近，在TDengine的一個社區羣中突發了一場嚴重的灌水事件。幾位羣友不眠不休地聊天，能夠說是廢寢忘食。那麼究竟是什麼話題能讓他們凌晨四點還在忘我地討論？node
這個話題就是——如何完善Docker環境下TDengine的集羣搭建。git
「什麼？除了大家官方本身人以外，怎麼會有用戶加班加點地討論如何完善Docker環境的集羣搭建，這也太假了。」github
好吧，咱們認可：實際上是有一個叫Oliver（羣暱稱）的用戶遇到了這樣的問題——辛辛苦苦搭起來Docker環境下的TDengine集羣在客戶端連不上了。接下來，就引起了羣裏的二位熱心大佬的討論不休，直到想出最後的解決方案。數據庫
事情的通過是這樣的：服務器
該用戶的數據庫集羣裝在這臺Linux服務器上（ip:10.0.31.2），容器ip所在的網絡是由Docker在宿主機建立的虛擬網絡172.19.0.0/16。三個容器的hostname和節點ip分別：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。網絡
各個節點配置以下：tcp
taosnode1: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode1;端口映射：16030-16042:6030-6042（tcp/udp）taosnode2: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode2;端口映射：26030-26042:6030-6042（tcp/udp）taosnode3: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode3;端口映射：36030-36042:6030-6042（tcp/udp）
按照官方文檔的指示努力折騰一番後，Oliver終於搭起了這個集羣。添加完節點以後，他忐忑地敲下了「show dnodes」，隨着三個READY映入眼簾後———舒坦了。測試
服務端沒有問題，接下來該客戶端了。他打開了本身的一臺ip爲10.0.31.5（與集羣宿主機同一網段）的Windows主機，迅速地在上面安裝了個TDengine客戶端，添加hosts信息，作好路由，2.8MB，傻瓜式安裝，輕鬆便捷，鏈接集羣一鼓作氣。「show dnodes」隨着三個READY再次映入眼簾後———又舒坦了。大數據
Oliver十分滿意，然而，他立刻發現事情可能並不像想象中的那麼簡單。url
因爲業務須要，他還須要完成客戶端（10.0.2.61）跨網段鏈接服務端集羣（基於ip:10.0.31.2的Docker環境下的集羣）。
ping得通宿主機，telnet得通集羣映射出來的端口，使用taos鏈接集羣，同樣的操做也和此前同樣順利。因而他再次敲下「show dnodes」——萬萬沒想到，這時令全部TDengine用戶都深惡痛絕的「DB error：Unable to establish connection」出現了。因而，他便在羣中拋出了本身的問題。
上文說到的兩位熱心的同窗就是在這個時候出現的。一位是爲TDengine的外部Contributor——Freemine。另外一位是路見問題拔刀相助的熱心大佬pigwing。
因爲集羣自己沒有任何使用問題，惟一的區別就是客戶端鏈接服務器的方式變成了跨網段。因此，一開始你們的思路就是——既然走宿主機的端口不行，那就試試直接連到Docker環境下的ip吧。遺憾的是，跨網段鏈接Docker環境下內部ip的想法沒能實現。
接着你們推測：TDengine靠的是EndPoint（EP）來識別數據節點，而EP=FQDN+端口。可客戶端鏈接已經成功，只是沒法對數據操做，在FQDN無誤的狀況下，你們猜想是集羣內的端口出現了問題，從而沒拿到集羣的拓撲信息。
接下來，從最初的瞭解環境，到一步一步的排查問題，三個持之以恆的工程師在羣裏從4月22日討論到4月25，最晚的時候凌晨4點多都有人在線。
終於，在三人的通力合做屢次試錯下，4月24日凌晨1點——freemine提出了一個行之有效的最終解決方案（文字過多隻截圖關鍵部分）
大功告成，通過測試後，一切順利！
那麼，freemine的集羣搭建方案和最初的集羣搭建有什麼區別呢？
雖然過程曲折，可是最後咱們仔細對比一下二者的方案就會發現，它們的區別就只有在端口配置這一塊不同。freemine的方案是在每個單機的serverport都修改了不同的值。taosnode1節點的serverport爲6030---映射主機的6030端口；taosnode2節點的serverport爲7030--映射主機的7030端口；taosnode3節點的serverport爲8030–映射主機的8030端口。
而提問者Oliver最初的各個節點的serverport都是沒作修改的默認6030，映射到宿主機的時候是16030，26030，36030。就是這樣的配置在客戶端與集羣宿主機的同網段鏈接時並無發生問題，而是在跨網段鏈接時出現問題。
看起來一絲小小的改動竟然有這麼大的區別？Why？
實際上是這樣，當客戶端與服務端同屬一個網段的時候，在添加路由後，客戶端是能夠直接訪問到Docker內部的。這樣一來，IP地址就能夠根據須要被正確地解析出來。如：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。在不一樣的IP地址下，即使端口都是同樣的6030，TDengine仍是能夠完成不一樣節點的區分。
可是，當跨網段以後就不同了。對於不一樣網段的客戶端和服務端而言，客戶端要經過真實路由去鏈接服務端，但真實路由中並無註冊咱們設置的Docker內部網絡，因此客戶端天然就訪問不了Docker內部的網絡。所以，當taosc須要獲得集羣提供的不一樣節點的信息時，FQDN已經沒法正確解析IP地址了。這時候，就須要經過端口來實現不一樣節點的區分。
這就是不能再在Docker環境下的節點中同時使用6030端口的緣由。
所以，當你使用了Docker主機內外一致的端口映射，且每一個節點的serverPort參數不相同的設置時，集羣就能夠經過不一樣的端口來區分不一樣的節點。這樣一來，客戶端才能夠拿到拓撲信息進行集羣的順利操做。
這就是整個「案件」的最終答案。
總結一下，對於用戶使用而言，Docker環境下搭建TDengine集羣的水仍是頗深。因爲環境的相對複雜，因此咱們也並非十分推薦你們使用這種方式搭建集羣。因此，關於TDengine在Docker環境的使用，你們仍是要當心謹慎。
最後咱們想說的是，做爲一個開源的產品，社區的活躍與專業是咱們濤思數據最爲關注的地方。雖然目前官網上並無關於Docker環境下TDengine集羣搭建的文檔。可是這些社區用戶們的活躍思考顯然很大程度填補了這樣的一個空白。
真心感謝Oliver，freemine，pigwing三位朋友。十分但願往後能夠繼續看到大家在物聯網大數據技術前沿羣中的活躍身影，同時咱們也但願有更多的朋友們可以參與進來。
掃描二維碼，添加小T爲好友，便可與各位熱衷開源的朋友一塊兒在羣內互動哦～
點擊「這裏」，查看Oliver整理的TDengine在Docker環境下的集羣搭建筆記！