介紹

容器給尋找大規模設計與部署應用的需求提供了一個優雅的解決方案。在Docker提供實際的容器技術的同時，許多其他的項目也在協助開發在部署環境中所需要的引導和溝通的工具。

多種Docker環境依賴的核心技術之一是服務發現。服務發現可以讓一個應用或者組件發現其運行環境以及其它應用或組件的信息。它通常是采用的是分布式key-value的存儲方式，而且它還用來作為一般查詢配置細節信息的地方。用戶配置一個服務發現工具就可以將實際容器跟運行配置分離開，這樣用戶就可以在多個環境中復用同一個鏡像。

在這篇向導中，我們將討論在一個Docker集群環境中服務發現工具帶來的好處。主要關注在常規概念，在需要的地方會用詳細的例子來描述。

服務發現與全局可讀配置存儲

服務發現的基本思想是任何一個應用的實例能夠以編程的方式獲取當前環境的細節。這是為了讓新的實例可以嵌入到現有的應用環境而不需要人工干預。服務發現工具通常是用全局可訪問的存儲信息注冊表來實現，它存儲了當前正在運行的實例或者服務的信息。大多數情況下，為了使這個配置具有容錯與擴展能力，這個工具分布式地存儲在基礎設施中的多個宿主機上。

雖然服務發現平臺的初衷是提供連接信息來連接不同組件的，但是它們更普遍地是用來存儲任何類型的配置信息。許多部署工具通過寫入它們的配置信息給發現工具來實現這個特性。如果容器配置了這些，它們就可以去查詢這些預配置信息，并根據這些信息來調整自身行為。

服務發現是怎么工作呢?

每一個服務發現工具都會提供一套API，使得組件可以用其來設置或搜索數據。正是如此，對于每一個組件，服務發現的地址要么硬編碼到程序或容器內部，要么在運行時以參數形式提供。通常來說，發現服務用鍵值對形式實現，采用標準http協議交互。

服務發現門戶的工作方式是：當每一個服務啟動上線之后，他們通過發現工具來注冊自身信息。它記錄了一個相關組件若想使用某服務時的全部必要信息。例如，一個MySQL數據庫服務會在這注冊它運行的ip和端口，如有必要，登錄時的用戶名和密碼也會留下。

當一個服務的消費者上線時，它能夠在預設的終端查詢該服務的相關信息。然后它就可以基于查到的信息與其需要的組件進行交互。負載均衡就是一個很好的例子，它可以通過查詢服務發現門戶得到各個后端節點承受的流量數，然后根據這個信息來調整配置。

這可將配置信息從容器內拿出。一個好處是可以讓組件容器更加靈活，并不受限于特定的配置信息。另一個好處是使得組件與一個新的相關服務實例交互時變得簡單，可以動態進行調整配置。

配置存儲是如何關聯起來的?

全局分布式服務發現系統的一個主要優勢是它可以存儲任何類型的組件運行時所需的配置信息。這就意味著可以從容器內將更多的配置信息抽取出去，并放入更大的運行環境。

通常來說，為了讓這個過程更有效率，應用在設計時應該賦上合理的默認值，并且在運行時可以通過查詢配置存儲來覆蓋這些值。這使得運用配置存儲跟在執行命令行標記時的工作方式類似。區別在于，通過一個全局配置存儲，可以不做額外工作就能夠對所有組件的實例進行同樣的配置操作。

配置存儲如何幫助集群的管理?

在Docker部署中，分布式鍵值對存儲其中最初可能不太明顯的一個功能是對集群成員的存儲和管理。配置存儲是為了追蹤宿主機成員變更和管理工具的***環境。

一些可能會存在分布式鍵值對存儲中的個人宿主機信息是：

• 宿主機IP
• 宿主機自身的鏈接信息
• 跟調度信息有關的標簽或元數據信息
• 集群中的角色(如果是采用了主從模式的集群)

在正常情況下，使用一個服務發現平臺時，這些細節可能不是你需要考慮的。但是他們為管理工具提供了一個可以查詢或修改集群自身信息的地方。

#p#

故障檢測怎么實現?

故障檢測的實現方式也有很多種。需要考慮的是如果一個組件出現故障，服務發現能否更新狀態指出該組件不再提供服務。這種信息是至關重要的，關系到將應用或服務故障可能性降到***。

許多服務發現平臺允許賦值時帶一個可配置的超時時間。組件可以設置一個超時時間，并能定期去請求服務發現來重置超時時間。如果該組件出現故障，超時時間達到設定值，那么這個組件的連接信息就會從服務發現的存儲中被去掉。超時時間長度在很大程度上是它與應用需要多快去應對一個組件的故障的函數。

這也可以通過將一個基本的“助手”容器與每一個組件相連來實現,而它們唯一的責任是定期的健康檢查組件以及更新注冊表如果組件關閉。這種類型的架構值得擔憂是,如果輔助容器出現故障,將導致不正確的信息在存儲中。一些系統解決這個問題的方法是在服務發現的工具中定義健康檢查。這樣,發現平臺本身可以定期檢查已注冊組件是否仍然可用。

當細節變化時，配置服務會如何?

對于基本的服務發現模型來說，一個關鍵的改進就是動態重新配置。普通服務發現工具允許用戶通過檢查在啟動時的信息來影響組件的初始配置，而動態重新配置涉及配置組件來反映配置存儲中的新信息。例如，當你在運行一個負載均衡，后端服務器上的健康檢查可能會提示集群中的某一個成員出現故障了。運行中的成員機器需要知道這個信息，并調整配置信息和重新加載它的負載。

這個有多種方式實現。由于負載均衡的例子是這個功能的主要應用場景之一，許多現有的項目專注在當配置變動時重新配置負載均衡。常見的是HAProxy配置調整，這要歸結于在負載均衡領域內它的普遍性。

某些項目更加靈活，它們可在任何類型的軟件中被用來觸發變更。這些工具周期性的去請求服務發現工具，并且當變更被發現，利用模板系統和服務發現工具中的值來生成新配置文件。當配置文件生成結束，相應的服務將被重新加載。

這種類型的動態配置在構建過程中需要更多的規劃和配置，因為這些所有的策略都需要存在于組件容器之中。這使得組件容器負責調整自身的配置。找出需要存在服務發現工具中的必要參數值并設計一個適當的數據結構以便使用，這是該系統的另一個技術挑戰，但是它可以帶來可觀的效益和靈活性。

安全方面如何?

許多人初次接觸全局配置存儲時擔心的一個問題是訪問的安全性。將連接信息存儲在全局可訪問的存儲中真的合適么?

這個問題的答案很大程度上依賴于你準備在存儲中存放的內容以及保護你的數據需要多少層的安全等級。幾乎所有的服務發現工具可以采用SSL/TLS 加密鏈接。對于一些服務，隱私性可能不是最重要的，而且發現服務放在內網中也可能讓人滿意。但是，大多數的應用會從它額外的安全性上獲益。

有許多不同的方法來解決這個問題，同時各種項目也都提供他們自己的解決方案。一個項目的解決方案是繼續允許開放發現服務平臺本身，但是對于寫入數據進行加密，使用者必須用相應的密鑰來解碼從服務發現中獲取的信息才能使用。其他組件不可以獲取到未加密的數據。

還有不同的方法，一些服務發現工具實現了訪問控制列表，將不同的鍵值切分到不同的分組中。他們可以根據訪問需要來制定不同的秘鑰來訪問相應的分組。這種簡單的方式既保證了能夠給特定組件提供信息又保證了對其他組件的不可訪問性。每個組件都可以被配置為只允許訪問它所需要的連接信息。

#p#

有哪些常見的服務發現工具?

既然我們已經討論了一些服務發現工具和全局分布式鍵值存儲的一般特點和功能，下面我們來介紹幾個與這些概念有關的項目。

一些常見的服務發現工具：

etcd：這是CoreOS的創建者提供的工具，面向容器和宿主機提供服務發現和全局配置存儲功能。它在每個宿主機上有基于http協議的API和命令行的客戶端。

consul：這個服務發現平臺有很多高級的特性，使得它脫穎而出，例如：配置健康檢查、ACL功能、HAProxy配置等等。

zookeeper：這個工具較上面兩個都比較老，提供一個更加成熟的平臺和一些新特性。

一些基本服務發現工具的擴展項目：

crypt：Crypt允許組件通過采用公鑰加密的方式來保護它們的信息。需要讀取數據的組件會被分配密鑰，而其他組件則不能讀取數據。

confd：Confd項目旨在基于服務發現的變化，而動態重新配置任意應用程序。該系統包含了一個工具來監測節點中的變化、一個模板系統來根據獲取到的值來生成配置文件，并能夠重新加載受影響的應用。

vulcand：Vulcand為成組的組件作為負載均衡使用。它使用etcd作為后端，并基于監測變更來調整它的配置。

marathon：雖然marathon主要是調度器(后續介紹)，它也實現了一個基本的重加載HAProxy的功能，當發現變更時它來協調可用的服務。

frontrunner：這個項目嵌入在marathon中對HAProxy的更新提供一個更穩定的解決方案。

synapse：這個項目引入了嵌入式的HAProxy組件，它能夠路由流量給各個組件。

nerve：它被用來與synapse結合一起來為各個組件提供健康檢查，如果組件不可用，nerve將更新synapse將該組件移除出去。

總結

服務發現工具和全局配置存儲使得Docker容器可以適應它們當前所處環境并嵌入現有的組件。這是一個重要的先決條件為的是提供方便、容易擴展和部署的功能，通過允許組件跟蹤和應對他們所在環境變化。

在下一個指南中，我們將探討Docker容器和宿主機之間用自定義的網絡配置進行通信。