摘要：當(dāng)面臨這些挑戰(zhàn)在短短半天的時(shí)間里，使用和現(xiàn)有的主機(jī)，我們已經(jīng)將部署好并成功運(yùn)行。使用來創(chuàng)建應(yīng)用并定義服務(wù)。

在這一部分，我們將一步步的走進(jìn)Rancher，細(xì)致的探討Rancher將如何解決在部署與容器管理時(shí)出現(xiàn)的種種的問題?；仡櫧坛痰牡诙糠郑銜?huì)發(fā)現(xiàn)我們已經(jīng)將應(yīng)用的部署遷移至Docker Compose，并且已經(jīng)建立了一系列工作步驟來部署我們的應(yīng)用。這將使得開發(fā)人員能夠輕松的對他們的應(yīng)用部署邏輯進(jìn)行修正，運(yùn)維人員也可以查看應(yīng)用的部署時(shí)間。當(dāng)然，在上一個(gè)部分教程的一系列操作中，也存在一些顯而易見的問題需要解決。

首先，運(yùn)維人員必須手動(dòng)地調(diào)整所有服務(wù)的執(zhí)行計(jì)劃。部署人員需要決定將哪一個(gè)應(yīng)用部署至哪一臺主機(jī)，這意味著部署人員需要時(shí)刻對每一臺主機(jī)的剩余可用資源都有了解，如果某一臺主機(jī)或者容器崩潰了，部署的操作人員將需要對應(yīng)用進(jìn)行重新部署。實(shí)際生產(chǎn)中，這意味著主機(jī)常常處于負(fù)載失衡的狀態(tài)，并且服務(wù)在崩潰之后需要很長時(shí)間才能得到恢復(fù)。

其次，使用Docker-Compose時(shí)，想要獲得你的服務(wù)的當(dāng)前狀態(tài)是十分困難的。舉個(gè)例子來說，我們經(jīng)常會(huì)從運(yùn)維人員、項(xiàng)目經(jīng)理以及開發(fā)者口中聽到這樣的問題：“現(xiàn)在部署環(huán)境中運(yùn)行的到底是XX應(yīng)用程序的哪個(gè)版本？”如果我們采用的是手動(dòng)調(diào)整服務(wù)的執(zhí)行計(jì)劃的方式，想要得到這個(gè)問題的答案通常需要詢問指定的進(jìn)行操作的工程師，工程師們需要登陸服務(wù)器并運(yùn)行docker中的ps命令來查看容器的信息。然而面對這些問題，Rancher將會(huì)給我們提供極大的便利：每個(gè)人都可以非常容易地獲取已經(jīng)部署的服務(wù)的信息，而不需要臨時(shí)請求運(yùn)維人員的幫助。

使用Rancher之前，我們試著了解過不少其他能夠管理Docker主機(jī)或集群的解決方案。然而這些解決方案都沒有注意到這是對Docker主機(jī)或集群在多種環(huán)境（multi-environment）下的管理，這將成為最大的麻煩與負(fù)擔(dān)之一。如果有服務(wù)以不同的負(fù)載運(yùn)行在8種不同的環(huán)境下，我們需要的是一個(gè)統(tǒng)一的方式來管理集群，而不會(huì)想要訪問8個(gè)不同的服務(wù)。并且，我們希望讓重新構(gòu)建環(huán)境對于我們而言，變成分分鐘就能完成的任務(wù)，這樣開發(fā)者就可以隨意地更改開發(fā)環(huán)境。然而，對于生產(chǎn)環(huán)境而言，我們希望提供給他們的只是有限的只讀訪問權(quán)限。面對這樣的需求，一個(gè)采用基于角色的訪問控制（RBAC）模型的集中管理方案就顯得十分必要了。我們最初決定嘗試Rancher就是因?yàn)樗诓渴鹕戏浅：唵巍?/p> 當(dāng)Rancher面臨這些挑戰(zhàn)

在短短半天的時(shí)間里，使用AWS ELB、Elasticache、RDS和現(xiàn)有的Docker主機(jī)，我們已經(jīng)將Rancher部署好并成功運(yùn)行。能夠方便地配置認(rèn)證信息也是Rancher的優(yōu)點(diǎn)之一。

我們并不會(huì)深入Rancher本身部署的細(xì)節(jié)，Rancher部署文檔中已經(jīng)說的很明白了。相反，我們將從剛剛完成初始設(shè)置那一步開始，說明將如何將原有的設(shè)置（教程第一部分和第二部分中所提及的）遷移進(jìn)來。

我們就從創(chuàng)建不同的環(huán)境開始吧，為了使得這個(gè)過程盡量簡單些，我們將對開發(fā)環(huán)境（dev）、部署環(huán)境（stage）以及生產(chǎn)環(huán)境（prod）分別進(jìn)行設(shè)置。每個(gè)環(huán)境都已有運(yùn)行在Ubuntu之上的Docker主機(jī)，且這些Docker主機(jī)是由內(nèi)部的Ansible配置的，Ansible安裝了Docker、我們的監(jiān)控代理、并進(jìn)行了一些組織特定的更改。在Rancher上，你只需要運(yùn)行一條命令，將Docker主機(jī)在Rancher server內(nèi)部進(jìn)行注冊，就可以將已有的Docker主機(jī)添加至每個(gè)環(huán)境中。

在大多數(shù)情況下，想要添加一臺主機(jī)需要經(jīng)過一系列的操作：通過鼠標(biāo)在網(wǎng)頁上完成一些點(diǎn)擊，接下來切換至某個(gè)特定的環(huán)境，最后在終端系統(tǒng)上輸入命令。然而，如果你使用Rancher API，我們可以在Ansible工具的幫助下使得這一系列的操作轉(zhuǎn)化為完全自動(dòng)化的設(shè)置。出于好奇，在下面我們截取了playbook中有關(guān)這一操作的部分內(nèi)容（大多是根據(jù) Hussein Galas的repo中的內(nèi)容做出的邏輯上的修改而得到的）。

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”

隨著工作的一步步進(jìn)行，我們已經(jīng)完成了環(huán)境的創(chuàng)建并已經(jīng)將主機(jī)在Rancher server中注冊，現(xiàn)在就讓我們來了解一下，如何將我們的部署工作流整合至Rancher中。我們知道，對于每一臺Docker來說，其中都有著一些正在運(yùn)行的容器，這些系統(tǒng)的部署是通過Ansible工具借助Jenkins完成的。Rancher提供了以下開箱即用的功能：

管理已有的容器（比如：啟動(dòng)、修改、查看日志、啟動(dòng)一個(gè)交互式的shell）

獲得關(guān)于運(yùn)行中的和停止運(yùn)行的容器的信息（比如：鏡像信息、初始化命令信息、命令信息，端口映射信息以及環(huán)境變量信息）

查看主機(jī)和容器層級上的資源使用情況（比如：CPU使用率、內(nèi)存占用率、以及磁盤和網(wǎng)絡(luò)的使用情況）

很快，我們就已經(jīng)將Docker主機(jī)注冊至Rancher Server中，現(xiàn)在我們可以查看容器在各種環(huán)境下的運(yùn)行狀態(tài)信息了。不僅如此，如果想要將這些信息分享給其他團(tuán)隊(duì)，我們僅僅需要針對某個(gè)環(huán)境給予他們一些有限的權(quán)限。通過以上的方式，在想要獲得狀態(tài)信息時(shí)我們就完全沒有必要請求操作人員登錄Docker主機(jī)，再通過人工的方式去查詢，同時(shí)這樣也減少了申請獲得環(huán)境信息的請求的數(shù)目，因?yàn)槲覀円呀?jīng)將某些訪問權(quán)限分配至各個(gè)團(tuán)隊(duì)了。舉個(gè)例子來說，如果為開發(fā)團(tuán)隊(duì)分配環(huán)境信息的只讀權(quán)限，那么將會(huì)在開發(fā)團(tuán)隊(duì)與部署操作團(tuán)隊(duì)之間架起一座溝通的橋梁，這樣兩個(gè)團(tuán)隊(duì)都會(huì)對這個(gè)環(huán)境的狀態(tài)比以往更加的關(guān)心。在這個(gè)基礎(chǔ)上，故障的排除也變成了一種小組間相互合作的過程，而不是以往的那種單向的、依賴同步信息流的解決方式，相互合作的方式也會(huì)減少解決突發(fā)事件的總時(shí)間。

到現(xiàn)在為止，我們已經(jīng)將已有的Docker主機(jī)加入Rancher Server，并且基于已經(jīng)閱讀完了的教程的第一部分關(guān)于Jenkins和Rancher的內(nèi)容，下一步，我們打算改進(jìn)的部分是我們已有的部署流水線，我們將會(huì)對已有的部署流水線進(jìn)行修改，以便于使用Rancher compose，Rancher Compose將代替之前Ansible工具提到的Docker compose。不過在我們深入下一部分之前，我們首先需要了解關(guān)于Rancher的應(yīng)用、調(diào)度、Docker Compose和Rancher Compose的一些信息。

應(yīng)用與服務(wù)：Rancher將每個(gè)獨(dú)立的容器（指的是部署在Rancher之外的容器，或者是通過Rancher UI生成的一次性功能的容器）、應(yīng)用和服務(wù)彼此分離開。簡單地說，應(yīng)用是一組服務(wù)，而所有容器都需要利用服務(wù)（關(guān)于應(yīng)用和服務(wù)的內(nèi)容之后將會(huì)由更加詳細(xì)的介紹）以構(gòu)建一個(gè)應(yīng)用。獨(dú)立的容器需要手動(dòng)地進(jìn)行調(diào)度。

調(diào)度：在之前的部署技術(shù)中，運(yùn)維人員需要決定容器應(yīng)當(dāng)在哪一臺主機(jī)上運(yùn)行。如果使用的是部署腳本，那么意味著運(yùn)維人員需要決定部署腳本在哪一臺或哪幾臺主機(jī)上運(yùn)行；如果使用Ansible，這將意味著運(yùn)維人員需要決定哪些主機(jī)或組需要到Jenkins中工作。不論是哪一種方式，都需要運(yùn)維人員去做一些決定，但是在大多數(shù)情況下，他們做出的決定都缺乏一些可靠的依據(jù)，這對我們的部署工作很是不利（比如說某一臺主機(jī)的CPU使用率高達(dá)100%）。很多解決方案，比如像Docker Swarm、Kubernetes、Mesos和Rancher都采用了調(diào)度器來解決這類問題。對于需要執(zhí)行的某個(gè)操作，調(diào)度器將會(huì)請求獲得一組主機(jī)的信息，并判斷出哪幾臺是適合執(zhí)行這個(gè)操作的。調(diào)度器會(huì)根據(jù)默認(rèn)的需求設(shè)定或者用戶定義的特定需求，比如CPU使用率高低、親和性或反親和性規(guī)則（比如：禁止在同一臺主機(jī)上部署兩個(gè)相同容器）等類似的需求，以逐漸縮小主機(jī)選擇的范圍。如果我是一個(gè)負(fù)責(zé)部署的運(yùn)維人員，調(diào)度器將會(huì)極大的減少我的工作負(fù)擔(dān)（尤其是我在深夜加班忙于部署時(shí)），因?yàn)檎{(diào)度器對以上信息的計(jì)算比我快的多，也準(zhǔn)的多。Rancher在我們通過應(yīng)用部署服務(wù)的時(shí)候能夠提供一個(gè)開箱即用調(diào)度器。

Docker compose：Rancher使用Docker compose來創(chuàng)建應(yīng)用并定義服務(wù)。由于我們已經(jīng)將服務(wù)轉(zhuǎn)化為Docker compose的文件，我們在此基礎(chǔ)上創(chuàng)建應(yīng)用就變得容易了許多。應(yīng)用可以手動(dòng)的從UI界面中創(chuàng)建，也可以通過Rancher compose在命令行（CLI）下快速的創(chuàng)建。

Rancher compose：Rancher compose是一種通過命令行（CLI）讓我們得以對Rancher中的每一種環(huán)境的應(yīng)用和服務(wù)進(jìn)行方便的管理的工具。同時(shí)，通過rancher-compse.yml文件，Rancher compose還能允許對Rancher工具進(jìn)行一些其他訪問。這是一個(gè)純粹的附加的文件，將不會(huì)取代原有的docker-compose.yml文件。在rancher-compose.yml文件中，你可以定義以下內(nèi)容，比如說：

每種服務(wù)的升級策略信息

每種服務(wù)的健康檢查信息

每種服務(wù)的需求規(guī)模信息

這些都是Rancher中非常實(shí)用的亮點(diǎn)，如果你使用Docker Compose或者Docker daemon，這些內(nèi)容你都是獲取不到的。如果想要查看Rancher Compose能提供的所有特性，你可以查看這個(gè)文檔

通過將已有的部署工作交給Rancher Compose來替代之前的Ansible工具，我們能夠很輕松的將服務(wù)遷移并部署為Rancher應(yīng)用的形式。之后，我們就能夠去除DESTINATION參數(shù)了，但我們依然保留VERSION參數(shù)，因?yàn)槲覀冊诓迦雂ocker-compose.uml文件的時(shí)候還要使用它。以下是使用Jenkins部署時(shí)，部署邏輯的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

閱讀完代碼段，我們可以發(fā)現(xiàn)其主要包括以下內(nèi)容：

我們定義了以環(huán)境變量的方式如何訪問我們的Rancher server。

需要找到docker-compose.yml文件，否則將會(huì)任務(wù)將會(huì)報(bào)錯(cuò)退出。

需要找到rancher-compose.yml文件，否則任務(wù)將會(huì)報(bào)錯(cuò)退出。

運(yùn)行Rancher-compose，并告訴它不要block并且使用-d命令輸出日志，使用-upgrade命令更新一個(gè)已經(jīng)存在的服務(wù)。

也許你已經(jīng)發(fā)現(xiàn)了，在絕大部分，代碼的邏輯都是相同的，而最大的區(qū)別就是使用rancher-compose代替使用Ansible工具完成部署，并對每一個(gè)服務(wù)添加了rancher-compose.yml文件。具體到我們的java-service-1應(yīng)用，docker-compose文件和rancher-compose文件現(xiàn)在是這樣的：

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

在開始部署工作之前，我們先回顧一下部署工作的流程：

開發(fā)人員將代碼的修改推送至git上

使用Jenkins對代碼進(jìn)行單元測試，在測試工作結(jié)束之后觸發(fā)下游工作

下游工作采用新的代碼構(gòu)建一個(gè)docker鏡像，并將其推送至我們自己的Docker鏡像倉庫中

創(chuàng)建包含應(yīng)用名、版本號、部署環(huán)境的deployment ticket

DEPLOY-111:
  App: JavaService1, branch “release/1.0.1”
  Environment: Production

部署工程師針對應(yīng)用運(yùn)行Jenkins的部署工作，運(yùn)行時(shí)需要將版本號作為參數(shù)。

Rancher compose開始運(yùn)行，對于某個(gè)環(huán)境創(chuàng)建或更新應(yīng)用，并且當(dāng)達(dá)到所需規(guī)模的時(shí)候，結(jié)束這個(gè)工作

部署工程師以及開發(fā)工程師分別手動(dòng)地對服務(wù)進(jìn)行校驗(yàn)

部署工程師在Rancher UI中確認(rèn)完成升級

使用Rancher進(jìn)行我們的服務(wù)部署時(shí)，我們從Rancher內(nèi)建的調(diào)度、彈性伸縮、還原、升級、和回滾等工具中獲得極大的便利，使得我們在部署過程中沒有花太大的力氣。同時(shí)我們發(fā)現(xiàn)，在將部署工作從Ansible工具中遷移至Rancher的工作量也是很小的，僅僅需要在原有的基礎(chǔ)上增加rancher-compose.yml文件。然而，使用Rancher來處理我們?nèi)萜鞯恼{(diào)度意味著我們將難以確認(rèn)我們的應(yīng)用到底是在哪臺主機(jī)上運(yùn)行的。比方說，之前我們并沒有決定java-service-1應(yīng)用在哪里運(yùn)行，對于后端，在進(jìn)行負(fù)載均衡相關(guān)操作時(shí)，該應(yīng)用就沒有一個(gè)靜態(tài)的IP。我們需要找到一種辦法，使得我們的各種應(yīng)用之間能夠相互察覺到對方。最終，對于我們的java-service-1應(yīng)用，我們將明確地將應(yīng)用容器所在的docker主機(jī)的8080端口與應(yīng)用綁定，不過，如果有其他服務(wù)與應(yīng)用綁定為相同的端口，它將會(huì)啟動(dòng)失敗。通常負(fù)責(zé)調(diào)度決策的工程師將會(huì)對以上的事務(wù)進(jìn)行處理。然而，我們最好將這些信息通知調(diào)度器以避免這樣的事情發(fā)生。

在本教程的最后一個(gè)部分，我們將繼續(xù)探索一些方案來解決在使用親和性規(guī)則、主機(jī)標(biāo)簽、服務(wù)探索以及智能升級和回滾等特性時(shí)出現(xiàn)的問題。

9月27日，北京海航萬豪酒店，容器技術(shù)大會(huì)Container Day 2017即將舉行。

CloudStack之父、海航科技技術(shù)總監(jiān)、華為PaaS部門部長、恒豐銀行科技部總經(jīng)理、阿里云PaaS工程總監(jiān)、民生保險(xiǎn)CIO······均已加入豪華講師套餐！

11家已容器落地企業(yè)，15位真·云計(jì)算大咖，13場純·技術(shù)演講，結(jié)合實(shí)戰(zhàn)場景，聚焦落地經(jīng)驗(yàn)。免費(fèi)參會(huì)+超高規(guī)格，詳細(xì)議程及注冊鏈接請戳