如何使用Docker、Docker-Compose和Rancher搭建部署Pipeline（三）
在這一部分，我們將一步步的走進Rancher，細緻的探討Rancher將如何解決在部署與容器管理時出現的種種的問題。回顧教程的第二部分，你會發現我們已經將應用的部署遷移至Docker Compose，並且已經建立了一系列工作步驟來部署我們的應用。這將使得開發人員能夠輕鬆的對他們的應用部署邏輯進行修正，運維人員也可以檢視應用的部署時間。當然，在上一個部分教程的一系列操作中，也存在一些顯而易見的問題需要解決。
使用Docker-Compose時面臨的挑戰
首先，運維人員必須手動地調整所有服務的執行計劃。部署人員需要決定將哪一個應用部署至哪一臺主機，這意味著部署人員需要時刻對每一臺主機的剩餘可用資源都有了解，如果某一臺主機或者容器崩潰了，部署的操作人員將需要對應用進行重新部署。實際生產中，這意味著主機常常處於負載失衡的狀態，並且服務在崩潰之後需要很長時間才能得到恢復。
其次，使用Docker-Compose時，想要獲得你的服務的當前狀態是十分困難的。舉個例子來說，我們經常會從運維人員、專案經理以及開發者口中聽到這樣的問題：“現在部署環境中執行的到底是XX應用程式的哪個版本？”如果我們採用的是手動調整服務的執行計劃的方式，想要得到這個問題的答案通常需要詢問指定的進行操作的工程師，工程師們需要登陸伺服器並執行docker中的ps命令來檢視容器的資訊。然而面對這些問題，Rancher將會給我們提供極大的便利：每個人都可以非常容易地獲取已經部署的服務的資訊，而不需要臨時請求運維人員的幫助。
使用Rancher之前，我們試著瞭解過不少其他能夠管理Docker主機或叢集的解決方案。然而這些解決方案都沒有注意到這是對Docker主機或叢集在多種環境（multi-environment）下的管理，這將成為最大的麻煩與負擔之一。如果有服務以不同的負載執行在8種不同的環境下，我們需要的是一個統一的方式來管理叢集，而不會想要訪問8個不同的服務。並且，我們希望讓重新構建環境對於我們而言，變成分分鐘就能完成的任務，這樣開發者就可以隨意地更改開發環境。然而，對於生產環境而言，我們希望提供給他們的只是有限的只讀訪問許可權。面對這樣的需求，一個採用基於角色的訪問控制（RBAC）模型的集中管理方案就顯得十分必要了。我們最初決定嘗試Rancher就是因為它在部署上非常簡單。
當Rancher面臨這些挑戰
在短短半天的時間裡，使用AWS ELB、Elasticache、RDS和現有的Docker主機，我們已經將Rancher部署好併成功執行。能夠方便地配置認證資訊也是Rancher的優點之一。
我們並不會深入Rancher本身部署的細節，Rancher部署文件中已經說的很明白了。相反，我們將從剛剛完成初始設定那一步開始，說明將如何將原有的設定（教程第一部分和第二部分中所提及的）遷移進來。
我們就從建立不同的環境開始吧，為了使得這個過程儘量簡單些，我們將對開發環境（dev）、部署環境（stage）以及生產環境（prod）分別進行設定。每個環境都已有執行在Ubuntu之上的Docker主機，且這些Docker主機是由內部的Ansible配置的，Ansible安裝了Docker、我們的監控代理、並進行了一些組織特定的更改。在Rancher上，你只需要執行一條命令，將Docker主機在Rancher server內部進行註冊，就可以將已有的Docker主機新增至每個環境中。
新增一臺Rancher主機
在大多數情況下，想要新增一臺主機需要經過一系列的操作：通過滑鼠在網頁上完成一些點選，接下來切換至某個特定的環境，最後在終端系統上輸入命令。然而，如果你使用Rancher API，我們可以在Ansible工具的幫助下使得這一系列的操作轉化為完全自動化的設定。出於好奇，在下面我們截取了playbook中有關這一操作的部分內容（大多是根據 Hussein Galas的repo中的內容做出的邏輯上的修改而得到的）。
name: install dependencies for uri module
apt: name=python-httplib2 update_cache=yes
name: check if the rancher-agent is running
command: docker ps –filter ‘name=rancher-agent’
register: containers
name: get registration command from rancher
uri:
method: GET
user: “{{ RANCHER_API_KEY }}”
password: “{{ RANCHER_SECRET_KEY }}”
force_basic_auth: yes
status_code: 200
url: “https://rancher.abc.net/v1/projects/{{ RANCHER_PROJECT_ID }}/registrationtokens”
return_content: yes
validate_certs: yes
register: rancher_token_url
when: “‘rancher-agent’ not in containers.stdout”
name: register the host machine with rancher
shell: >
docker run -d –privileged
-v /var/run/docker.sock:/var/run/docker.sock
{{ rancher_token_url.json[‘data’][0][‘image’] }}
{{ rancher_token_url.json[‘data’][0][‘command’].split() | last}}
when: “‘rancher-agent’ not in containers.stdout”隨著工作的一步步進行，我們已經完成了環境的建立並已經將主機在Rancher server中註冊，現在就讓我們來了解一下，如何將我們的部署工作流整合至Rancher中。我們知道，對於每一臺Docker來說，其中都有著一些正在執行的容器，這些系統的部署是通過Ansible工具藉助Jenkins完成的。Rancher提供了以下開箱即用的功能：
- 管理已有的容器（比如：啟動、修改、檢視日誌、啟動一個互動式的shell）
- 獲得關於執行中的和停止執行的容器的資訊（比如：映象資訊、初始化命令資訊、命令資訊，埠對映資訊以及環境變數資訊）
- 檢視主機和容器層級上的資源使用情況（比如：CPU使用率、記憶體佔用率、以及磁碟和網路的使用情況）
獨立的容器
很快，我們就已經將Docker主機註冊至Rancher Server中，現在我們可以檢視容器在各種環境下的執行狀態資訊了。不僅如此，如果想要將這些資訊分享給其他團隊，我們僅僅需要針對某個環境給予他們一些有限的許可權。通過以上的方式，在想要獲得狀態資訊時我們就完全沒有必要請求操作人員登入Docker主機，再通過人工的方式去查詢，同時這樣也減少了申請獲得環境資訊的請求的數目，因為我們已經將某些訪問許可權分配至各個團隊了。舉個例子來說，如果為開發團隊分配環境資訊的只讀許可權，那麼將會在開發團隊與部署操作團隊之間架起一座溝通的橋樑，這樣兩個團隊都會對這個環境的狀態比以往更加的關心。在這個基礎上，故障的排除也變成了一種小組間相互合作的過程，而不是以往的那種單向的、依賴同步資訊流的解決方式，相互合作的方式也會減少解決突發事件的總時間。
到現在為止，我們已經將已有的Docker主機加入Rancher Server，並且基於已經閱讀完了的教程的第一部分關於Jenkins和Rancher的內容，下一步，我們打算改進的部分是我們已有的部署流水線，我們將會對已有的部署流水線進行修改，以便於使用Rancher compose，Rancher Compose將代替之前Ansible工具提到的Docker compose。不過在我們深入下一部分之前，我們首先需要了解關於Rancher的應用、排程、Docker Compose和Rancher Compose的一些資訊。
應用與服務：Rancher將每個獨立的容器（指的是部署在Rancher之外的容器，或者是通過Rancher UI生成的一次性功能的容器）、應用和服務彼此分離開。簡單地說，應用是一組服務，而所有容器都需要利用服務（關於應用和服務的內容之後將會由更加詳細的介紹）以構建一個應用。獨立的容器需要手動地進行排程。
排程：在之前的部署技術中，運維人員需要決定容器應當在哪一臺主機上執行。如果使用的是部署指令碼，那麼意味著運維人員需要決定部署指令碼在哪一臺或哪幾臺主機上執行；如果使用Ansible，這將意味著運維人員需要決定哪些主機或組需要到Jenkins中工作。不論是哪一種方式，都需要運維人員去做一些決定，但是在大多數情況下，他們做出的決定都缺乏一些可靠的依據，這對我們的部署工作很是不利（比如說某一臺主機的CPU使用率高達100%）。很多解決方案，比如像Docker Swarm、Kubernetes、Mesos和Rancher都採用了排程器來解決這類問題。對於需要執行的某個操作，排程器將會請求獲得一組主機的資訊，並判斷出哪幾臺是適合執行這個操作的。排程器會根據預設的需求設定或者使用者定義的特定需求，比如CPU使用率高低、親和性或反親和性規則（比如：禁止在同一臺主機上部署兩個相同容器）等類似的需求，以逐漸縮小主機選擇的範圍。如果我是一個負責部署的運維人員，排程器將會極大的減少我的工作負擔（尤其是我在深夜加班忙於部署時），因為排程器對以上資訊的計算比我快的多，也準的多。Rancher在我們通過應用部署服務的時候能夠提供一個開箱即用排程器。
Docker compose：Rancher使用Docker compose來建立應用並定義服務。由於我們已經將服務轉化為Docker compose的檔案，我們在此基礎上建立應用就變得容易了許多。應用可以手動的從UI介面中建立，也可以通過Rancher compose在命令列（CLI）下快速的建立。
Rancher compose：Rancher compose是一種通過命令列（CLI）讓我們得以對Rancher中的每一種環境的應用和服務進行方便的管理的工具。同時，通過rancher-compse.yml檔案，Rancher compose還能允許對Rancher工具進行一些其他訪問。這是一個純粹的附加的檔案，將不會取代原有的docker-compose.yml檔案。在rancher-compose.yml檔案中，你可以定義以下內容，比如說：
- 每種服務的升級策略資訊
- 每種服務的健康檢查資訊
- 每種服務的需求規模資訊
這些都是Rancher中非常實用的亮點，如果你使用Docker Compose或者Docker daemon，這些內容你都是獲取不到的。如果想要檢視Rancher Compose能提供的所有特性，你可以檢視這個文件
通過將已有的部署工作交給Rancher Compose來替代之前的Ansible工具，我們能夠很輕鬆的將服務遷移並部署為Rancher應用的形式。之後，我們就能夠去除DESTINATION引數了，但我們依然保留VERSION引數，因為我們在插入docker-compose.uml檔案的時候還要使用它。以下是使用Jenkins部署時，部署邏輯的shell片段：
export RANCHER_URL=http://rancher.abc.net/
export RANCHER_ACCESS_KEY=…
export RANCHER_SECRET_KEY=…
if [ -f docker/docker-compose.yml ]; then
docker_dir=docker
elif [ -f /opt/abc/dockerfiles/java-service-1/docker-compose.yml ]; then
docker_dir=/opt/abc/dockerfiles/java-service-1
else
echo “No docker-compose.yml found. Can’t continue!”
exit 1
fi
if ! [ -f ${docker_dir}/rancher-compose.yml ]; then
echo “No rancher-compose.yml found. Can’t continue!”
exit 1
fi
/usr/local/bin/rancher-compose –verbose \
-f ${docker_dir}/docker-compose.yml \
-r ${docker_dir}/rancher-compose.yml \
up -d –upgrade閱讀完程式碼段，我們可以發現其主要包括以下內容：
- 我們定義了以環境變數的方式如何訪問我們的Rancher server。
- 需要找到docker-compose.yml檔案，否則將會任務將會報錯退出。
- 需要找到rancher-compose.yml檔案，否則任務將會報錯退出。
- 執行Rancher-compose，並告訴它不要block並且使用-d命令輸出日誌，使用-upgrade命令更新一個已經存在的服務。
也許你已經發現了，在絕大部分，程式碼的邏輯都是相同的，而最大的區別就是使用rancher-compose代替使用Ansible工具完成部署，並對每一個服務添加了rancher-compose.yml檔案。具體到我們的java-service-1應用，docker-compose檔案和rancher-compose檔案現在是這樣的：
docker-compose.yml
java-service-1:
image: registry.abc.net/java-service-1:${VERSION}
container_name: java-service-1
expose:
– 8080
ports:
– 8080:8080
rancher-compose.yml
java-service-1:
scale: 3在開始部署工作之前，我們先回顧一下部署工作的流程：
- 開發人員將程式碼的修改推送至git上
- 使用Jenkins對程式碼進行單元測試，在測試工作結束之後觸發下游工作
- 下游工作採用新的程式碼構建一個docker映象，並將其推送至我們自己的Docker映象倉庫中
- 建立包含應用名、版本號、部署環境的deployment ticket
DEPLOY-111:
App: JavaService1, branch “release/1.0.1”
Environment: Production- 部署工程師針對應用執行Jenkins的部署工作，執行時需要將版本號作為引數。
- Rancher compose開始執行，對於某個環境建立或更新應用，並且當達到所需規模的時候，結束這個工作
- 部署工程師以及開發工程師分別手動地對服務進行校驗
- 部署工程師在Rancher UI中確認完成升級
關鍵點
使用Rancher進行我們的服務部署時，我們從Rancher內建的排程、彈性伸縮、還原、升級、和回滾等工具中獲得極大的便利，使得我們在部署過程中沒有花太大的力氣。同時我們發現，在將部署工作從Ansible工具中遷移至Rancher的工作量也是很小的，僅僅需要在原有的基礎上增加rancher-compose.yml檔案。然而，使用Rancher來處理我們容器的排程意味著我們將難以確認我們的應用到底是在哪臺主機上執行的。比方說，之前我們並沒有決定java-service-1應用在哪裡執行，對於後端，在進行負載均衡相關操作時，該應用就沒有一個靜態的IP。我們需要找到一種辦法，使得我們的各種應用之間能夠相互察覺到對方。最終，對於我們的java-service-1應用，我們將明確地將應用容器所在的docker主機的8080埠與應用繫結，不過，如果有其他服務與應用繫結為相同的埠，它將會啟動失敗。通常負責排程決策的工程師將會對以上的事務進行處理。然而，我們最好將這些資訊通知排程器以避免這樣的事情發生。
在本教程的最後一個部分，我們將繼續探索一些方案來解決在使用親和性規則、主機標籤、服務探索以及智慧升級和回滾等特性時出現的問題。
9月27日，北京海航萬豪酒店，容器技術大會Container Day 2017即將舉行。
CloudStack之父、海航科技技術總監、華為PaaS部門部長、恆豐銀行科技部總經理、阿里雲PaaS工程總監、民生保險CIO······均已加入豪華講師套餐！
11家已容器落地企業，15位真·雲端計算大咖，13場純·技術演講，結合實戰場景，聚焦落地經驗。免費參會+超高規格，詳細議程及註冊連結請戳
