《專家觀察 | 趙安全：“Docker容器在傳統行業的落地再思考”》要點：
本文介紹了專家觀察 | 趙安全：“Docker容器在傳統行業的落地再思考”，希望對您有用。如果有疑問，可以聯系我們。

由工業和信息化部指導,中國信息通信研究院主辦,業界知名組織云計算開源產業聯盟(OSCAR)承辦的2017全球云計算開源大會于4月19日-20日在北京國家會議中心順利召開.本文為本屆大會嘉賓分享的大會演講速記內容,敬請瀏覽.

嘉賓介紹：趙安全

公司職務：BoCloud 博云高級解決方案架構師

大會演講速記

今天我題目叫做Docker容器在傳統行業的落地實踐.我們2015年開始做,我把這個坑給大家分享一下,包括我們一些思考跟大家分享一下.

整個的容器在傳統行業落地的時候,第一個問題為誰服務的問題?因為我們很多客戶,我問這個應用你用它上容器的目的,他說我想試試,我回答是這種應用上容器沒有什么作用.

容器在傳統行業應用要解決的問題,敏捷模式、互聯網模式應用問題的解決.從客戶期望來說想解決問題是這幾個.一是雙十一的時候,淘寶那邊流量一進來我就可以跑了,能不能解決彈性的問題.我們現在應用發布很慢,兩個月一個迭代,是不是把發布周期很長的問題解決掉.AO客戶說我們整個平臺變化能力比較差,能不能把我這個問題解決掉,這幾個是比較典型的需求,我肯定回答說是可以的.

但是僅僅落地容器是不夠的,因為容器平臺部署好之后可以能幫助解決這些問題,但是并不是說做了容器一定能解決這個問題.為什么?

首先彈性問題,彈性問題說起來比較簡單的,容器化之后可以很大程度解決這個問題.

其次是發布周期長的問題,你迭代很慢的問題,整體來說容器化能幫一些忙,其實它要整個解決,實際上是應用架構的解決和Docker平臺落地才能把這個事情解決掉.舉個例子,我們有一個客戶有一個應用,這個應用部署起來需要上傳20個包,20個包整個存儲空間需要七八百兆的空間.因為它沒有配置管理,所以這個包上傳必須開發人員從自己電腦上手工集成.集成完之后打包上傳,打包完之后這個應用有時候配置項一百多個,你從界面或者多種手段要配置好,上傳和改配置的工作這樣去做需要三個小時,你升級容器沒有解決問題,其實更復雜了,不是我們平臺有問題,你應用架構是有問題的.

第三個就是說并發內容多,這個更多是架構問題,或者整個并發能力解決的問題,可能跟容器平臺沒有什么關系.這些是客戶比較傳統的需求,需要容器、Docker和架構一體化解決的.做容器比較長的不論是我們廠商還是客戶應該有這樣的認識.

剛才講到容器的基礎就是軟件架構,我們看容器化其實對軟件架構是什么樣的,我希望應用是分布式的,如果它不是分布式的沒有意義,你不是分布式,我連彈性都沒有做,容器應用比較小了.我希望它是無狀態的,希望它可以快速定位,我們啟動容器化應用,這樣一個東西上容器,希望發揮容器的更好作用.

DeoOps我們希望體量不要太大,單個應用不要太大,太大應用其實你很難做這種垂直層,也很難把這個流水線跑起來,希望是比較小的,服務是松偶合的,這樣持續交互流水線互相之間沒有關聯,這樣很好打通,到最后做集成.看起來就是做微服務的要求,所以這三個合在一起.

容器平臺建設關鍵問題,我們說傳統行業建設的關鍵問題,我們總結八條.第一條彈性伸縮問題,怎么快速有效的伸縮.第二個配置管理的問題.因為傳統行業的應用跟互聯網公司應用有區別的,畢竟管理是一個難題.網絡問題,網絡問題我今天稍微講一講,我看前面老師已經講了一些內容.

還有傳統行業我們流程跟互聯網公司不一樣的,你從互聯網公司去傳統公司你會覺得流程很煩比較復雜.還有平臺對接,你平臺過來以后可靠性怎么樣,安全性怎么樣,你怎么給我保證的這些問題.

彈性伸縮,基于鏡像啟動一個新的容器,然后把負載均衡器改一下,這個彈性伸縮就做完了.實際上首先你彈性伸縮,你基于什么指標做彈性伸縮,什么時候彈,什么時候縮,我怎么調配新的應用,縮容問題,用戶不夠用怎么辦,用戶擴了怎么辦,底層資源不足我怎么辦?

具體來講第一個彈性伸縮的指標,所有的容器平臺默認支持兩個指標,第一個CPU,第二個內存,可能還有人支持網絡流量,這三個指標做彈性伸縮.這幾個指標有沒有意義,有意義,你基于你性能測試結果,知道什么時候CPU內存到什么程度,把指標配置好,肯定有用的,尤其對CPU內存比較敏感應用是有用的.從一個比較合理的角度來說,最好方式跟應用監控平臺做指標,基于應用監控指標做這個彈性伸縮最合理.如果這些做不到,我們手動彈性伸縮也可以做這些工作的.

還有一個負載均衡的問題,傳統負載均衡用F5比較多,有一個對F5自動配置的問題,需要整個平臺支持這個能力.另外還有一個問題容器啟動了,是不是里面應用就一定啟動了,這個不一定的,到底什么時候應用調動,你做一個應用可用性的監測,確定可用以后把客戶調過來就是可以的.我可以多等一些時間,把用戶調動過來.

另外縮容,你怎么保證用戶在上面,如果用戶在上面縮容了,用戶掉了怎么辦,我們用Session解決這個問題.另外IAAS對接和資源自動獲取的問題,資源不夠怎么辦?需要你容器平臺跟IaaS平臺做最接,VCENTER對接,open Stack,公有云對接.

剛剛講容器化應用的配置管理一定是一個問題,互聯網公司里我們理想狀態下希望有一個配置中心的,這樣配置統一先發的,跟容器鏡像無關,是格式化管理的,你把配置改了甚至都不需要重寫東西,盡量通過一個服務中心做,這樣配置變得非常簡單了.很多傳統行業沒有這么好的條件,也有幾個方案做.第一個環境變量的方式,或者用Kubernetes也可以,我們早期也有直接改配置的文件.它的是開發、測試、生產三個環境都是獨立容器,這個你做好之后也是可以解決問題的.

另外容器網絡,前面講很多,容器網絡的性能一直有問題的,下面圖是我們測容器網絡的性能.前面第一個容器訪問它本身的主機.Docker原生的方式,還有OAS的模式,容器訪問自己的主機,只能達到實際網絡的一半.還有一個問題容器跑在虛擬網絡上,性能會下降非常厲害,甚至下降80%以上都有可能的.這個問題有很多解決方案,京東前一段是開源社區做得事情.DPDK在Docker上有一些難點上,虛擬化上可以做的都實現了,所以我們找到中科院軟件所一起做這個事情,實驗室已經把它解決掉了,還要有一段時間正式應用到我們產品上去.

流程適配問題,傳統公司講我們這邊有很多流程,你這個一定適配我們流程才能用起來.這不是Docker的問題,而是DevOps的問題DevOps怎么做?我們希望落地一個新平臺,落地一個新的軟件開發模式,不要成為一個包袱,我們希望有一個新的應用,有一個新的DevOps試點團隊做這個事情,開發設計階段是偏互聯網方式的流程,到了生產階段,有不同機構的要求,我們走一下傳統流程,保證生產經過流程驗證沒有問題的,這是我們一個想法.

還有一個傳統行業跟互聯網公司區別比較大的地方,開發環境、測試環境、生產環境,開發和測試環境是物理隔離不通的,這種情況下怎么做?實際上來講把開發測試和生產環境隔開,他們之間交互有一個鏡像交互就可以了.

運維人員用熟了很多系統,他要求你平臺適配這個系統,而不是說你容器平臺自帶的管理我就用,比如說監控管理、日志管理,IAAS平臺都需要跟他們平臺對接的,你提供Docker管理的一套系統,實際上你很多能力要在傳統行業里面原有的程序支持.

還有容災的問題,你上了容器之后,兩地三中心這個要怎么辦?我覺得這個好像沒有什么關系,我后來想想可能客戶覺得你把我整個應用部署方式,管理方式都改了,我兩地三中心不知道 怎么管了.

簡單強調幾點,第一點整個容災,兩地三中心核心有兩個部分.第一個是上面負載均衡調度的問題.第二個下面數據庫這一層,存儲這一層數據一致性保障的問題,這兩層其實都是跟容器關系不是很大,當然有一些關系但是關系不是很大.實際上來說容器改變更多是整個應用的發布,應用部署的過程,這個過程需要我們專門解決的,其實方案有跨數據中心統一應用管理的節點統一管理整個數據中心的發布,當然還有不同的策略,屬地中心、異地中心,切換更多是應用方面,負載方面就可以了,其實跟容器本身關系不是很大的.

還有安全性的問題,我這邊正好講的有一些算是不是特別重復的內容.剛剛講那幾個點,容器安全性還有一個大家比較安全的點就是鏡像安全性,鏡像安全性是一個什么問題?首先如果我們鏡像都是安全的,實際上對傳統行業安全的增強.因為傳統行業里面有很多時候,我們的客戶也是在不同地方獲取到不同的應用包、軟件包,而且有很多不同的版本來部署,其實是比較亂的.容器化之后,經過鏡像之后標準化把它底層資源,包括中間件都是標準化的,這個鏡像本身是安全的,是對傳統行業的增強.

我們現在做得事情就是為我們客戶提供標準化的鏡像,另外我們去年開始社區推一個社情,就是關于鏡像安全掃描,我們也推到我們這里來了,做安全鏡像掃描這個事情.

容器部分最后關于運維的可以用性,我們把容器定義為運維管理平臺,從運維發布部署到運維管理,都是容器平臺的能力.其中有一點運維,這是我們給一個證券公司做得服務治理,我們現在比較主流的Docker開源的框架,基本上來說支持Java為主的,傳統行業有C,各種別的語言,我們上面用了幾個不同的架構搭了整個分布式架構的架子,幫它做整個應用恢復架構的服務治理,解決校驗分析、黑白名單、負載均衡、熔斷的問題.整個來講這是從開始創建到最后整個部署,從代碼開始到最后整個平臺.

我們幫客戶落地容器的過程當中我們發現,客戶很多訴求,僅僅落地容器不夠的,還需要做一些別的事情,我個人對這個DevOps非常感興趣,花很長時間研究它,包括參與DevOps的培訓,我覺得確實有啟發,跟大家分享一下.

落地有這幾個難點：第一個架構耦合的問題,我架構耦合之后不管你做什么事,發布速度,包括彈性包括部署非常難做.這個事改掉很難.第二個關于質量控制測試,測試這個事情傳統公司基本上很少有公司說我把自動化做得很好,這是一個難點.第三個交付和發布是我們在做的事情,因為應用部署和容器平臺是解決這個問題的.第四個傳統行業也是求新求變.我們有很多企業說我們要敏捷,我們要上容器平臺,這是它一直做的事情,這個事情只是做了局部優化而不是整體的優化,這樣導致做任何一個事情你感覺起不到效果.

整個來說DevOps全局有什么東西?這是百度張老師的圖我結過來用的,紅色部分是容器部分可以解決的.可以看到這個東西是比較大的框架內容.從數據交付來講也會有提交與編譯,測試與應用,最后交付與運維這三個步驟,沒有一個好的技術架構支持,沒有一個團隊支持,這個事情很難去做.所以說這個事情應該說有一定復雜性的.

具體來講我認為DevOps實施落地的步驟建議是這樣的,第一個需求驅動.什么意思?首先我們大家都比較痛,一定要解決這個問題,剛才我講了它推起來非常難.

第二個試點先行.你找一個東西試點,你在原來框架里面改改把這個事情做了不可能呢,這是我們去年幫客戶做咨詢的時候提的,你找一個應用,這個是互聯網應用,跟兼容關系沒有那么緊密,你來做一個事情可能比較容易一些.

第三個獨立團隊,你找一個獨立團隊干這個事,你先有一個新流程把這事辦了,最后看效果怎么樣,有了效果之后,大家再來去做這種更新,想辦法把它推廣出來,這是比較合理的方案.最后一個先架構再平臺最后流程.先把架構這個事做了,一定要把基礎打好,然后你再做一個平臺把這個事固化下來取得效果,最后我們適配所需要的流程事情,這樣比較容易落地,是這樣的.

最后一點我們是2012年成立的創業公司,我們要解決我們公司的事情.我們以容器和運維為主的創業公司,2012年成立.目前來說我們主要客戶都是金融客戶,而且以做容器為主的,還有自動化運維這樣一些產品的公司.今天我分享的就是這些內容,謝謝大家.

文章來自微信公眾號：云計算開源產業聯盟

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4173.html