一種Docker容器主動負載均衡裝置及方法與流程

2023-05-09 01:34:12

本發明關於網際網路技術領域，特別是涉及一種Docker容器主動負載均衡裝置及方法。

背景技術：

Docker是一個開源的應用容器引擎，單實例運行Docker容器無法滿足生產需要，行業內一般會採用Docker集群的模式對外提供服務，目前較多採用開源容器集群管理的系統如kubernetes、mesos、swarm等並結合基礎網絡解決方案如flannel、weave、pipework等，解決Docker集群面臨問題，但Docker容器集群的負載均衡一直未能有完美的解決方案。

Docker容器發現目標是將隱藏在Docker容器內部的服務展現出來，減少或消除Docker容器之間通信壁壘。

Docker容器集群負載均衡目的是通過Docker容器發現將運行正常的容器統一通過負載均衡器轉發，調用者對負載均衡器後端的容器透明無感知。一種Docker容器主動負載均衡目的是當Docker容器啟動成功時應用名稱、Docker容器IP位址、應用埠等信息自動推送，並將Docker容器實例掛載到負載均衡器，從而使得該Docker容器實例提供服務能力，全程不需要人工幹預。調用者在可以完全不用理會後端Docker容器運行細節包括Docker容器個數、ip及埠，還包括是否是在物理機還是虛擬機下運行，只要有一個正常運行的容器，便可對外提供服務，對用戶完全透明。 同時對於異常的服務，整個系統要能及時響應處理，將異常Docker實例從負載均衡器列表剔出。

目前，常見的一種Docker集群的負載均衡方案如kubernetes提供有三種模式的負載均衡：1、使用宿主機IP+PORT的方式，這種方式需要將宿主機的IP暴露給調用者，特別是當宿主機宕機後，還需要調用者切換到其他宿主機；2、使用原生自帶的Service的方式並以private IP對外提供服務，這種方式需要調用者必須也在kubernetes集群內部，否則privateIP無法訪問；3、使用GCE、AWS等IaaS環境下專用負載均衡，這種方式大多數企業都不具備，所有這些都不能滿足生產對高可用的需要。

顯而易見地，基於常見的Docker集群負載均衡方案往往依賴於集群管理系統，集群管理系統的變化或升級會導致原有方法的失效；或存在多次時延性能較低，不僅監控Docker容器的啟動、停止變化等信息，還要將信息同步刷新負載均衡器；或由於採用專用負載均衡器，對學習、維護成本要求較高，不適宜技術沉澱，增加企業成本；或當服務運行多種環境下如Docker環境、vmware、kvm或獨立運行在宿主機環境時，無法滿足異構環境的需要。

技術實現要素：

為克服上述現有技術存在的不足，本發明之目的在於提供一種Docker容器主動負載均衡裝置及方法，以實現實時主動發現與註冊機制，並採用通用的負載均衡器，為Docker容器集群提供服務，保證對應用無侵入，方便系統進行容器化改造。

為達上述及其它目的，本發明提出一種Docker容器主動負載均衡裝置，包括：

鏡像轉換模塊，用於提供包含應用管理器的Docker基礎鏡像並將待執行應用轉換為Docker鏡像；

應用管理器，用於啟動該Docker鏡像，並根據預設應用信息，解析並執行該待執行應用的啟動命令，並發送註冊請求，將該應用註冊到分布式協調伺服器；

分布式協調伺服器，用於部署分布式協調服務；

探測器，用於對該分布式協調伺服器上的應用變化情況進行監聽，將應用變化情況發送至負載均衡代理器；

負載均衡代理器，將所述應用變化情況根據配置模版轉換一定格式的配置數據並執行，並配置到通用負載均衡器；

通用負載均衡器，用於部署通用負載均衡服務。

進一步地，該鏡像轉換模塊包括：

基礎鏡像， 用於預先存放該應用管理器與待執行應用需要的基礎環境構建的Docker鏡像，並將此鏡像作為待執行應用的基礎鏡像，並存放在鏡像倉庫；

命令接收模塊，用於接收該待執行應用的標識信息；

鏡像構建模塊，通過Dockerfile構建待執行應用鏡像，並上傳至鏡像倉庫。

進一步地，該應用管理器包括：

參數解析模塊，用於解析預設的應用信息；

命令執行模塊，用於接收該參數解析模塊解析出的應用執行命令，執行該命令並獲取命令執行結果，若執行結果若正常，則調用應用註冊模塊；

應用註冊模塊，用於獲取該參數解析模塊解析出的數據以及獲取待執行應用的狀態信息，並與該分布式協調伺服器建立臨時會話連結，將該應用的狀態詳情註冊到該分布式協調伺服器；

健康檢查模塊，用於根據預設的健康檢查命令輪詢應用的健康情況，並將結果通知該應用註冊模塊。

進一步地，當該Docker容器通過該應用註冊模塊註冊到該分布式協調伺服器時，判斷該分布式協調伺服器目錄有無該應用相對應的目錄，若無，則在分布式協調伺服器創建新的目錄並同時在該目錄創建一個新的節點。

進一步地，該探測器包括：

監聽模塊，用於對在該分布式協調伺服器上的應用變化情況進行監聽，若應用對應的Docker容器實例狀態發生變化則觸發第一發送模塊；

第一發送模塊，用於將應用變化情況發送至負載均衡代理器。

進一步地，該負載均衡代理器包括：

第一接收模塊，與該第一發送模塊進行連接並維持心跳，該第一接收模塊接收該第一發送模塊發來的指令，並調用數據解析模塊；

數據解析模塊，根據此時的配置模版模塊的格式解析該指令，並傳入第二命令執行模塊；

配置模版模塊，其模版數據根據負載均衡代理器所代理的負載均衡器不同；

第二命令執行模塊，將數據寫入該通用負載均衡器配置文件目錄，執行該通用負載均衡器的重啟命令。

為達到上述目的，本發明還提供一種Docker容器主動負載均衡方法，包括如下步驟：

步驟一，接收待執行應用文件，預設待執行應用詳情；

步驟二，將所述待執行應用文件轉換為Docker鏡像；

步驟三，執行所述Docker鏡像中應用啟動命令；

步驟四，發送註冊請求，將該應用註冊到分布式協調伺服器；

步驟五，從分布式協調伺服器中獲取所述註冊信息，獲取應用實例對應容器的變化數據，並將該數據進行解析，通過配置模版，更新配置文件到通用負載均衡器。

進一步地，步驟五進一步包括：

監聽應用在分布式協調器的目錄節點，並將目錄節點的變化信息發送到負載均衡代理器；

根據配置模版將變化信息同步到通用負載均衡器。

進一步地，於步驟二中，將該待執行應用文件的標識信息按照規範寫入Dockerfile，將待執行應用基礎鏡像與待執行應用通過Dockerfile構建待執行應用鏡像。

進一步地，於步驟四中，該待執行應用的Docker容器與該分布式協調伺服器維持臨時會話，當應用異常時，立即斷開與該分布式協調伺服器的連結，並自動退出。

與現有技術相比，本發明一種Docker容器主動負載均衡裝置及方法，通過應用管理器向分布式協調伺服器發起連接並進行註冊應用容器信息，並對應用容器健康信息實時監控，並主動同步反饋到分布式協調伺服器，利用探測器根據分布式協調伺服器的信息主動更新到負載均衡器，成功的將Docker容器掛載到負載均衡器，充分利用通用負載均衡器成熟的生產和運維經驗，對於傳統應用Docker容器化改造，有效地降低改造成本，本發明由容器主動向負載均衡器發起連接並進行註冊，利用成熟穩定的負載均衡器，該過程無需預先配置均衡配置文件且不需要重新啟動負載均衡器，自動實現負載均衡，克服目前的容器中負載均衡方法難以適應雲計算系統中用於提供後端服務的、動態變化的容器集群的問題。

附圖說明

圖1為本發明第一實施例之一種Docker容器主動負載均衡裝置的系統架構圖；

圖2為本發明第二實施例之一種Docker容器主動負載均衡裝置的系統架構圖；

圖3為本發明第三實施例之一種Docker容器主動負載均衡方法的步驟流程圖；

圖4為本發明具體實施例提供的一種Docker容器主動負載均衡方法的流程圖。

具體實施方式

以下通過特定的具體實例並結合附圖說明本發明的實施方式，本領域技術人員可由本說明書所揭示的內容輕易地了解本發明的其它優點與功效。本發明亦可通過其它不同的具體實例加以施行或應用，本說明書中的各項細節亦可基於不同觀點與應用，在不背離本發明的精神下進行各種修飾與變更。

圖1為本發明第一實施例之一種Docker容器主動負載均衡裝置的系統架構圖。如圖1所示，本發明一種Docker容器主動負載均衡裝置，包括：鏡像轉換模塊101、應用管理器102、分布式協調伺服器103、探測器104、負載均衡代理器105以及通用負載均衡器106。

鏡像轉換模塊101，用於提供包含應用管理器的Docker基礎鏡像並將待執行應用轉換為Docker鏡像。

具體地說，鏡像轉換模塊101為一個部署成功的Docker環境，其包括基礎鏡像301、命令接收模塊302以及鏡像構建模塊303，在該模塊已預先存放了應用管理器與待執行應用需要的基礎環境構建的Docker鏡像，並將此鏡像作為待執行應用的基礎鏡像301，同時也存放在鏡像倉庫。使用ftp、tftp、scp、wget等方式將待執行應用將存放到鏡像轉換裝置相應的目錄。命令接收模塊302接收用戶輸入將待執行應用的標識信息，該待執行應用的標識信息包括應用名、應用啟動、停止命令、埠、應用附加信息以及健康檢查命令等信息，並解析與本地預存Dockerfile模版，形成新的Dockerfile，鏡像構建模塊303通過Dockerfile構建待執行應用鏡像，並上傳至鏡像倉庫，此時該應用鏡像至少包括了應用管理器、待執行應用以及相應的參數。

應用管理器102，用於啟動該Docker鏡像，並根據預設應用信息，解析出待執行應用的啟動命令，並執行該命令，並發送註冊請求，將該應用註冊到分布式協調伺服器。

具體地，應用管理器102包括參數解析模塊311、命令執行模塊312、應用註冊模塊313、健康檢查模塊314。其中參數解析模塊311負責解析預設的應用信息，該預設的應用信息包括：應用名、應用啟動、停止命令、埠、應用附加信息等，將應用執行命令包括應用啟動命令、應用停止命令傳遞給命令執行模塊312；命令執行模塊312，用於接收參數解析模塊311解析出的應用執行命令，執行該命令並獲取命令執行結果，若執行結果若正常，則調用應用註冊模塊313；應用註冊模塊313獲取參數解析模塊311解析出的數據以及獲取待執行應用的狀態信息，並與分布式協調伺服器103建立臨時會話連結，將該應用的狀態詳情：容器狀態信息、容器IP、埠、應用名、應用附加信息註冊到分布式協調伺服器103，當發現應用異常比如宕機等現象，自動斷開與分布式協調伺服器103的連結。其中，當所述Docker應用啟動時，所述參數解析模塊312解析出所代理的應用的預設信息，調用命令執行模塊312執行應用啟動命令，並由應用註冊模塊313通知所述分布式協調伺服器103，在所述文件目錄下創建與所述待執行應用對應的文件夾。每當一個執行應用的Docker容器啟動成功後，應用註冊模塊313就會將應用信息註冊到分布式協調伺服器103對應應用下的文件夾作為應用節點實例。

詳細地，當Docker容器通過應用註冊模塊313註冊到分布式協調伺服器103時，判斷分布式協調伺服器103目錄有無該應用相對應的目錄，若無，則在分布式協調伺服器103創建新的目錄並同時在該目錄創建一個新的節點，容器的IP和應用埠即是該節點的名稱。當該應用有新的Docker實例產生，新的Docker實例都將註冊在該目錄下。當該應用的某個Docker實例宕機，則應用註冊模塊313自動斷開與分布式協調伺服器103的連接，同時分布式協調伺服器103刪除該Docker實例的註冊信息。

健康檢查模塊314主要並根據預設的健康檢查命令輪詢應用的健康情況，並將結果通知應用註冊模塊313。健康檢查模塊314主要檢查是否存在失效容器，失效容器可以是指不能提供正常服務的容器。例如，當健康檢查模塊314檢測容器發生了異常如容器與健康檢查模塊314不能健康心跳、容器進程意外停止等現象，即該容器不能提供服務，此時可以認為該容器為失效容器。可選的，對於任意一個容器，可以監測該容器與健康檢查模塊314的通信連接是否斷開，若健康檢查模塊314監測到該容器為失效容器。健康檢查模塊314通知應用註冊模塊313將自動與分布式協調伺服器103斷開連結，從而使分布式協調伺服器103將該失效容器節點刪除。

分布式協調伺服器103，用於部署分布式協調服務。在本發明具體實施例中，分布式協調伺服器103可以有一個或多個，當有多個分布式協調伺服器103時，該多個分布式協調伺服器103用於形成分布式協調服務組，並且可以從該多個分布式協調伺服器103中選出一個leader(領導者)，其中，分布式協調伺服器103用於部署分布式協調服務。本實施例中部署zookeeper作為分布式協調伺服器，zookeeper是一個開源的分布式協調伺服器。它是一個為分布式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分布式同步、組服務等等。特別注意的是當zookeeper目錄節點中存儲的數據的修改，子節點目錄的變化等，一旦變化可以通知設置監控的客戶端，這個功能是zookeeper對於應用最重要的特性，通過這個特性可以實現的功能包括配置的集中管理，集群管理，分布式鎖等等。此處，主要使用了zookeeper中的配置維護和分布式同步這兩項功能，其中，在所述分布式協調伺服器103中維護一個文件目錄，該文件目錄中存在與所述多個應用分別對應的文件夾。即，該文件目錄下存在多個文件夾，每個文件夾對應一個應用，每個文件夾下至少有一個節點，每個節點對應一個Docker容器實例。從而可以通過zookeeper的文件夾和節點來管理應用以及應用的Docker實例，就可以實現對Docker容器狀態變化管理，即實現對Docker容器的發現。

例如，預設/apps/catalog為所有應用的父目錄，若預設信息中應用名為helloworld，埠為8080，該應用對應一個Docker實例，且該容器IP為172.17.0.2，則該應用對應zookeeper的目錄為/apps/catalog/helloworld，該Docker實例對應的zookeeper節點為/apps/catalog/helloworld/172.17.0.2：8080，若該應用又新增一個Docker實例且Docker容器IP為172.17.0.3，則該應用zookeeper節點目錄為/apps/catalog/helloworld/172.17.0.2：8080和/apps/catalog/helloworld/172.17.0.3：8080。若所述IP為172.17.0.3的Docker容器宕機，則該應用對應的節點變為/apps/catalog/helloworld/172.17.0.2：8080。藉助於zookeeper的文件目錄和節點與應用和Docker實例的對應關係，可以實現一個應用對應一個目錄，一個Docker容器對應一個目錄節點的對應關係。

探測器104，用於監控分布式協調伺服器103中對應的所有應用文件夾。該文件夾的文件夾名稱對應應用名稱，每一個應用唯一對應一個以應用名為文件夾名稱的文件夾。探測器104包括監聽模塊331以及第一發送模塊，在本具體實施例中，在啟動待執行應用的Docker實例後，可以將該Docker實例詳情註冊到該分布式協調伺服器103，監聽模塊331檢測到應用目錄/apps/catalog發生了變化，並讀取應用目錄/apps/catalog的節點詳情，由第一發送模塊332發送相應的指令通知負載均衡代理器105新增一個應用實例信息，對通用負載均衡器106更新配置。可選地，當待執行應用的其中一個Docker實例停止或宕機，健康檢查模塊314檢測到該實例發生異常，通知應用註冊模塊313斷開與分布式協調伺服器103的連結，分布式協調伺服器103刪掉此目錄節點信息，此時監聽模塊331立即檢測到應用目錄/apps/catalog目錄發生了變化，通知負載均衡代理器105刪除一個，對通用負載均衡器106更新配置。

負載均衡代理器105，用於通過配置模版，更新配置文件到通用負載均衡器106。

具體地，負載均衡代理器105包括第一接收模塊341、數據解析模塊342、配置模版模塊343、第二命令執行模塊344。負載均衡代理器105和通用負載均衡器部署106在同一伺服器。第一接收模塊341通過TCP協議與第一發送模塊332進行連接並維持心跳，第一接收模塊341接收第一發送模塊332發來的指令，並調用數據解析模塊342。數據解析模塊342根據此時的配置模版模塊343的格式解析該指令，配置模版模塊343中模版數據根據負載均衡代理器105所代理的負載均衡器不同，模版數據各有不同，比如nginx適用的配置與lvs、keepalived適用的配置各不相同，數據解析模塊342按模版數據成功將指令解析後，放入臨時內存區域，調用第二命令執行模塊344。第二命令執行模塊344預設通用負載均衡器106配置文件路徑、啟動、停止、重啟命令並賦予執行通用負載均衡器106控制權限，當數據解析模塊342將解析出的數據傳入第二命令執行模塊344後，第二命令執行模塊344讀取上述臨時內存區域將數據寫入通用負載均衡器106配置文件目錄，執行通用負載均衡器106的重啟命令。

通用負載均衡器106，用於部署通用負載均衡服務。在本實施例中，通用負載均衡器106可以位於獨立的伺服器中，也可以位於由若干伺服器構成的伺服器集群中。比如nginx和lvs是開源的軟負載均衡器，目前行業已積累較多的生產經驗，對於企業的研發、運維及學習成本大大降低。nginx與lvs不同之處，lvs在處理四層流量時有顯著的性能表現但對網絡要求比較高，nginx常用於七層負載均衡，對網絡環境要求較低。由於通用負載均衡器106是本領域技術人員熟悉的，在此不再贅述。

在本發明中，應用管理器與待執行應用也可以運行在非Docker容器環境，或在容器環境下一起實現應用集群的負載均衡。如圖2所示為本發明第二實施例之一種Docker容器主動負載均衡的裝置的系統架構圖，其中，應用管理器203預先設置應用信息：應用名、應用啟動、停止命令、埠、應用附加信息等，應用管理器203啟動後，由參數解析模塊解析應用詳情，並啟動待執行應用204，當待執行應用204啟動成功後，由應用管理器203將應用實例的狀態信息、宿主機IP、埠、應用名、應用附加信息註冊到分布式協調伺服器205。不同的是：1、應用實例由容器IP變成宿主機IP，2、同一個宿主機運行的應用實例埠不能相同，之後各模塊的處理過程與第一實施例基本一致，不再贅述。

圖3為本發明第三實施例之一種Docker容器主動負載均衡方法的步驟流程圖。如圖3所示，本發明一種Docker容器主動負載均衡方法，包括如下步驟：

步驟301，接收待執行應用文件，預設待執行應用詳情。其中所述待執行應用詳情包括應用啟動命令、停止命令、應用名稱，版本號，應用附加信息（TCP/HTTP），以及應用埠信息。

步驟302，將所述待執行應用文件轉換為Docker鏡像。具體地，將待執行應用文件的標識信息，例如應用名稱、應用啟動命令、停止命令、埠、應用附加信息以及健康檢查命令等按照規範寫入Dockerfile，將待執行應用基礎鏡像與待執行應用通過Dockerfile構建待執行應用鏡像，即Docker鏡像。

步驟303，執行所述Docker鏡像中應用啟動命令。也就是說，當待執行應用已成功構建為Docker鏡像時，啟動該鏡像，並根據預設應用信息，解析出待執行應用的啟動命令，並執行該命令。

步驟304，發送註冊請求，將該應用註冊到分布式協調伺服器。所述註冊請求中攜帶有所述Docker容器中應用信息的容器IP、應用埠信息、應用名稱、應用附加信息等。在本發明具體實施例中，此時分布式協調伺服器創建一個以應用名為名稱的目錄，並在該目錄下創建一節點，其中該節點的名稱為容器IP和埠，如172.17.0.2:8080，其他信息如應用附加信息存儲在該節點內。待執行應用的Docker容器與分布式協調伺服器維持臨時的session會話，當應用異常時，立即斷開與分布式協調伺服器的連結，並自動退出。由於與分布式協調服務採用臨時的session會話，該臨時會話一旦斷開，分布式協調伺服器並即刻刪除該節點所有信息。

步驟305，從分布式協調伺服器中獲取所述註冊信息，即應用實例對應容器的變化數據 ，並將該數據進行解析，通過配置模版，更新配置文件到負載均衡器。具體地，步驟305進一步包括：

步驟S1，監聽應用在分布式協調器的目錄節點，並將節點的變化信息發送到負載均衡代理器。根據上述步驟S304得知，新增應用已成功在分布式協調伺服器註冊為一個目錄，主動讀取該目錄下的節點信息，一旦檢測該目錄下有新增節點註冊，發送指令給下遊模塊即負載均衡代理器，所述指令攜帶目錄名（也即是應用名），該目錄下所有節點名稱（也即是節點實例地址）及附加信息；

步驟S2，根據配置模版將變化信息同步到負載均衡器，如nginx、lvs。根據上述步驟S1得知，負載均衡器代理器接收步驟S1發送的指令包括了應用下所有節點信息，則負載均衡代理器根據配置模版相關參數即轉化為負載均衡器識別的參數，並寫入相應的配置文件，其中負載均衡代理器應預設負載均衡器配置文件路徑、啟動、停止、重啟命令。在本發明具體實施例中，所述配置模版根據選用的負載均衡器而各有差別。

圖4為本發明具體實施例提供的一種Docker容器主動負載均衡方法的流程圖，如圖4所示，該方法可以包括：

步驟S401，預設應用信息，將待執行應用構建為一個新的鏡像。具體地，將待執行應用的標識信息：應用名、應用啟動、停止命令、埠、應用附加信息以及健康檢查命令按照規範寫入Dockerfile，將待執行應用基礎鏡像與待執行應用通過Dockerfile構建待執行應用鏡像。

步驟S402，在分布式協調伺服器中部署分布式協調伺服器,如zookeeper。分布式協調伺服器可以是單節點或集群模式。特別地，當分布式協調伺服器一旦出現諸如目錄、子節點、數據等變化，可以主動通知監聽客戶端，通過這個特性可以實現當應用實例節點發生變化可立即通知下遊模塊進行及時處理。

步驟S403，通過上述步驟S401中所述，待執行應用已成功構建為Docker鏡像，啟動該鏡像，並根據預設應用信息，解析出待執行應用的啟動命令，並執行該命令，然後根據預設應用健康檢查語句定期檢查應用健康度。

步驟S404，當待執行應用成功啟動後，將該應用的狀態詳情包括：容器狀態信息、容器IP、埠、應用名、應用附加信息註冊到上述步驟S402已經部署成功的分布式協調伺服器，此時分布式協調伺服器創建一個以應用名為名稱的目錄，並在該目錄下創建一節點，其中該節點的名稱為容器IP和埠，如172.17.0.2:8080，其他信息如應用附加信息存儲在該節點內。待執行應用的Docker容器與分布式協調伺服器維持臨時的session會話，當應用異常時，立即斷開與分布式協調伺服器的連結，並自動退出。由於與分布式協調服務採用臨時的session會話，該臨時會話一旦斷開，分布式協調伺服器並即刻刪除該節點所有信息。

步驟S405，在通用負載均衡器部署負載均衡服務如nginx、lvs。負載均衡器與各個節點、各個節點容器網絡保證互聯互通，基於容器互通的網絡方案可以採用埠映射、直接路徑或覆蓋網絡的方式，所述網絡方案是本領域技術人員熟悉的，在此不再贅述。

步驟S406，監聽應用在分布式協調器的目錄節點，並將節點的變化信息發送到負載均衡代理器。根據上述步驟S404得知，新增應用已成功在分布式協調伺服器註冊為一個目錄，主動讀取該目錄下的節點信息，一旦檢測該目錄下有新增節點註冊，發送指令給下遊模塊即負載均衡代理器，所述指令攜帶目錄名（也即是應用名），該目錄下所有節點名稱（也即是節點實例地址）及附加信息。

步驟S407，根據配置模版將變化信息同步到負載均衡器如nginx、lvs。根據上述步驟S406得知，負載均衡器代理器接收步驟S406發送的指令包括了應用下所有節點信息，則負載均衡代理器根據配置模版相關參數即轉化為負載均衡器識別的參數，並寫入相應的配置文件。其中負載均衡代理器應預設負載均衡器配置文件路徑、啟動、停止、重啟命令。

上述方法使應用在Docker環境下的運行情況時刻反饋到負載均衡系統上，通過採用了通用的負載均衡器和主動註冊的機制，從而將應用調用者從多變、複雜Docker容器地址轉換為訪問固定的負載均衡器地址，全程自動發現、自動註冊，對調用者無感知，而且應用管理器同時也可以與待執行應用在宿主機或虛擬機環境下同樣適用。

相對與上述實施例，進一步地，本實施例中S401中在該裝置已預先將程序管理器與待執行應用需要的基礎環境構建為新的Docker鏡像作為待執行應用的基礎鏡像步驟之前還包括：從鏡像倉庫中獲取待執行應用需要的基礎環境。具體地，鏡像倉庫用於存儲鏡像文件，包括待執行應用需要的基礎環境、待執行應用的基礎鏡像、待執行應用鏡像，新構建鏡像統一存儲到鏡像倉庫。本實施例中，鏡像轉換裝置、各節點與鏡像倉庫建立通訊連接。

綜上所述，本發明一種Docker容器主動負載均衡裝置及方法，利用應用管理器主動將容器變化信息註冊，同時利用探測器與分布式協調伺服器採用臨時會話機制，無需通過心跳方式實時對分布式協調伺服器進行監聽，一旦容器發現變化，通過利用負載均衡代理器將所述容器的變化信息寫入通用負載均衡器，本發明可適用於應用容器化改造，對現有應用無約束和限制；能及時監聽容器變化情況而不需要採用心跳機制，從而避免了心跳造成的超時問題；選用通用工業化軟負載均衡器，對學習、使用、運維的成本要求較低，節省企業的研發和運維成本，本發明實施例中還闡述了在非容器環境下，通過應用管理器將待執行應用的變化情況同步到負載均衡器上，滿足應用在異構環境運行的需要。

上述實施例僅例示性說明本發明的原理及其功效，而非用於限制本發明。任何本領域技術人員均可在不違背本發明的精神及範疇下，對上述實施例進行修飾與改變。因此，本發明的權利保護範圍，應如權利要求書所列。