這篇文章將為大家詳細(xì)講解有關(guān)Rancher將如何解決在部署與容器管理時(shí)出現(xiàn)的問題,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個(gè)參考,希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
創(chuàng)新互聯(lián)公司成立于2013年,先為正寧等服務(wù)建站,正寧等地企業(yè),進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為正寧企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
我們將一步步的走進(jìn)Rancher,細(xì)致的探討Rancher將如何解決在部署與容器管理時(shí)出現(xiàn)的種種的問題。這將使得開發(fā)人員能夠輕松的對他們的應(yīng)用部署邏輯進(jìn)行修正,運(yùn)維人員也可以查看應(yīng)用的部署時(shí)間。
首先,運(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)常會從運(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將會給我們提供極大的便利:每個(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)一的方式來管理集群,而不會想要訪問8個(gè)不同的服務(wù)。并且,我們希望讓重新構(gòu)建環(huán)境對于我們而言,變成分分鐘就能完成的任務(wù),這樣開發(fā)者就可以隨意地更改開發(fā)環(huán)境。然而,對于生產(chǎn)環(huán)境而言,我們希望提供給他們的只是有限的只讀訪問權(quán)限。面對這樣的需求,一個(gè)采用基于角色的訪問控制(RBAC)模型的集中管理方案就顯得十分必要了。我們最初決定嘗試Rancher就是因?yàn)樗诓渴鹕戏浅:唵巍?/p>
在短短半天的時(shí)間里,使用AWS ELB、Elasticache、RDS和現(xiàn)有的Docker主機(jī),我們已經(jīng)將Rancher部署好并成功運(yùn)行。能夠方便地配置認(rèn)證信息也是Rancher的優(yōu)點(diǎn)之一。
我們并不會深入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ò)的使用情況)
獨(dú)立的容器
很快,我們就已經(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)限,那么將會在開發(fā)團(tuán)隊(duì)與部署操作團(tuán)隊(duì)之間架起一座溝通的橋梁,這樣兩個(gè)團(tuán)隊(duì)都會對這個(gè)環(huán)境的狀態(tài)比以往更加的關(guān)心。在這個(gè)基礎(chǔ)上,故障的排除也變成了一種小組間相互合作的過程,而不是以往的那種單向的、依賴同步信息流的解決方式,相互合作的方式也會減少解決突發(fā)事件的總時(shí)間。
到現(xiàn)在為止,我們已經(jīng)將已有的Docker主機(jī)加入Rancher Server,并且基于已經(jīng)閱讀完了的教程的第一部分關(guān)于Jenkins和Rancher的內(nèi)容,下一步,我們打算改進(jìn)的部分是我們已有的部署流水線,我們將會對已有的部署流水線進(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)容之后將會由更加詳細(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)度器將會請求獲得一組主機(jī)的信息,并判斷出哪幾臺是適合執(zhí)行這個(gè)操作的。調(diào)度器會根據(jù)默認(rèn)的需求設(shè)定或者用戶定義的特定需求,比如CPU使用率高低、親和性或反親和性規(guī)則(比如:禁止在同一臺主機(jī)上部署兩個(gè)相同容器)等類似的需求,以逐漸縮小主機(jī)選擇的范圍。如果我是一個(gè)負(fù)責(zé)部署的運(yùn)維人員,調(diào)度器將會極大的減少我的工作負(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è)純粹的附加的文件,將不會取代原有的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文件,否則將會任務(wù)將會報(bào)錯(cuò)退出。
需要找到rancher-compose.yml文件,否則任務(wù)將會報(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)用綁定為相同的端口,它將會啟動(dòng)失敗。通常負(fù)責(zé)調(diào)度決策的工程師將會對以上的事務(wù)進(jìn)行處理。然而,我們最好將這些信息通知調(diào)度器以避免這樣的事情發(fā)生。
關(guān)于Rancher將如何解決在部署與容器管理時(shí)出現(xiàn)的問題就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學(xué)到更多知識。如果覺得文章不錯(cuò),可以把它分享出去讓更多的人看到。