《專家觀察 | 馬全一：“ContainerOps DevOps編排”》要點：
本文介紹了專家觀察 | 馬全一：“ContainerOps DevOps編排”，希望對您有用。如果有疑問，可以聯系我們。

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

嘉賓介紹：馬全一

公司職務：華為技術有限公司資深架構師

大會演講速記

我分享的題目是我們華為目前開源做的一套DevOps的產品,我們把它定義為ContainerOps,我們講了一個新的理念,DevOps編排.

現在在容器社區大家都講容器的Container的Orchestration,容器的Orchestration其實是底層調度管理,針對資源的應用,有點像OpenStack.但是真正在業務層面其實還是需要編排,你的業務的應用,你的DevOps的任務其實都需要編排,所以我們在容器編排的基礎之上做了一個DevOps編排的系統,我們叫它ContainerOps.

這個是我演講的主要內容,前面兩位嘉賓也講了到底什么是DevOps,到底怎么來的.后面會講我們是怎么看DevOps的,依據于我們對這個產品的理念,設計的ContainerOps,還有一些它實現的細節,還有為什么要這樣做.

先說什么是DevOps,在我個人理解,這個里面講的是DevOps這個詞的來歷,它不是一個大牛怎么樣,設計了一套理論,然后定義為DevOps.

其實整個產生過程是比較有偶然性的,最早在2007年的時候有一個歐洲的比利時的顧問Patrick,他在顧問的過程中經常會遇到研發團隊還有測試團隊還有運維團隊之間溝通的問題,遇到很多障礙,所以他一直在思考,因為他也算是一個敏捷的教練.2008年在多倫多敏捷的會議上,他們去聽一個議題,安格的議題,但是他去了以后安格這個人并不在會場上,因為沒有人去聽,所以那個講師以為沒有人他也走了.他在大廳里才把這個人找到,兩個人聊了很久,兩個人對DevOps遇到的溝通的問題有很深刻的共識,所以他們兩個人發起了一個敏捷的Workgroup,在里面討論.DevOpsDays,在后面一段時間里,推特有140個字限制,他們就把Days去掉了,從那個時候開始就出現了DevOps這個單詞.

所以其實不是誰設想的這個理念.在2010年的時候快事有DevOpsDays的會,這個會我在2015年的時候參加過一次,有很大的宴會廳,擺了20張桌子,有一個白板,大家把自己感興趣的議題貼上,你在第幾桌,所有感興趣的人可以坐過去跟你交流.

在2011年的時候,Gartner象限報告里第一次把DevOps放進去做一個統計.在2012年采訪Patrick的時候,他說他很偶然的選擇了DevOpsDays這樣一個單詞,很偶然的把Days這個單詞去掉了,才產生了DevOps,他其實并沒有說是一個Master,要設計一個很大的理念去做什么事情.

所以從整個來看,DevOps其實就是在迭代過程中很偶然產生的東西,其實不是一個定義出來的東西.所以他沒有一個完整的定義說到底什么是DevOps,被所有人覺得是共識的一個DevOps的定義,他也沒有一個像剛才說的微服務,中文叫12條軍規,你滿足這些你做的就是微服務,他實際也沒有.

這個DevOps的定義,看完以后發現對你工作一點用也沒有.我個人覺得,DevOps其實是一個無形的,應該是貫穿你整個工作過程中的一個追求,你是要把整個溝通的成本降低,把整個研發的效率提高,把你整個應用部署上線的時間縮短.最終目標是把你研發、運維還有測試,包括你的商業團隊,包括你的Marketing部門之間的隔閡打破.

怎么做到這點,商業和你的研發運維的這個邏輯之間,你其實要一個快速的迭代和響應,比如他的需求過來,你能在很短的時間幫他實現,這時候你的流程變快的時候其實就沒有這個隔閡.在研發內部加快這個速度,讓它整個最后變快.

我個人覺得要做三點,第一點,你要把在你生產環境下的,你將來上線環境的描述、定義要盡早確定下來,并且跟你研發的環境要保持一致.這點像Zabbix,很多的運維管理工具其實都在做這件事.其實更簡單的做法,就用一個容器,這是最直接的解決方案.

第二點,你要把整個的流程定義好,這個流程其實還是要反復的去調整修改,根據你的業務,比如Gitlab有三個,Master,Production、duction,預生產、生產,他們的Gitlab.com可能是適合這種方式,但適不適合你,還要看你整個團隊的素質情況怎么樣,你研發產品的情況怎么樣,這個過程其實你要去定義它,不停去根據你的業務情況去調整.

第三,你盡量讓一切都做到自動化,當然是我們每個做研發做工程師的終極目標,什么都是自動的,不需要我了,我只要看著就好了.這個過程還是很難的,我們追求的過程,其實在很多業務流程里,有的時候還是要有個老板出來說確定你要上線,點個按鈕你才能做.所以我們在產品設計里也要預留這樣的接口給他.

DevOps現在講的,從去年開始這個理念比較熱,但是真正在做這件事情的時候特別難,你在團隊里面去推,說我要做DevOps,其實都遇到很大阻力,我也跟很多公司還有team都去交流過.我感覺第一點就像這張圖一樣,我們經常會說,可能新來個總監來個老板,說我原來用過什么,有成功的經驗,我們要換個監控系統.這個時候有個很大的方向,業務團隊不管怎么樣,已經在往前走了.

這個時候換個新的輪子,你跑得更快,這時候所有的團隊都會抵制你,不管你的初衷是什么.當我推一個新的東西給你的時候,我第一點是給你承諾,你原來的工作不用做修改,或者非常低非常少的代價的修改,保證你原來的流程,大家原來做的事情不要動.

第二步,我們會有一套工具,幫你原來的流程能夠copy過來,上來以后我們在這個流程之中利用這個工具灰度的能力,慢慢的一點一點去改進,讓你整個團隊往前跑,而不是我上來說我們要配套新的系統,大家明天晚上來個通宵,然后把事情干完.這種方式肯定不可以.

基于這種理念我們去做ContainerOps這個產品,我們講DevOps編排,這里我們產品有三個理念,第一個,有很多都用Jenkins,很多情況下我們還有工程師喜歡寫一個文件,當你的研發團隊變得很大的時候,一個DevOps這樣的配置文件,你反而變得不可控.第三個,我們把所有的要執行的工作全部都容器化,由kubernetes來執行.第一,要減少你對環境的依賴,第二,你用kubernetes的時候其實你增加了很多的管理的能力.

我們怎么去把一個原先的任務變成一個Component,比如你要在一個流程里用到它,你一定要給它傳遞一些數據,比如最簡單的,我告訴他一個github的地址,他做一次任務,你也要傳一次github的地址,我們定義了傳遞的方式,以Key/Value的方式,只盯這個環境變量的名字,任務完成之后要把結果輸出出來,這個時候直接向系統的標準的log輸出,你打的時候告訴你格式是什么,如果你執行結果,以確定的方式打出來,我們會把所有容器的打出來的日志全部收集在一起.

第三,你做一個容器的鏡像,如果是Docker一定要選一個base,當然你有無數的選擇,我們推薦的是github下的phusion/baseimage,很關鍵的一點,Docker的鏡像其實是一個容器鏡像跑一個應用,如果你的DevOps很復雜的時候,你可能需要里面比如說裝一個數據庫,然后再跑一個任務,這時候怎么辦,它里面做了很多預先的設定,讓你很容易在里面跑幾個鏡像.

當你去寫這樣一個東西,比如你把一個原來Jenkins的封裝成容器鏡像了,這時候你去測試它的時候肯定會有各種各樣的問題,如果你用了kubernetes測,你會發現再去找各種情況日知會很麻煩.這個鏡像是默認開了SSH的Server,所以你可以直接就進去看里面的狀況.

我們為什么沒有選擇上kubernetes Pod的概念,Pod是幾個Container連在一起完成一個任務,而我們選擇的是一個容器內你用幾個進程?兩點.第一點,當然我們做這個東西現在我們這個產品是依據于底下的kubernetes平臺的.但是你這樣一個Component如果是單一的不依賴于Pod這個概念,你還是可以使用Docker的引擎.我們選一個Component,一個開源社區它的成功,技術當然是很重要的一部分,關鍵的一點是你有一個share的topic,比如Jenkins大家都用它,它有一個龐大的plug in的倉庫.

Docker大家也都在用,因為有一個Docker Hub,里面有幾十萬的倉庫讓你選擇.包括github,有很多替代的,這是它的優勢.你說它最大優勢是什么,當然它的Git托管能力上很強,除了這點以外其實它沒有別的,作為一個商業產品,技術優勢跟別的差距不是太大.所以我們也定義了一個新的Component的概念,我們要依據這個方式讓它產生一個大家可以交流的東西,我們再去做一個host,然后把這個社區做起來.

方式,如果你用plug in,你可能要找到它,下載下來,裝到Jenkins之上,要找到它運行的環境,把這些找到跑起來測試,最后沒問題了.你要用的時候只要知道它的地址,粘到這個系統里,然后你就不用管了,它運行的時候,kubernetes會幫你把它從服務器下載下來,運行完以后,kubernetes的Master再把它干掉,后面所有事情都不用做.

我們覺得這個方式要比plug in的方式更合理一些.我們w會去做這樣一個Component的公共的Service,我們也有開源解決方案,很簡單,第一個,我們跟Docker的Hub學了一個Library,你可以直接來用,你自己也可以上傳管理你自己的.因為它是Component,是容器的,底下有個Registry,這一塊我們后面會開源出來,包括我們也會做一個華為 host Service讓大家來使.

這個是Component的模型,你底層有baseimage,把所有的東西輸出到系統的stdout,包括錯誤信息,Docker會利用命令把所有日志抓出來,在每個節點上會有一個進程,會把所有的日志收集出來發到處理的模塊.

處理的邏輯是這樣,這里把所有的日志都抓出來,發現道路這個模塊,第一件事就是把所有的都存下來.這里開源產品我們選的是TiDB和TiKV.這里可以自定義一些處理的流程,因為我們會打特定的標簽出來,這個時候你可以針對它去做一些處理,處理完之后會把結果發到處理的節點上,知道到底成功還是失敗.

這是最簡單的工作流,它的方式,第一,這里定義Stage,可能是根據業務邏輯劃分的,每一個方塊是一個action.第一執行完了執行第二個,然后執行第三個,每個action是并行執行的,action里面確定的是一個Job.這里有一些它的屬性,我們做了很多特性,比如說你可以設置整個環境變量,可以為它設很多的標簽,比如我們前端時間咨詢的情況,某銀行跟我們講他有5000條這樣的流程,他想分組來管理,每一個做一個分組的名稱.

你如果在整個的流程中需要人為參與,你要方法一個特殊的Stage在這里,它會通過一個E-mail發出去.隨著里面這個就是一個Job,這個是那些環境變量傳盡量的那些KV的值,包括輸出的.在它執行之前,你可以先去寫一個腳本,確定你到底要做什么事情.為什么要這么做,因為我們這個東西做得不太像專業的Workflow的產品,其實更多是傾向于DevOps的,所以它沒有流程控制能力,也沒有循環判斷.我們要給研發或者是團隊提供這樣的能力的時候,給他一個讓他執行腳本的方式.最后還可以再一次執行一個Lua的腳本來確定.

這是這個界面的設計,這是第二版的設計,第一版比這個更酷炫一些,我后面會講一個案例,在實際使用當中發現用起來并不是那么爽.這個是日志輸出的情況,我們把這個項目拿到TiDB那家OpenStack的廠商去做,第一個,他們是開源的,所以他們每次都要經過Travis CI的檢查,這是第一步.

然后要執行1000萬的數據庫,執行完以后要根據用戶實際場景測試,7×24小時,按照用戶的場景把他數據庫的節點部署好,不停的跑測試用例.整個DevOps分成這三個階段這三個階段不能連寨一起第一個是在用戶服務,第二是在他辦公室自己的機器做的,第三個是用其他云的,管理起來比較麻煩,很多個交付,很多個任務,需要去寫一些東西出發的.

github第一次Pr以后,我們把它原來的測試全部變成Component的測試,放在kubernetes平臺執行.執行完以后調API,告訴github可以PR,再把MySQL的所有測試用例用kubernetes再跑一遍,這個跑完以后就會通過他們內部的Slack的team,然后說這個已經過了,包括性能的情況.然后再去這個7×24,有個手工觸發的地方.這套測試大概花了我們十幾個GCE的高配的虛擬機幫他來做,他原來整個流程跑完需要幾個小時時間,我們幫他能做到1小時之內甚至40分鐘,我們當時遇到的問題不是說調度管理的問題,而是他們有一部分的代碼編譯速度特別慢,包括在GCE上特別慢,所有時間消化在那上.

我想解決第一點DevOps遇到的一個問題,很多公司說我要把DevOps提高,我要怎么怎么樣,然后把時間縮短.但實際上是怎么樣的,當然華為不一樣,華為有編譯器團隊,我們可以說我們編譯的跟別人就是不一樣.一定是投入了更多的資源把你的任務分開.

帶來的第二問題,作為一個公司來講,這時候他就要來考慮,我做這件事達到這些效率,花的這些錢值不值,可能我們覺得DevOps越快越好,但是很多公司不是這樣的,他說這個方式雖然很好,但是我不想出這么多錢干這件事,雖然證明這個流程可以.

DevOps選擇的時候還是要依據很多條件,你要做這個事情,第一你的組織結構是什么樣,第二你團隊的整個成長歷史經驗包括積累是什么相同,更重要一點,你做的項目是什么樣的,這個項目是不是需要那么多的流程,需要那么多的工具支持.最后你把所有的資源核算,算清楚我做這件事情的代價是什么,我的工程師要不要去breaking down我目前的工作流程.不是說越快越好或者花越來越多的錢越好.

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

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