Rancher將如何解決在部署與容器管理時出現的問題

這篇文章將為大家詳細講解有關Rancher將如何解決在部署與容器管理時出現的問題，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

我們將一步步的走進Rancher，細致的探討Rancher將如何解決在部署與容器管理時出現的種種的問題。這將使得開發人員能夠輕松的對他們的應用部署邏輯進行修正，運維人員也可以查看應用的部署時間。

使用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

閱讀完代碼段，我們可以發現其主要包括以下內容：

1. 我們定義了以環境變量的方式如何訪問我們的Rancher server。

2. 需要找到docker-compose.yml文件，否則將會任務將會報錯退出。

3. 需要找到rancher-compose.yml文件，否則任務將會報錯退出。

4. 運行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端口與應用綁定，不過，如果有其他服務與應用綁定為相同的端口，它將會啟動失敗。通常負責調度決策的工程師將會對以上的事務進行處理。然而，我們最好將這些信息通知調度器以避免這樣的事情發生。

關于Rancher將如何解決在部署與容器管理時出現的問題就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。