如何用Rancher實現consul的服務發現

如何使用Docker、Docker-Compose和Rancher搭建部署Pipeline，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

我們將討論如何用Rancher實現consul的服務發現。

在這構建部署流水線系列的最后一篇文章中，我們將探討在轉換到Rancher進行集群調度時面臨的一些挑戰。在之前的文章中，我們通過使用Rancher執行調度，讓運維人員無須再負責選擇每一次容器運行的位置。要使用這個新方案，我們必須讓環境的其他部分知道調度程序放置這些服務的位置，以及如何訪問它們。我們還將討論如何使用標簽來操作調度程序，以調整容器放置位置，并避免端口綁定沖突。最后，我們將通過利用Rancher的回滾功能優化我們的升級過程。

在引入Rancher之前，我們的環境是一個相當靜態的環境。我們總是將容器部署到相同的主機上，而部署到不同的主機則意味著我們需要更新一些配置文件以反映新位置。例如，如果我們要添加'java-service-1'應用程序的一個附加實例，我們還需要更新load balancer以指向附加實例的IP。使用調度器讓我們無法預測容器部署的位置，并且我們需要動態配置環境，使其能自動適應變化。為此，我們需要使用服務注冊和服務發現。

服務注冊表為我們提供了應用程序在環境中的位置的單一來源。和硬編碼服務位置不同，我們的應用程序可以通過API查詢服務注冊表，并在我們的環境發生變化時自動重新配置。Rancher使用Rancher的DNS和元數據服務提供了開箱即用的服務發現。然而，混合使用Docker和非Docker應用程序時，我們不能完全依賴Rancher來處理服務發現。我們需要一個獨立的工具來跟蹤我們所有服務的位置，consul就符合這個要求。

我們不會詳細說明如何在您的環境中設置Consul，但是，我們將簡要描述我們在ABC公司使用Consul的方式。在每個環境中，我們都有一個部署為容器的Consul集群。我們在環境中的每個主機上都部署一個Consul代理，如果主機正在運行Docker，我們還會部署一個注冊器容器。注冊器監視每個守護進程的Docker事件API，并在生命周期事件期間自動更新Consul。例如，在新容器被部署后，注冊器會自動在Consul中注冊該服務。當容器被刪除時，注冊器撤銷它的注冊。

Consul服務列表

在Consul中注冊所有服務后，我們可以在負載均衡器中運行consul-template，根據Consul中存儲的服務數據動態填充上游列表。對于我們的NGINX負載均衡器，我們可以創建一個模板來填充’java-service-1’應用程序的后端：

# upstreams.conf
upstream java-service-1 { 
{{range _, $element := service "java-service-1"}}    
       server {{.Address}}:{{.Port}}; 
{{else}}     
       server 127.0.0.1:65535; # force a 502{{end}} }

此模板在Consul中查找注冊為“java-service-1”的服務的列表。然后它將循環該列表，添加具有該特定應用程序實例的IP地址和端口的服務線。如果在Consul中沒有注冊任何“java-service-1”應用程序，我們默認拋出502以避免NGINX中的錯誤。

我們可以在守護進程模式下運行consul-template，使其監控Consul的更改，在發生更改時重新渲染模板，然后重新加載NGINX以應用新配置。

TEMPLATE_FILE=/etc/nginx/upstreams.conf.tmpl
RELOAD_CMD=/usr/sbin/nginx -s reload 
consul-template -consul consul.stage.abc.net:8500 \     
       -template "${TEMPLATE_FILE}:${TEMPLATE_FILE//.tmpl/}:${RELOAD_CMD}"

通過使用我們的負載均衡器設置來動態地改變其余的環境變化，我們可以完全依賴Rancher調度器來做出我們的服務應該在哪里運行的復雜的決定。但是，我們的“java-service-1”應用程序在Docker主機上綁定TCP端口8080，如果在同一主機上調度了多個應用程序容器，則會導致端口綁定沖突并最終失敗。為了避免這種情況，我們可以通過調度規則來操作調度器。

通過在docker-compose.yml文件中使用容器標簽來提出條件，是Rancher給我們的一種操作調度器的方法。條件可以包括親和規則、否定、至“軟”強制（意味著盡可能地避免）。在我們使用'java-service-1'應用程序的情況下，我們知道在給定時間只有一個容器可以在主機上運行，因此我們可以基于容器名稱設置反關聯性規則。這將使調度程序查找一個未運行名稱為“java-service-1”的容器的Docker主機。我們的docker-compose.yml文件看起來像下面這樣：

java-service-1:   
   image: registry.abc.net/java-service-1:${VERSION}   
   container_name: java-service-1   
   ports:    
         - 8080:8080   
    labels:     
         io.rancher.scheduler.affinity:container_label_ne: io.rancher.stack_service.name=java-service-1

注意“標簽”鍵的引入。所有調度規則都作為標簽被添加。標簽可以被添加到Docker主機和容器。當我們在Rancher注冊我們的主機時，我們可以將它們與標簽關聯，以后就可以切斷調度部署。例如，如果我們有一組使用SSD驅動器進行存儲優化的Docker主機，我們可以添加主機標簽storage=ssd。

Rancher主機標簽

需要利用優化存儲主機的容器可以添加標簽來強制調度程序僅在匹配的主機上部署它們。我們將更新我們的“java-service-1”應用程序，以便只部署在存儲優化的主機上：

java-service-1:   
    image: registry.abc.net/java-service-1:${VERSION}   
    container_name: java-service-1   
    ports:    
         - 8080:8080   
    labels:     
         io.rancher.scheduler.affinity:container_label_ne: io.rancher.stack_service.name=java-service-1     
         io.rancher.scheduler.affinity:host_label: storage=ssd

通過使用標簽，我們可以根據所需的容量，而不是個別主機運行特定的容器集，來精細地調整我們的應用程序部署。切換到Rancher進行集群調度，即使您仍然有必須在特定主機上運行的應用程序。

最后，我們可以利用Rancher的回滾功能優化我們的服務升級。在我們的部署工作流中，通過調用rancher-compose來指示Rancher在該服務堆棧上執行升級以部署服務。升級過程大致如下：

• 通過拉取一個新的鏡像來啟動升級

• 逐一地，現有容器被停止并且新容器被啟動

• 部署程序登錄到UI并選擇“完成升級”時，升級完成，

• 已停止的舊服務容器被刪除

Rancher升級

當給定服務的部署非常少時，此工作流就好了。但是，當某個服務處于“升級”狀態（在部署者選擇“完成升級”之前）時，在執行“完成升級”或是“回滾”操作之前，你都不能對它進行任何新的升級”。rancher-compose實用程序讓我們可以選擇以編程方式選擇要執行的操作，以部署程序者的身份執行操作。例如，如果您對服務進行自動測試，則可以在rancher-compose升級返回后調用此類測試。根據這些測試的狀態，rancher-compose可以被再次調用，這次我們告訴堆棧“完成升級”或“回滾”。我們部署Jenkins作業的一個原始示例可能如下：

# for the full job, see part 3 of this series
/usr/local/bin/rancher-compose --verbose \   
    -f ${docker_dir}/docker-compose.yml \   
    -r ${docker_dir}/rancher-compose.yml \   
    up -d --upgrade 
JAVA_SERVICE_1_URL=http://java-service-1.stage.abc.net:8080/api/v1/status 
if curl -s ${JAVA_SERVICE_1_URL} | grep -q "OK"; then   
   
# looks good, confirm or "finish" the upgrade   
    /usr/local/bin/rancher-compose --verbose \    
         -f ${docker_dir}/docker-compose.yml \     
         -r ${docker_dir}/rancher-compose.yml \     
         up --confirm-upgrade 
else   

     # looks like there's an error, rollback the containers   
     # to the previously deployed version   
     /usr/local/bin/rancher-compose --verbose \     
        -f ${docker_dir}/docker-compose.yml \     
        -r ${docker_dir}/rancher-compose.yml \     
        up --rollback 
fi

這個邏輯將調用我們的應用程序端點來執行簡單的狀態檢查。如果輸出顯示的是‘OK’，那么我們完成升級，否則我們需要回滾到以前部署的版本。如果您沒有自動測試，另一個選擇是簡單地總是完成或“確認”升級。

# for the full job, see part 3 of this series
/usr/local/bin/rancher-compose --verbose \   
    -f ${docker_dir}/docker-compose.yml \   
    -r ${docker_dir}/rancher-compose.yml \   
    up -d --upgrade --confirm-upgrade

如果不久以后，您確定需要回滾，就使用相同的部署作業簡單地重新部署以前的版本。這確實不像Rancher的升級和回滾功能那么友好，但它通過使堆棧不處于“升級”的狀態來解鎖將來的升級。

當服務在Rancher中回滾時，容器將被重新部署到以前的版本。當使用通用標記如“latest”或“master”部署服務時，可能會出現意外的后果。例如，讓我們假設'java-service-1'應用程序以前被部署了標簽'latest'。對圖像進行更改，推送到注冊表，Docker標簽“latest”被更新為指向此新映像我們使用標簽“latest”繼續升級，在測試后決定應用程序需要回滾。使用Rancher滾動堆棧仍然會重新部署最新的映像，因為標簽“latest”尚未被更新為指向上一個映像。回滾可以在純技術術語中實現，但是部署最近的工作副本的預期效果完全無法實現。在ABC公司，我們通過始終使用與應用程序版本相關的特定標記來避免這種情況。因此，不要使用標記latest”部署我們的“java-service-1”應用程序，我們可以使用版本標簽“1.0.1-22-7e56158”。這保證回滾將始終指向我們的應用程序在環境中的最新工作部署。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。