《Ghostcloud精靈云CTO喬融:基于Docker的DevOps實現》要點:
本文介紹了Ghostcloud精靈云CTO喬融:基于Docker的DevOps實現,希望對您有用。如果有疑問,可以聯系我們。
講師介紹
喬融
Ghostcloud精靈云CTO
資深Docker、DevOps鉆研者,14年企業級軟件研發經驗.
曾任職于EMC,負責數據存儲保護一體機核心研發;曾任職于Symantec(VERITAS),負責NAS和NBU的核心模塊研發,Symantec全球白金獎獲得者.
主題簡介:
1、傳統開發模式的問題分析
2、DevOps的完成流程詳解
3、基于Docker的DevOps實現步驟詳解和案例分享
一、傳統開發模式的問題分析
眾所周知,傳統開發模式已經面臨了諸多難題.首先,在代碼集成方面,因為沒有合適粒度的代碼合并,大規模的合并會有很大的風險,且傳統開發模式中沒有自動化測試,以至于測試周期特別長,人力成本高昂.其次,傳統開發中的單體應用,通常都很龐大,單體應用把所有模塊都包含在一個應用中,升級單個模塊也需要對整個應用進行升級,所以升級和創新都很不方便,常見的如銀行系統就是如此.
同時,傳統的開發模式中單獨采用微服務的情況也會由于服務數量多而沒有有效管理,在大批量的部署和測試的時候容易出現問題.除此之外,傳統開發模式更面臨著開發和測試的環境不一致,以及由于沒有有效的升級方式導致業務停止的問題.
二、DevOps的完成流程詳解
(如何一步步實現DevOps)
為了解決傳統開發模式中的問題,目前一個比較流行和徹底的方案是:DevOps流程+微服務理論+使用容器和容器編排工具.在這里展示給大家的是一個理論上的基于容器的CI/CD流程,實際上,DevOps的前身就是CI/CD,實現了CI/CD后,再加上一些發布、部署等標準和管理就構成了DevOps.
(基于容器的CI/CD流程)
三、基于Docker的DevOps實現步驟詳解和案例分享
1、實現DevOps之自動化測試
那么,如何完整地實現DevOps呢?通常情況下,傳統開發模式轉向DevOps的第一步是解決自動化問題.要想持續地集成代碼,沒有自動化測試來保證快速地進行合并后的驗證,風險是很高的,而且沒有自動化測試,測試環境很有可能成為整個開發環節的瓶頸.只要是經常使用的測試用例,需要盡量自動化每一個操作.
自動化工具很多,對自動化工具和測試框架的選擇需要根據具體應用來決定,這里只列舉其中常用的一小部分——Jenkins、Python、Robot Framework、Shell Script、Selenium、Ansible和Docker Container Orchestration——這些都是我們面對客戶需求的時候經常用到的.然而,不是每次集成都需要跑完所有的測試用例,因而對測試用例進行管理,可提高持續集成的效率.
(自動化測試)
如何來判斷自動化測試用例和框架是否有效?常見的判斷依據有三個,首先是自動化測試的覆蓋率.如果通過率再高,覆蓋率低,那么自動化測試就不是一個有效的,目前企業級比較認可的覆蓋率是75%左右,再提高也比較困難.其次是看漏測率,有時候自動化用例本身也可能有Bug,前期階段通過比較手動測試、自動化測試的結果來判斷自動化測試是否有效.最后,當產品發布后根據從客戶來源的bug數目來判斷自動化測試用例是否有效.另外,要穩定一套自動化用例,一般需要2個版本周期或者更長.
2、實現DevOps之持續集成和持續交付
持續集成一個主要的功能是讓每個工程師的代碼提交都不會影響到Mainline,以保證Mainline的可發布狀態.實施持續集成時,需要注意的地方:指定規則,提交代碼時要一并提交新功能的測試用例.
集成的粒度和頻度也很關鍵.一般一個小模塊,不超過1周的時間.
(持續集成)
持續集成通過后,根據應用程序的特點,在經過系統集成測試、性能測試、穩定的自動化測試通過率以及管理層的批準后,才是可持續交付和部署的應用程序.
持續交付有兩種方式,一種就是基于DevOps的自動持續發布,一種是多個功能一并發布.在持續交付的過程中需要注意三個問題:
3、實現DevOps之微服務化
有了自動化測試、持續集成和持續交付三塊,已經基本實現了DevOps的粗略流程,而為了提高DevOps的效率, 往往需要結合微服務.一個微服務理論上只做一件事,并能用任何語言編寫.微服務是松耦合的,意味著一個應用的微服務可以被部署到不同機器上并通過RestAPI/RPC來通信,當定義好微服務的API之后,每個team便能獨立開發.因此,微服務更容易被測試和實現CI/CD.
(微服務的最佳實踐)
在微服務的最佳實踐中,首先不得不提容器.容器的輕量化讓微服務啟動很快,同時容器的跨平臺性保證了微服務可以在不同的平臺啟動起來.第二種是使用代理服務器來訪問微服務,現在最常見的方式是前端連接一個代理服務器,后端再連接運行同一個微服務的幾個相同容器.一個大的應用會使用幾十上百個微服務,和微服務不相關的庫文件不建議放在容器中.實踐微服務中,建議使用配置管理工具(ansible, puppet等)和容器服務編排工具(K8s,Swarm,EcOS等).
(康威定律)
在開發微服務中康威定律起到了很大的作用.康威定律指出任何軟件代碼都是用來反映組織機構而產生的,如果要采用微服務的開發方法,就需要是把團隊劃分成多個小團隊,由每個小團隊負責一個或多個微服務.所以如果要轉成DevOps和CI/CD的開發模式,就需要采用這種敏捷開發模式,一個團隊7-8個人比較合適.
4、實現DevOps之容器技術
另外一個實現DevOps的重要手段是Docker容器技術.和傳統的Hypervisor相比,Docker沒有自己的操作系統,它使用宿主機的操作系統,而Hypervisor需要建立虛擬機,每個虛擬機需要裝一個操作系統,因此Docker效率更高更節約資源.如果一臺物理機可以操作20個虛擬機,便至少可以啟動200個容器,且啟動容器的時間是秒級.
Docker和Hypervisor的對比
使用容器編排工具可以實現對容器的健康檢查、動態伸縮、灰度發布和藍綠發布等功能.而我們提到的容器編排技術,比如K8s,Mesos和Swarm,都是開源的工具,這里我們把精靈云自研的容器編排工具EcOS和開源工具進行了簡單對比.
(幾種常見容器編排技術的比較)
K8s是由谷歌發起的開源框架,最大的問題是太笨重,對使用者來說操作很復雜,學習周期很長.Swarm是Docker公司開發的工具,Docker本身不能支持的功能,Swarm也是無法支持的.如圖所示,EcOS是精靈云自主開發的容器編排技術,最大的特點是結合了開源工具的優點,在應用編排上完全可視化.
5、實現DevOps之灰度發布
如果一個服務由多個相同的容器運行,灰度發布則先對其中的部分容器先進行升級,可混合讓老版本和新版本的容器同時提供服務.如發現新服務沒有什么問題,則可以把所有剩下的微服務再全部進行升級.
(灰度發布)
6、實現DevOps之版本控制
DevOps下版本控制的原則是始終在Mainline上進行新功能的開發,并經由持續集成的自動化測試對代碼進行驗證.當功能開發到一定階段的時候,對可RC的代碼創建分支,該分支上停止新功能的開發,只求穩定.當產品發布后,如發現問題,可出hotfix.根據時間點和具體需要,可把其他分支的hotfix merge到Mainline上.
(版本控制原理)
Q1:微服務是一個抽象概念還是說有具體的工具來實現?
A1:微服務是一種軟件架構風格,它以專注于單一責任與功能的小型功能模塊為基礎,利用模塊化的方式組合出復雜的大型應用程序.另一方面,也可以說微服務是一種編程思維,如果是想要開發出能在云上運行的微服務,可參考云原生的12因素法則.
Q2:請問傳統的非常龐大的單體應用如何逐步改成微服務?
A2:1)新的功能開發使用微服務方式.
2)把邊緣模塊換成微服務方式.
3)將前端和后端分離
4)抽出服務,逐步替換.這一步尤為復雜,需要由經驗豐富的架構師來主導.
Q3:請問一下剛所說的75%覆蓋率,是前后端全部的?
A3:平均覆蓋率為75%.
Q4:你們這邊Devops應用在什么量級別?
A4:Ghostcloud已經結合Jenkins和EcOS,完全實現了自動化的持續集成.但是目前還有一些手動的系統集成測試和性能測試.
Q5:您所說的企業級應用指的哪種類型的?包括一些復雜的SaaS應用嗎?有沒有一些實際的項目事例的自動化測試覆蓋率供參考?
A5:銀行的管理系統,電商的平臺,企業的云平臺管理軟件等,大型的由企業使用的軟件都可以叫企業級應用.SaaS當然可以算是企業級應用.國外很多大公司的代碼覆蓋率都是這個70%~80%值,可以看一下這篇文章:http://www.bullseye.com/minimum.html
Q6:web ui的自動化測試用的什么工具,比如input框如何search到?
A6:web ui的測試工具很多,比如Robot Framework的Selenium. 對于input框這類元素,可使用xpath來定位.
Q7:負載均衡有啥好的方案?怎么自動發現應用拓撲(ip)變化?
A7:我們目前使用的是HAProxy,并且正在開發Nginx的支持.自動發現使用的是ETCD+DNS+Wather的方式,當容器IP地址發生改變,可自動捕獲,并更新代理服務器的配置文件.
Q8:之前我們在搭建PaaS平臺時,花費了很多時間在環境搭建、定位環境問題上,請問對于平臺的搭建維護,有什么好的建議?
A8:建議試一下EcOS,一鍵部署.www.ghostcloud.cn
Q9:traefik專門用來做微服務負載均衡,國內用得多嗎?
A9:大多數還是用的HAProxy和Nginx吧.
原文出處:http://dbaplus.cn/news-21-1125-1.html
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/4305.html