由工業和資訊化部指導，中國資訊通訊研究院主辦，業界知名組織雲端計算開源產業聯盟（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我目前的工作流程。不是說越快越好或者花越來越多的錢越好。

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