《Ghostcloud精靈云CTO喬融：基于Docker的DevOps實(shí)現(xiàn)》要點(diǎn)：
本文介紹了Ghostcloud精靈云CTO喬融：基于Docker的DevOps實(shí)現(xiàn)，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

講師介紹

喬融
Ghostcloud精靈云CTO

資深Docker、DevOps鉆研者,14年企業(yè)級(jí)軟件研發(fā)經(jīng)驗(yàn).
曾任職于EMC,負(fù)責(zé)數(shù)據(jù)存儲(chǔ)保護(hù)一體機(jī)核心研發(fā)；曾任職于Symantec(VERITAS),負(fù)責(zé)NAS和NBU的核心模塊研發(fā),Symantec全球白金獎(jiǎng)獲得者.

主題簡(jiǎn)介：

1、傳統(tǒng)開發(fā)模式的問題分析
2、DevOps的完成流程詳解
3、基于Docker的DevOps實(shí)現(xiàn)步驟詳解和案例分享

一、傳統(tǒng)開發(fā)模式的問題分析

眾所周知,傳統(tǒng)開發(fā)模式已經(jīng)面臨了諸多難題.首先,在代碼集成方面,因?yàn)闆]有合適粒度的代碼合并,大規(guī)模的合并會(huì)有很大的風(fēng)險(xiǎn),且傳統(tǒng)開發(fā)模式中沒有自動(dòng)化測(cè)試,以至于測(cè)試周期特別長(zhǎng),人力成本高昂.其次,傳統(tǒng)開發(fā)中的單體應(yīng)用,通常都很龐大,單體應(yīng)用把所有模塊都包含在一個(gè)應(yīng)用中,升級(jí)單個(gè)模塊也需要對(duì)整個(gè)應(yīng)用進(jìn)行升級(jí),所以升級(jí)和創(chuàng)新都很不方便,常見的如銀行系統(tǒng)就是如此.

同時(shí),傳統(tǒng)的開發(fā)模式中單獨(dú)采用微服務(wù)的情況也會(huì)由于服務(wù)數(shù)量多而沒有有效管理,在大批量的部署和測(cè)試的時(shí)候容易出現(xiàn)問題.除此之外,傳統(tǒng)開發(fā)模式更面臨著開發(fā)和測(cè)試的環(huán)境不一致,以及由于沒有有效的升級(jí)方式導(dǎo)致業(yè)務(wù)停止的問題.

二、DevOps的完成流程詳解

(如何一步步實(shí)現(xiàn)DevOps)

為了解決傳統(tǒng)開發(fā)模式中的問題,目前一個(gè)比較流行和徹底的方案是：DevOps流程+微服務(wù)理論+使用容器和容器編排工具.在這里展示給大家的是一個(gè)理論上的基于容器的CI/CD流程,實(shí)際上,DevOps的前身就是CI/CD,實(shí)現(xiàn)了CI/CD后,再加上一些發(fā)布、部署等標(biāo)準(zhǔn)和管理就構(gòu)成了DevOps.

(基于容器的CI/CD流程)

三、基于Docker的DevOps實(shí)現(xiàn)步驟詳解和案例分享

1、實(shí)現(xiàn)DevOps之自動(dòng)化測(cè)試

那么,如何完整地實(shí)現(xiàn)DevOps呢?通常情況下,傳統(tǒng)開發(fā)模式轉(zhuǎn)向DevOps的第一步是解決自動(dòng)化問題.要想持續(xù)地集成代碼,沒有自動(dòng)化測(cè)試來(lái)保證快速地進(jìn)行合并后的驗(yàn)證,風(fēng)險(xiǎn)是很高的,而且沒有自動(dòng)化測(cè)試,測(cè)試環(huán)境很有可能成為整個(gè)開發(fā)環(huán)節(jié)的瓶頸.只要是經(jīng)常使用的測(cè)試用例,需要盡量自動(dòng)化每一個(gè)操作.

自動(dòng)化工具很多,對(duì)自動(dòng)化工具和測(cè)試框架的選擇需要根據(jù)具體應(yīng)用來(lái)決定,這里只列舉其中常用的一小部分——Jenkins、Python、Robot Framework、Shell Script、Selenium、Ansible和Docker Container Orchestration——這些都是我們面對(duì)客戶需求的時(shí)候經(jīng)常用到的.然而,不是每次集成都需要跑完所有的測(cè)試用例,因而對(duì)測(cè)試用例進(jìn)行管理,可提高持續(xù)集成的效率.

(自動(dòng)化測(cè)試)

如何來(lái)判斷自動(dòng)化測(cè)試用例和框架是否有效?常見的判斷依據(jù)有三個(gè),首先是自動(dòng)化測(cè)試的覆蓋率.如果通過率再高,覆蓋率低,那么自動(dòng)化測(cè)試就不是一個(gè)有效的,目前企業(yè)級(jí)比較認(rèn)可的覆蓋率是75%左右,再提高也比較困難.其次是看漏測(cè)率,有時(shí)候自動(dòng)化用例本身也可能有Bug,前期階段通過比較手動(dòng)測(cè)試、自動(dòng)化測(cè)試的結(jié)果來(lái)判斷自動(dòng)化測(cè)試是否有效.最后,當(dāng)產(chǎn)品發(fā)布后根據(jù)從客戶來(lái)源的bug數(shù)目來(lái)判斷自動(dòng)化測(cè)試用例是否有效.另外,要穩(wěn)定一套自動(dòng)化用例,一般需要2個(gè)版本周期或者更長(zhǎng).

2、實(shí)現(xiàn)DevOps之持續(xù)集成和持續(xù)交付

持續(xù)集成一個(gè)主要的功能是讓每個(gè)工程師的代碼提交都不會(huì)影響到Mainline,以保證Mainline的可發(fā)布狀態(tài).實(shí)施持續(xù)集成時(shí),需要注意的地方：指定規(guī)則,提交代碼時(shí)要一并提交新功能的測(cè)試用例.

集成的粒度和頻度也很關(guān)鍵.一般一個(gè)小模塊,不超過1周的時(shí)間.

(持續(xù)集成)

持續(xù)集成通過后,根據(jù)應(yīng)用程序的特點(diǎn),在經(jīng)過系統(tǒng)集成測(cè)試、性能測(cè)試、穩(wěn)定的自動(dòng)化測(cè)試通過率以及管理層的批準(zhǔn)后,才是可持續(xù)交付和部署的應(yīng)用程序.

持續(xù)交付有兩種方式,一種就是基于DevOps的自動(dòng)持續(xù)發(fā)布,一種是多個(gè)功能一并發(fā)布.在持續(xù)交付的過程中需要注意三個(gè)問題：

• 部署到生產(chǎn)環(huán)境后也要有相應(yīng)的測(cè)試；
• 使用Toggle控制功能是否生效；
• 要有回滾的手段(灰度發(fā)布).

3、實(shí)現(xiàn)DevOps之微服務(wù)化

有了自動(dòng)化測(cè)試、持續(xù)集成和持續(xù)交付三塊,已經(jīng)基本實(shí)現(xiàn)了DevOps的粗略流程,而為了提高DevOps的效率, 往往需要結(jié)合微服務(wù).一個(gè)微服務(wù)理論上只做一件事,并能用任何語(yǔ)言編寫.微服務(wù)是松耦合的,意味著一個(gè)應(yīng)用的微服務(wù)可以被部署到不同機(jī)器上并通過RestAPI/RPC來(lái)通信,當(dāng)定義好微服務(wù)的API之后,每個(gè)team便能獨(dú)立開發(fā).因此,微服務(wù)更容易被測(cè)試和實(shí)現(xiàn)CI/CD.

(微服務(wù)的最佳實(shí)踐)

在微服務(wù)的最佳實(shí)踐中,首先不得不提容器.容器的輕量化讓微服務(wù)啟動(dòng)很快,同時(shí)容器的跨平臺(tái)性保證了微服務(wù)可以在不同的平臺(tái)啟動(dòng)起來(lái).第二種是使用代理服務(wù)器來(lái)訪問微服務(wù),現(xiàn)在最常見的方式是前端連接一個(gè)代理服務(wù)器,后端再連接運(yùn)行同一個(gè)微服務(wù)的幾個(gè)相同容器.一個(gè)大的應(yīng)用會(huì)使用幾十上百個(gè)微服務(wù),和微服務(wù)不相關(guān)的庫(kù)文件不建議放在容器中.實(shí)踐微服務(wù)中,建議使用配置管理工具(ansible, puppet等)和容器服務(wù)編排工具(K8s,Swarm,EcOS等).

(康威定律)

在開發(fā)微服務(wù)中康威定律起到了很大的作用.康威定律指出任何軟件代碼都是用來(lái)反映組織機(jī)構(gòu)而產(chǎn)生的,如果要采用微服務(wù)的開發(fā)方法,就需要是把團(tuán)隊(duì)劃分成多個(gè)小團(tuán)隊(duì),由每個(gè)小團(tuán)隊(duì)負(fù)責(zé)一個(gè)或多個(gè)微服務(wù).所以如果要轉(zhuǎn)成DevOps和CI/CD的開發(fā)模式,就需要采用這種敏捷開發(fā)模式,一個(gè)團(tuán)隊(duì)7-8個(gè)人比較合適.

4、實(shí)現(xiàn)DevOps之容器技術(shù)

另外一個(gè)實(shí)現(xiàn)DevOps的重要手段是Docker容器技術(shù).和傳統(tǒng)的Hypervisor相比,Docker沒有自己的操作系統(tǒng),它使用宿主機(jī)的操作系統(tǒng),而Hypervisor需要建立虛擬機(jī),每個(gè)虛擬機(jī)需要裝一個(gè)操作系統(tǒng),因此Docker效率更高更節(jié)約資源.如果一臺(tái)物理機(jī)可以操作20個(gè)虛擬機(jī),便至少可以啟動(dòng)200個(gè)容器,且啟動(dòng)容器的時(shí)間是秒級(jí).

Docker和Hypervisor的對(duì)比

使用容器編排工具可以實(shí)現(xiàn)對(duì)容器的健康檢查、動(dòng)態(tài)伸縮、灰度發(fā)布和藍(lán)綠發(fā)布等功能.而我們提到的容器編排技術(shù),比如K8s,Mesos和Swarm,都是開源的工具,這里我們把精靈云自研的容器編排工具EcOS和開源工具進(jìn)行了簡(jiǎn)單對(duì)比.

(幾種常見容器編排技術(shù)的比較)

K8s是由谷歌發(fā)起的開源框架,最大的問題是太笨重,對(duì)使用者來(lái)說(shuō)操作很復(fù)雜,學(xué)習(xí)周期很長(zhǎng).Swarm是Docker公司開發(fā)的工具,Docker本身不能支持的功能,Swarm也是無(wú)法支持的.如圖所示,EcOS是精靈云自主開發(fā)的容器編排技術(shù),最大的特點(diǎn)是結(jié)合了開源工具的優(yōu)點(diǎn),在應(yīng)用編排上完全可視化.

5、實(shí)現(xiàn)DevOps之灰度發(fā)布

如果一個(gè)服務(wù)由多個(gè)相同的容器運(yùn)行,灰度發(fā)布則先對(duì)其中的部分容器先進(jìn)行升級(jí),可混合讓老版本和新版本的容器同時(shí)提供服務(wù).如發(fā)現(xiàn)新服務(wù)沒有什么問題,則可以把所有剩下的微服務(wù)再全部進(jìn)行升級(jí).

(灰度發(fā)布)

6、實(shí)現(xiàn)DevOps之版本控制

DevOps下版本控制的原則是始終在Mainline上進(jìn)行新功能的開發(fā),并經(jīng)由持續(xù)集成的自動(dòng)化測(cè)試對(duì)代碼進(jìn)行驗(yàn)證.當(dāng)功能開發(fā)到一定階段的時(shí)候,對(duì)可RC的代碼創(chuàng)建分支,該分支上停止新功能的開發(fā),只求穩(wěn)定.當(dāng)產(chǎn)品發(fā)布后,如發(fā)現(xiàn)問題,可出hotfix.根據(jù)時(shí)間點(diǎn)和具體需要,可把其他分支的hotfix merge到Mainline上.

(版本控制原理)

Q&A

Q1：微服務(wù)是一個(gè)抽象概念還是說(shuō)有具體的工具來(lái)實(shí)現(xiàn)?
A1：微服務(wù)是一種軟件架構(gòu)風(fēng)格,它以專注于單一責(zé)任與功能的小型功能模塊為基礎(chǔ),利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序.另一方面,也可以說(shuō)微服務(wù)是一種編程思維,如果是想要開發(fā)出能在云上運(yùn)行的微服務(wù),可參考云原生的12因素法則.

Q2：請(qǐng)問傳統(tǒng)的非常龐大的單體應(yīng)用如何逐步改成微服務(wù)?
A2：1)新的功能開發(fā)使用微服務(wù)方式.
2)把邊緣模塊換成微服務(wù)方式.
3)將前端和后端分離
4)抽出服務(wù),逐步替換.這一步尤為復(fù)雜,需要由經(jīng)驗(yàn)豐富的架構(gòu)師來(lái)主導(dǎo).

Q3：請(qǐng)問一下剛所說(shuō)的75%覆蓋率,是前后端全部的?
A3：平均覆蓋率為75%.

Q4：你們這邊Devops應(yīng)用在什么量級(jí)別?
A4：Ghostcloud已經(jīng)結(jié)合Jenkins和EcOS,完全實(shí)現(xiàn)了自動(dòng)化的持續(xù)集成.但是目前還有一些手動(dòng)的系統(tǒng)集成測(cè)試和性能測(cè)試.

Q5：您所說(shuō)的企業(yè)級(jí)應(yīng)用指的哪種類型的?包括一些復(fù)雜的SaaS應(yīng)用嗎?有沒有一些實(shí)際的項(xiàng)目事例的自動(dòng)化測(cè)試覆蓋率供參考?
A5：銀行的管理系統(tǒng),電商的平臺(tái),企業(yè)的云平臺(tái)管理軟件等,大型的由企業(yè)使用的軟件都可以叫企業(yè)級(jí)應(yīng)用.SaaS當(dāng)然可以算是企業(yè)級(jí)應(yīng)用.國(guó)外很多大公司的代碼覆蓋率都是這個(gè)70%～80%值,可以看一下這篇文章：http://www.bullseye.com/minimum.html

Q6：web ui的自動(dòng)化測(cè)試用的什么工具,比如input框如何search到?
A6：web ui的測(cè)試工具很多,比如Robot Framework的Selenium. 對(duì)于input框這類元素,可使用xpath來(lái)定位.

Q7：負(fù)載均衡有啥好的方案?怎么自動(dòng)發(fā)現(xiàn)應(yīng)用拓?fù)?ip)變化?
A7：我們目前使用的是HAProxy,并且正在開發(fā)Nginx的支持.自動(dòng)發(fā)現(xiàn)使用的是ETCD+DNS+Wather的方式,當(dāng)容器IP地址發(fā)生改變,可自動(dòng)捕獲,并更新代理服務(wù)器的配置文件.

Q8：之前我們?cè)诖罱≒aaS平臺(tái)時(shí),花費(fèi)了很多時(shí)間在環(huán)境搭建、定位環(huán)境問題上,請(qǐng)問對(duì)于平臺(tái)的搭建維護(hù),有什么好的建議?
A8：建議試一下EcOS,一鍵部署.www.ghostcloud.cn

Q9：traefik專門用來(lái)做微服務(wù)負(fù)載均衡,國(guó)內(nèi)用得多嗎?
A9：大多數(shù)還是用的HAProxy和Nginx吧.

原文出處：http://dbaplus.cn/news-21-1125-1.html

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4305.html