馬全一:ContainerOps–DevOps編排系統
經過了十個城市的路演,華為HDG線下沙龍終于來到了首都。在北京,開發人員之多,關注的技術領域之廣,討論的話題之深入,堪稱HDG歷屆參與討論者之最。
馬全一是華為DevOps***架構師,他告訴記者,在他《ContainerOps–DevOps編排系統》的演講中,關于 ContainerOps 的架構細節和演示 Demo 是在之前沒有公開過的,是北京站***次公開的內容。同時他還考慮到了很多開發者的訴求,例如在當前 DevOps 領域存在多種工具、服務,割裂的工具鏈造成用戶完成 DevOps 流程需要使用多種工具;此外,開發者們往往都會遇到的在多種工具之間傳遞事件數據只能靠腳本這種情況,維護成本高,以及各種 plugin 學習困難,使用環境配置復雜。
以下是他的現場演講實錄:
我這個是延展型的ContainerOps的,這個項目我在擔任華為之前就做的,因為我當時在做docker的社區,所以對docker比較熟。我自我介紹一下,我叫馬全一,剛才李強也說了,我其實最早在國內做docker的社區,對這個技術早期的時候還是比較熟悉。
今年我跟華為的PaaS團隊一起做,我主要是負責PaaS里面DevOps的一部分。我感覺在華為里面的架構師,其實身兼數職。華為的產品都是技術性的,所以華為的架構師相當于互聯網公司的產品經理+架構師的特色。所以這個產品有什么特點,很多細節的地方都是架構師來決定,但是大方向還是由客戶的需求,還有我們的判斷來做的,但是很多細節的地方都是由架構師來定的。包括研發我們要做到***層,甚至參與開發,這是華為架構師所做的事情。現在我們在做的社區架構師,也要出來講自己的產品,這是我覺得不太一樣的地方。
主要的內容就是,我們講一下我們對DevOps的理念是什么,講一下我們產品的特點ContainerOps。我主要講開源的一部分,這個跟我們上個產品最終的版本是一樣的。上層的調度管理其實是一致的。在整個產品的設計里面我們講一個Component的概念,就是DevOpsComponent,***我們會講一下整個調度引擎,還有一個demo,有幾個視頻,我們demo的視頻給大家放一下,讓大家看一下具體的形態是什么。
我們先講一下DevOps的由來,DevOps這個詞最早其實沒有這個不詞,2007年的時候有一個工程師,他在歐洲是做商業的咨詢項目,在歐洲的環境下有很多獨立的顧問,比如說做一些安全的咨詢,或者DevOps的咨詢。這個人以前是做咨詢的,他在咨詢過程中發現研發團隊和運維團隊之間,當時也不叫運維團隊,他叫系統管理員。發現團隊之間的交流有很多障礙,有很多隔閡,所以他一直在思考這個問題。
這是對DevOps的解釋,我看了這么多資料,覺得對我來說DevOps其實就是一個理念。它其實是一個方法論,這個方法論其實沒有一個固定的形態,就像前面說微服務沒有一個最終的答案,也沒有一個最終的結果。我覺得DevOps同樣是這樣情況,它其實是解決你的,就是讓開發人員最有效的,***發揮你生產力的一個方式,在我看來應該是這樣。這張圖很多人都在用,研發、測試、運維交織在一起,其實就是一個DevOps。我是2000年開始工作,那時候我工作的公司也不大,團隊比較小,像我這樣去了以后當時認為就是新手,從前干到后,裝機啊,跟客戶做服務啊,編內核啊,寫程序啊,所有事情都要做。我感覺那時候我就處在這個位置上,所有的工作都是我自己的,或者一兩個人來做。現在的情況,人力模型已經不一樣了,現在團隊都比較大,做前端的就是做前端,做后端的你說我做數據庫的,做DBA的,其實都不管寫代碼。這種情況下相互之間有溝通的時候,就容易產生這些效率低下的問題。
怎么解決這個問題,我覺得DevOps整體的目標就是把這些溝通流程的問題打破,讓你從前到后能夠很順暢的完成它。這三點是我自己總結的,***點你在研發的階段一定要把你在生產階段的這些事情定義好,你生產的環境,你部署的方案。這個事情我的感受是來自于我開始做容器,以前你做研發的時候肯定是運維會負責線上環境的一致性,你說研發根本碰不到,你也不可能拿到賬號密碼注冊之類的。你做了容器之后,其實你已經把所有運行的環境封裝在一起,這個時候其實很容易就達到了你在研發的階段,就能夠把你生產環境的定義做好。其次你要把這個流程定義清楚,這是我加入華為之后***的感受,就是華為里面有很多很多流程,其實你做每件事情里面都會有一個定好的,你要向誰申請,這個申請由誰來批注,然后怎么樣。這個流程定義之后,像我們出差各種方面其實把這個工作流程填好就可以。如果研發里面一個項目的一個產品,它的運維,它的這些方案,比如它的回滾的機制,所有的你都能定義好,你整個相對就會比較流暢。現實中的很多問題,今天老板外面聊天很開心,回來跟你說你要做一個特性,明天要上線,沒有時間定這些東西。所以你要把流程定義好,知道真個工作大概的時間。你希望速度加快,就是你把所有能自動化的,當然這是理想,能夠自動化的全部自動化,盡量少的人工參與,才能夠有這樣的效果。所以基于這些特點,我們在設計PaaS產品,DevOps產品的時候,想的是應該以容器的方式做DevOps,這是我們產品最核心的目標。
這個沒有太多想講的,這是Cloud Native 。我們現在在做容器的DevOps,容器其實屬于CNCF基金會的一個范疇。CNCF就是 Clound Native Computing Foundation。Cloud Native 是什么呢,這個JoeBade以前是Cloud Native 的一個產品經理,去年離開的開始創業,我記得后來做投資,后來投資不行開始創業了,現在跟Cloud Native 另一個沉淀,以前CNCF的一個國內的代表,他們出來創業。這是他對Cloud Native 的定義,我根據他的那些定義,因為這篇文章其實是沒有公開的,是在Cloud Native 內部應用列表里面,加了這幾點。他其實是定義了Cloud Native的范圍,我看完之后其實還是不知所云他講的是什么。我心里覺得Cloud Native 很簡單,就是你的應用以容器的形式封裝,可以在任意的服務器,任意的云的服務之間,可以流動,這時候你的應用就應該是Cloud Native 。我認為只要是容器化的,就應該符合Cloud Native 。他這里講了很多,其實擴大了一些概念,這個我覺得可能是一個商業的目的,并不是一個技術的目的。
這是我們華為在做的ContainerOps。我們講的概念是什么呢,我們講DevOps的編排。是什么呢?我個人是這樣覺得,應用前面講DevOps是一個方法論,所以如果任何一個人,有一個公司,或者有一個產品項目推銷,包括華為。如果他說他能夠解決你DevOps的問題,我覺得他一定是忽悠你的,三個字叫大忽悠。沒有一個工具,沒有一個產品,能夠完全解決你DevOps的問題,他只能涵蓋你DevOps中的一部分。DevOps應該是從始至終,從你團隊成員的教育開始,包括你流程的定制,包括你項目的特性,針對所有這些東西來去定制,形成整個一個DevOps的流程。所以我們做DevOps解決的一個問題就是,我們解決DevOps里面有很多很多工具,有很多插件,你還有很多自定義的事情。我們解決如何把這些自定義的事情編排在一起,形成一個有效的DevOps工作流,這是我們解決的問題。我們也不能完全解決你DevOps所有的事情。我覺得你如果要實施一個DevOps,在你公司的內部應該是你有很多工具,有選擇好某一個適合某一件事情,然后把它串在一起,然后再有一個Consultant4來幫你咨詢說你在某些地方是需要如何改進。然后反反復復這樣不停的迭代,你才會形成一個好的團隊,能夠做DevOps。11這是我們對DevOps的認識。
我們講Component。Component的概念是什么,在我們這里***個你原來所有自定義的工作,這個Component是由我們這個平臺來幫你維護整個生命周期的。它是一個比較合適短時間的任務,比如我要掃一篇代碼,檢查一篇代碼格式,有一個PR上來以后,你掃一個代碼格式,說這個提交不行,或者它沒有簽名。這些短期的任務,是由Component來完成。這個Component從運行到它的結束,所有的這些工作是由我們這個ContainerOps平臺來幫你來維護。我們會把它下放執行,這個我們管它叫做一個Component。其實很簡單,它就是把DevOps的工作封裝在一個容器里。我們覺得如果你做一個Component,或者你希望找到一個Component,沒有這樣的環境,這個生態并沒有發揮出威力,包括我們的產品也沒有。所以華為會在下個月有一個服務,sh的運營。這個opshub是我們專門用來存所有Component的,你可以把你做好的東西存上來。我們也會做一些,在我們給別人實施過程中遇到的問題,我們自己有做Component,也會存上來,我們也希望用戶能存上來。你再做你自己DevOps工作的時候,可以先在上面找搜,找到你需要的東西,就不用再做了,你拉下來執行的時候也不用關心它到底是什么樣,它只是完成你希望的工作。
為什么呢。這是我們對它的封裝。這個(19:11)你可以認為就是一個docker的(19:13)。我們在未來會提供其他的,(19:15),因為這是現在業界標準的一些格式,我們會支持多種格式,我們會把它做一個轉換。只要你用(19:25)先做好,我們會在上面講的這個服務里面幫你做轉換。在一個鏡像啟動以后,我們提供很多環境變量給你,這些環境變量代表不同的意義。這是我隨便寫的一個程序,你把環境變量拿去做事情,跟我們整個平臺做交互。其實這些環境變量多數帶來的是(19:54)的地址,安全我們的要求pose出來,我們就知道你在干什么。這是你在做一個Component的時候要設計一個環境變量,你在定義工作流的時候還可以設計很多其他的環境變量。你可以在***步工作的時候,把這個環境變量設置一個值,比如dete的值,另一個容器引擎,另一個容器的Component再去讀這個值,這樣你可以達到數據傳遞的效果。這個效果其實有些麻煩,我們還有其他的機制。比如說這里一個COdata,其實它是在容器啟動的時候傳入數據的環境變量,整個是一個JS的數據,所以你在這里可以拿到JS的數據,支撐你數據的運行。然后(20:53),你在所有結束之后,把你輸出的定義定義一個JS進去,然后pose到這個地址,這個地址會傳遞到下一個。
整個流程是這樣的,當你***步啟動的時候,你可以從COdata拿到你需要的業務數據,這個Component變量會帶來一些,比如你在哪個工作流里面跑,你的ID是什么,這些信息會用于你跟這邊的交互。第二步就是你向Component(21:27),我們的平臺就知道你的容器啟動起來。但是我們可以調動(21:35),我們覺得在這個里面可以直接讓你給我發一個消息來的更直接一點,這樣減少跟(21:44)的交互。減少這樣的交互,有利于將來我們整個這套東西移植到其他的平臺,比如說(21:53),或者是其他的PaaS平臺里。你告訴我們你的容器啟動以后,你去拿一些環境變量,你可以開始執行你的任務。但是執行的時候,之前你給我一個消息,我知道你開始執行了,在你執行的過程中反復的向狀態的地址pose數據,我們就可以拿到你的中間輸出。在你***結束之后,你pose一個消息給我,說這個任務執行是成功還是失敗,你把你需要傳出的數據在這了,放到http的包里面發給我們。我們可以把這個數據傳遞到下一個執行的任務。***你發一個stop的消息,我們整個平臺就會把這個容器干掉了。這邊就是在執行過程中你可以讀取你設置里面的環境變量,有可能是***次設的,也有可能你從其他容器里面得到的。
這里給大家放一個視頻。這里就是說如果你做好一個容器的Component,你看到現在這個界面是我們開源的界面,你就把它注冊在這個平臺里面,這是你做的。你也可以給它指定一個版本。這里其實是一些特定設定的名字,你來設定。andpoes是指這個容器的地址,我們剛才會專門給開發者一個(23:57),你也可以用docker(23:59),或者用其他國內服務都可以。這個主要是分辨率的問題,因為我錄的時候是1080P的,估計這個線的問題。下面會有一些設置,上面黑色的部分你的容器是跑在(23:32)的,將來我們會把(24:33)其他的都拽在這里。這里你可以分配一些資源,我這個任務跑的時候要用到CPU多少內存。這里是定義,我們前面講(23:43),你會傳入一些jason的數據,你可以把jason的數據直接寫在這里,這是你輸出的數據。你把它注冊在這里的時候,所有人都知道怎么去用它,因為他知道傳入數據和傳出數據是什么。這個做好了一個容器鏡像,就保存在這里了。這個后面還會再做一些其他的鏡像。
這個就是我們怎么定義整個工作流的過程。在這個起點一般的指令是寫一個倉庫的地址,我們會告訴你一個UL,你放在(26:47),它會傳遞這個數據。比如你設置是PR的數據還是(25:51)的數據過來。這里面是定義step。現在很多公司都是用(26:03)做DevOps,有很多網上的資料或者很多假的說,有建幾個step,比如說(26:15),有各種各樣的step。我們這里推薦按照你自己的業務邏輯建step。
我們講一個例子,最近我們這套東西跟(26:31)在合作,它是國內一家在做分布式數據庫的公司。所以他們把他們整個的DevOps分成三個step。***step是什么,他們在他們的分布式數據庫叫(26:46),其實是下面一個KV,上面一個SQL的解析層,它的整個這一套是兼容MYSQL協議的時候,所以它有2萬5千個MYSQL的測試用地,要在它的程序上跑,它把這個定義為***個step。就是說我公共測試,你任何一個開源的PR過來,我都要跑2萬5千個測試,保證你能夠兼容MYSQL的測試,這是它的***個測試。然后他認為這個應該是一個step。我們跟他分析的時候,這2萬5千個沒有順序跑肯定不行,我們根據測試的關聯關系分成很多(27:21),每一個跑一些測試領域。在一個step統一時刻,就跑三個或多個,就把2萬5千個執行。
第二個step是什么呢,就是它每天晚上都要做一遍測試,這個測試是什么,就是把當天所有合過的PR,比如當天合了6個PR,把這6個PR合在一起,生成一個要測試的版本。在當天晚上再去跑一個測試,這個測試關注的是性能。我今天合的6個PR跟昨天的版本,之間性能上有沒有差距,這是它要關注的水平。所以在當天每天晚上去做這件事情,我們又給它發出一個step。
第三個階段是說,***我要做成一個產品的時候,我要做一個7×24的測試,所以用了很多很多服務器的資源。比如說它要裸機,要有虛擬機,因為它是分布式的,要在可能不同的云服務廠商里面切很多機器來去測。不停的殺掉一個節點,看它的服務是不是完整,一致性是不是得到保證。所以這個時候我們認為這個測試不是一個每日的,而是要根據版本,對于我們來說就是打標簽的時候要做。所以我們又劃分一個step,所以在那個step里面執行。
我們目前這個開源版本里面,它對接的頂層,一個是(28:58),另外我們現在在做的就是能夠對接各種云服務廠商,比如說AWS(29:02)這些云服務廠商。因為沒有一個服務廠商能夠開放所有的API,讓我既能調動測試容器,又能調度測試邏輯,又能調度VM,沒有。所以我們只能不同的環境,來實現(29:19)那個需求。但是在我們商業平臺PaaS平臺里面就不太一樣。這個待會下一個講師會講,資源調度那一塊,我們能夠支撐不同的任意資源來管理。所以如果在這個測試領域里面,如果在商業版本里面,其實底層已經把虛機、裸機,還有容器所有這些環境都已經覆蓋了,所以就不需要再去兼容這些了。
這個我們劃分為三個step,其實你不需要按照網上很多,包括AW上面有各種Step的模板。而是要分析你自己實際業務的情況,然后去定義一個合理的step,來去做。所以我們認為這個step應該是你創建來做的。
這個調度完了整個的情況是什么,在我們平臺的位置,后面可以調動其他云的服務。上面我們會有其他開源的產品。它其實是一個容器鏡像的可以看到一個增強版的,支撐更多的格式。是專門做容器或者一些其他工具的構建。它最主要是把你任何一個工具,把你的構建任務變成一個docker,放在下面整個的平臺執行。這是我們明年計劃會做一個bet服務,我們會重新重寫bet的后端存儲。我們按照bet的存儲格式,因為bet在服務器上是一個倉庫,一個目錄,所以一個倉庫是不能橫向,只能用多個拷貝的方式來應對多個并發。我們是把整個文件,因為上面其實是一個Kvalue的文件,我們把這個文件K和value安全按照bet協議解析,插到分布式的數據庫里面。這是我們商業版本要做的,經過測算認為我們可以做一個15T到20T的bet的倉庫,是一個高并發的訪問。因為我們在華為內部也有很多代碼,代碼量也很大,也遇到這樣的問題。
CI和CD明年都會有對應的開源的產品,這是整個的架構。通過這個引擎調動起來,流程就比較簡單了。***就是你在WorkFlow里面會定義一個工作流WorkFlow,WorkFlow這個在你的版本提交里面會提醒WorkFlow引擎,會告訴你構建做一件事情。每一步構建完了之后,會把產品存在倉庫里面,再把它拉出去做CI和CD。這個流程相對比較簡單。
我們看整個構建的時候是怎么做的,這完全是一個拖拽的工作。剛才選的是用哪個compent,在每個里面都選一個自定義的工作來做。它畫了一個這樣的線,就是說在你傳入的數據里面會發到這個(33:09)里面來。這邊是對應傳出來的數據,我們把它解成數據,這邊是傳出的數據,會按照同級來匹配。這個輸出之后就直接傳給它,這里演示的是一個傳出的沖突,這樣手工能把沖突解決掉,形成正確的數據流。
其實我們在整個項目里面最復雜開發的是這一塊,我們是怎么做數據傳入和傳出,就是我們在compent已經定義了我傳出的是什么,傳入的是什么。我在不同的組建中間定義好,提供這樣的工具。
我們剛才講的是從這里到這里,是這樣的一個傳輸的事件定義。在這里你可以把兩個組件輸出的事件傳遞到一個里面。這種情況下就會有沖突的可能,因為你同級下面兩邊傳的是一樣的,系統會自動的幫你把沖突的地方找出來,讓你來選。紅色都是沖突的,你選擇一個以后,把不需要的點叉,都占掉。這個就是剛才那個demo,給大家演示的那個。
這是整個引擎,整個WorkFlow執行起來的情況。在這里先偽造一個post的消息,這是它post的工具,把這個地址URL換了,偽造一個post的工具,中間傳入的是一個get someting的地址,中間應該有很長時間的等待。在這里我們默認在自定義的時候,你可以定義的地址,因為是響應最多的。比如你在某個流程里面需要手工去做,你可能要把它嵌入到整個工作流里面的時候,你再發一封郵件有一個地址,你post地址,整個WorkFlow就往下執行,這是它執行的結果,有的失敗了,有的成功了。這是當時成功執行以后,都是綠色的,如果是失敗的話,就是紅色的。這個是一個執行成功的。這里會看到它輸出的日志。
整個的UI就是這個樣子,因為這個版本是我們在上個月CNCF基金會上的版本,跟現在這個版本有點出入,界面上做了新的調整,要比現在的更好一點。這里是我們講的WorkFlow為什么要做這件事情,我們不希望用戶把你所有的工作全部遷移到這個上面來,因為你研發的流程是一個持續的過程,不要中斷它。但是你可以把我們WorkFlow的引擎做一個***層的編排調度,可以在構建的時候引入你自己的方案。
你再往前修改,再去演進的第二個。因為我們明年會有測試工具,你說現在沒有,我自己有一些測試的方案,可以在這一步的時候把它再引進來帶,形成一個新的測試。
這是我們整個ContainerOps的設計情況,這里其實沒有更多的代碼級別產品的實現,因為我們還會在http所有的活動里面進行講,大家可以去關注,因為我們會直播。這里Orchestration,這是我剛才講的,我們會把compent我們收集到的,我們跟社群里面合作的,都會在這里。下個月這個服務會發布。當然你可以認為它是一個dockerhap,但是我們不希望你把它當成一個dockerhap來用,你存個幾十G的東西在我們這里,其實對我們壓力也很大。因為這個所有的費用全是由華為來出的。因為華為所有的開源都是建制北美,所以我們所有的服務都是在北美做的,放在GCE上,所以所有的費用其實挺高的,包括整個拉下來。這個網站只是一些簡單的介紹,我們會在明年Q1的時候,會把你剛才看到的界面重新整理成一個服務,你可以在上面調度你自己的產品,當做一個是開源的服務。如果你的項目是開源的,或者是比較小的項目,你可以在上面定義工作流。你可以用我們做的compent,也可以用業界已有的。
我們現在跟社區有一個合資的計劃,我們會單獨量身訂做整個workflow,像我們都會直接跟所有人聊他們的研發流程是什么,我們幫他去劃分這些(41:52),做這件事情。如果你是一個開源的項目,你的項目比較符合,比如說你是容器的,還是分布式的,還有微服務,如果你是這樣的項目,如果你希望我們來幫你做的話,我們也是可以做的,但是這是需要雙方來有一個合作的協議。這部分做的所有的CI的資源,所有你做構建的資源是由我們華為來做的。但是我們還是希望這個開源的項目符合我們對項目的定位。還是兩部分,一部分如果你是商業想用企業版本就是聯系我們的銷售,如果你是開源項目,你可以跟我們聯絡,我們可以幫你來做,我們可以派一個工程師上門到你的辦公室跟你去聊,怎么做DevOps,怎么用我們的工具把你DevOps流程做好。如果你說我只想試一試,你可以再一兩個月,明年我們就會發布服務,你可以在網站上試。
這就是我們的口號,整個膠片我在北美講的是英文版的,所以回來的時候沒改,就是這樣。
(結束)