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

嘉賓介紹：淡成

公司職務：紅帽軟體（北京）有限公司高階方案架構師

大會演講速記

淡成：大家好，我叫淡成。今天介紹的主題叫《當DevOps遇到容器》。兩個關鍵字，DevOps和容器現在都非常火，我們今天這個大會有兩個分會場就專門講這兩個技術。

為什麼會想到介紹這個話題，因為我是售前工程師，我的日常工作會和各個不同企業的客戶去溝通他們遇到的一些技術上的問題。

最近一段時間，在企業裡面我在溝通的時候遇到最多的問題是這樣的，很多客戶說我們現在聽到了我們自己用了很多DevOps的工具，比如像Jenkins，比如像程式碼檢查的工具。現在社群裡面的容器技術又這麼火，我自己的DevOps其實已經做得挺成熟了，我用了Jenkins，每天可以釋出一個版本，釋出一次可能也就十幾二十分鐘。在這種情況下你說我還有必要使用容器嗎，用容器能給我帶來更進一步的好處嗎？

因為我們在公司內部推廣的時候，我們的技術人員其實是有一定抵觸的，他不管開發還是運維人員，他都需要掌握新的技術，他要了解怎麼在容器開發，怎麼做容器的部署和運維。

我覺得有必要在這裡面和大家討論一下，到底DevOps整個流程過程中哪一些地方可以使用到容器，容器可以帶來什麼樣的好處，它有什麼樣一些技術的限制。

DevOps的概念前面幾位嘉賓都已經講了，2008、2009年就已經有了，其實在實踐裡面剛開始做得最好的就是這個片子。

2009年Flickr做影象管理的公司，每天部署十次，這個在以前其實是不可想象的。現在可能有來自網際網路公司的同事，大家覺得我一個應用單一的服務一天去部署十次，這個其實再正常不過了，很簡單。

但是在2009年的時候，那個年代我們阿里的同學曾經在不同場合分享過，2009年的時候阿里是怎麼做這個釋出的，他在很多個數據中心裡通過手動的方式登入到不同的資料中心裡人工去進行釋出，釋出的過程中出現錯誤的時候需要人工的去進行回滾。

2011年我們上線了12306，12306在上線最初的時候，它的更新是有時間視窗的，做一次更新需要4個小時的時間視窗，那個時候開發和運維人員幾乎需要通宵去加班。

我們從DevOps發展背景來看一下，為什麼說現在很多的企業都想去做DevOps，其實這個有兩個方面的原因。

一個方面，IT部門在我們企業內部的重要程度越來越重要，在以前，IT部門一般來說是一個企業的支撐部門，重要程度很一般，一般是運維在自己的資料中心裡管理幾個伺服器，做一些運維的工作。

隨著一些技術的發展，比如說企業發現通過大資料可以影響到自己企業的業務，使自己的業務增長。我們會發現IT部門在企業內部的地位越來越高了，參與業務的程度也越來越高了。再往後發展，我們通過容器，現在很多企業想去做數字化的轉型，甚至很多企業現在他的IT系統就是他主要的業務，他的業務就是他的IT系統。

比如現在網際網路金融、打車軟體、今日頭條這種內容提供商，他的核心業務就是他的IT系統。IT系統的重要程度越來越高，也就直接導致了IT系統裡它所遵循的這些流程，DevOps程度越高，它的核心競爭力就越高。

我們從參與人員的角度看一下DevOps，以前來講，我們大家都認為DevOps就是開發和運維人員，其實整個DevOps目標是使我們的業務更加靈活、更加敏捷的適應市場和業務的變化。

所以廣義上來講，我們希望整個企業內部所有的和業務相關的人員都能參與到DevOps中間來。但是傳統企業由於組織架構的問題，它會導致DevOps很難推廣，因為每個部門考核的目標以及他所關注的點是不一樣的。

我作為售前，我經常去客戶不同的部門去交流，我有個很明顯的感觸，每個部門關注的點是不一樣的。比如你在和運維人員溝通的時候，你告訴他說我這個開發語言多麼先進，可以減少50%的程式碼量，運維人員一般的反應就是“哦”，如果你去開發部門告訴他們說我這個工具可以實時監控網路、儲存狀態，可以在你的系統發生故障的時候給你自動恢復，開發人員一般的反應是“呵呵，在我的環境裡不會出現故障的”。

可以看到這就我們開發人員和運維人員他們之間由於他的背景知識，他所關注的點不一樣，造成這樣一個問題。

DevOps你就去改變企業的組織架構，讓大家形成一個融合的團隊。如果改變組織架構有難度，你就要去做一個標準化的交付物或者交付流程的銜接，讓不同部門之間溝通和交流的壁壘更加清晰。很有可能DevOps這個運動會幫助我們創造出來新的崗位。我們知道關係型資料庫在廣泛應用之前，其實沒有DBA這個角色。

現在谷歌和Facebook裡最活躍的崗位就是SRE，這個崗位在以前也是沒有的，但是由於DevOps的運動，造就了一些新的崗位，這一點也是值得關注的。

我們可以從三個角度來看，一般對DevOps，對於企業組織的要求。第一是人員，前面幾個嘉賓都提到需要有一個企業文化的重建，甚至組織架構的重建，使大家的目標和KPI是一致的。流程，通過敏捷，我們可以通過迭代儘早的發現問題，儘早的解決問題，這個其實在大部分的企業內部現在已經這麼做了。

通過DevOps流水線可以管理不同階段、不同交付物的規格和質量。第三點是技術和工具，包括我們使用的CICD流水線、不可變基礎設施等等這種技術來實現。

下面介紹一下實際我們的客戶在使用容器，在DevOps實踐中遇到的一些問題和他們是怎麼解決的。

所有的新技術它初始推廣的時候其實都會遇到阻力的，大家知道在汽車誕生之初，開得也比較慢，聲音又大，又老冒煙。最早汽車推廣是很困難的，很多地方允許馬車走，不允許汽車走，那時候馬車的擁有者就會認為說我這個馬車很舒服，出了問題壞了以後，隨處都可以找到配件修理它。

同樣的問題在容器裡也是一樣的，很多企業客戶提出的問題，我現在的系統壞了，我知道我有工具而且我有能力修好它，但是到了容器這個環境裡以後，如果出現了問題我該怎麼辦，我沒有這方面的技能。我們下來會從幾個方面看一下容器在DevOps裡遇到問題該怎麼解決。

這塊是一個簡單的IT架構的發展趨勢，可以看到這幾個關鍵的技術點，微服務，DevOps，雲端計算，我們的應用架構從單體發展到多層，發展到微服務，我們的開發流程從敏捷發展到DevOps，我們應用的執行環境也發生了變化。

有一點，DevOps的概念和微服務的概念提出的時間已經很長了，都是2008、2009年的概念，為什麼在近一兩年才開始在不同的企業裡使用起來。其實有一個可能性，容器這個技術其實是一個催化劑，它幫助我們把微服務，幫助我們把DevOps更好的在企業落地。

微服務我們一般建議使用者以最合理的技術選型去實現微服務，比如我這個服務適合用Java開發，還有一個服務需要PHP開發，微服務建議用最短的時間最靈活的方式去實現你的業務邏輯。

問題來了，開發人員是靈活了，運維人員就頭大了，最早我的運維人員可能只掌握一個Java的運維知識就夠了，現在你三天兩頭扔一個新的開發語言，運維人員的工作越來越難做了。

所以說需要有一種標準化的交付物給這個運維人員，他可以不去關注我的容器裡執行的什麼語言，甚至什麼業務都可以不用關注，是以容器為最小的排程單元去運維的。

有了容器以後，微服務的可行性就變大了。同樣的道理，在DevOps上也一樣，以前我們一個一個應用，在做DevOps的時候，他可能需要自己開發不同的指令碼，去適應你的Java應用或者是其他的應用。通過容器以後，我的工具鏈就變成單一的了。

環境那塊不用講了，我們以前一個應用遷移動不動需要兩三天時間，用了容器以後，在公有云、私有云裡來回遷移的時候可能就是一個模板檔案或者幾條命令就可以做到了。

在DevOps相關的領域，包括像釋出管理、配置管理、執行時管理、環境製備和監控等一系列的方向，下面從幾個方向看一下容器技術在裡面怎麼使用的。

首先發布管理，容器在DevOps的釋出管理裡最大的作用就是標準化的交付件，不可變基礎設施，每當釋出以後我這個裡面的內部就不會變了，它是一個標準的格式，我在任何的底層的異構的環境裡都可以執行。

簡化運維。現在很多地方使用容器的運維人員，他其實已經不需要掌握我們傳統的比如java運維等等這種能力了，我的平臺容器發生故障的時候，我可能只是做一個健康檢查，如果不健康殺掉就行了，沒有其他動作。

通過Dockerfile它的配置和部署工作，被提前到了編譯時，以前我們做好應用在不同的環境釋出，再去手動調整環境變數，但是現在所有這些工作都被提到了編譯時，由於環境造成的問題的可能性降到最低。

最後一點是程式碼管理，我們以前可能只對程式碼管理，其實我們對配置、對基礎設施也可以以程式碼的形式去管理。

比如對基礎設施來講，我一個Dockerfile，我可以把它當成程式碼進行版本管理，不同的人對它進行修改，在不同的版本里。對於環境問題我們也是一樣，我在釋出的時候，我的應用執行的環境其實是可以被版本化的。

以前我們在一個應用出現故障的時候，你想把它回滾到一個月以前的版本，我們通過什麼方式來做，虛擬機器，虛擬機器有什麼問題，虛擬機器是把環境和應用繫結在一起的，你沒法把環境和應用分開，你要回滾到一個月前的版本，你的應用也會回滾到一個月前的版本。

而通過容器，不僅應用程式碼有環境控制，我的基礎設施Dockerfile也有版本控制，我的環境也有版本控制，這三者組合起來，可以選定程式碼的版本、環境的版本、基礎設施的版本，把它們三個隨時組裝成一個你想要的狀態。這是通過容器可以做到的。

第二個是配置管理，我們以前在做應用的時候可能是寫一些配置檔案，這些配置檔案最大的問題，你在執行時需要手動去修改檔案的。比如有時候你需要登入到你的生產歡迎裡做一些配置檔案的修改。使用容器，我們可以把配件檔案和程式碼完全分離開。有映象管理和流轉，通過映象倉庫。環境的版本控制剛才也介紹過了。

這一點對於我們的運維是非常重要的，大家可以下來看一些關於環境的版本控制這方面的最佳實踐。我可以在任何時間把我這個系統會回滾到以前的任何一個時間點上去。

執行時管理，指的是應用上線以後，DevOps還有很多工作要做。DevOps很重要一點是要形成反饋迴路，在你執行時有很多工作，比如你部署的時候，你要通過模板來部署，你的服務之間的關係，用DevOps一定要有一定的釋出能力。

比如說通過灰度釋出或藍綠髮布。我們現在很多企業其實已經實現了這種灰度或藍綠髮布的方式，但是據我所知絕大多數企業還是以手動的方式來做。舉個例子，紅帽有些客戶他在做灰度和藍綠的時候，他是在生產環境，人工的登入到Nginx的伺服器裡去手動的切換路由，這個裡面的風險點和不可控點就非常多了。

如果一個容器平臺本身把這些能力一直內建到平臺裡了，對於我們要去做DevOps就變得非常可控，而且非常簡單。這些指令碼，首先你不用寫這些指令碼了，這是平臺的能力。

第二，你也不用人工做這些操作，平臺會自動幫我們做，你只要告訴它我的灰度釋出的規則是什麼，通過配置就可以了。容錯，彈性，比如我的某一個服務由於請求量過大的是不需要人工再去寫指令碼，去監測資源利用率去做拓展，平會自動幫我做這些。這些都是我們平時在做DevOps運營過程中經常會遇到的能力，目前大部分的能力都是以和應用強相關的一些指令碼或者自己定義的工具來實現的。

但是如果有這麼一個平臺，它把我們所有不同型別的服務都抽象成了一個標準的處理方式，不管你是Java的應用，還是PHP的應用，你遇到問題的時候我都可以以一個標準化的處理方式來處理。

環境製備，這個很好理解了，通過一個容器的平臺，剛才我們上一位嘉賓講的，如果說一個環境沒有控制，可能會有很多人將來用很多虛擬機器、伺服器，導致資源濫用。

如果每一個開發人員或者測試人員上來就是一個租戶，你不管在裡面使用多少個容器多少個應用，你只要不超過這個上限，就可以隨意使用。而且資源製備隨著非常快，通過使用者登入以後就可以使用整個平臺裡面所有的資源。

監控，DevOps裡的最佳實踐裡監控非常重要的，如果讓我們手動管理DevOps應用，那會很麻煩，現在大部分的應用都是分散式的應用，你的這些日誌的收集、監控資料的收集，都需要你通過一些定製化的工具來實現。

如果說有這麼一個平臺，它可以幫助我們把日誌和監控資料都給我集中的收集起來，並且它幫我定義了一個通用的健康檢查的介面。以前這個健康檢查在企業內部使用的時候，每個應用會有自己相應健康檢查的實現方式，有的通過監聽某個介面，有的通過訪問某個URL。

如果有一個平臺給我提供標準的健康檢查的標準，我的開發人員在釋出應用的時候就把這個健康檢查掛載進去了，對於運維人員來講，他幾乎不需要來關心我容器執行的健康程度，你釋出以後，只要出現故障的時候，容器會自動被平臺殺掉，啟動新的容器來幫你提供服務。

還包括其他功能，像計費、報表、分散式追蹤，在傳統的單體應用裡面，你可能通過一個呼叫堆疊就能看到你的應用哪塊慢了，但是在分散式環境裡，你的某一個業務經歷了好幾個服務的呼叫，到底是哪塊出了問題，導致你的服務故障或者是比較慢。這個平臺如果能提供這種分散式追蹤的能力，就會幫助我們很好的實現DevOps的實踐。

從剛才這五個層面講到DevOps要關注這五個點，容器要在這五個點裡都有一些最佳最好的實踐。什麼東西可以幫我提供什麼健康檢查、日誌。

下面是廣告時間，我們在做DevOps的時候，如果說你想通過容器實現剛才DevOps那五個層面的功能，比如說標準化的健康檢查、彈性擴充套件、自動擴容、監控、日誌等等，使用紅帽的OPENSHIFT，包括了所有我們在日常DevOps落地的過程中所需要的這些工作。最後總結一下基於容器的DevOps的實施步驟，這個是我們在一些客戶裡總結出來的流程。

首先我們要去做一個基礎架構，也就是我們說的容器平臺，如果你要基於容器去做DevOps，首先你對容器管理平臺架構要構建好。

其次，可以用容器平臺去做一些自動化的釋出管理，比如說用Jenkins和你的容器平臺做一個對接，做我們軟體生命週期管理的後半部分，你的應用映象可能已經build好了，把這個應用映象釋出到平臺的容器平臺的工作可以來做。

第三個階段可以引入開發，從原始碼開始，通過CICD的Pipeline構建成應用心的映象，然後把映象釋出到容器平臺上去進行管理，再去利用剛才我們講的容器平臺裡的功能，去反饋回開發。

這是一些最佳實踐，首先要注重持續整合，從一個應用或者從一個小的團隊開始，有一些在做容器的DevOps的時候，一開始要一些非常大的應用來上線，其實這個是不太好的一個實踐。

比較好的方法，用一個小的團隊，一個小的應用，先把這個流程給試通了，確實可以在企業內部達到高效的效果以後，在其他的部門和其他的應用裡去進行推廣。確定衡量的指標，這塊其實挺有意思。

以前咱們國內的開發人員衡量我們自己的KPI，以後是程式碼行數，你解了幾個Bug。現在是以業務結果為導向，比如說你的應用執行過程中的故障率，你做一次上線花了多長時間，是以實際終端使用者來使用業務系統為目標。

這個也可以解釋為什麼很有可能在可見的一段時間我們的開發人員和運維人員會有一個融合的過程，融合成一個一個以業務為導向的單元去協同工作。

最後總結一下，通過容器來做DevOps可以改進我們的質量和速度，容器在DevOps裡面它的這些好處，剛才那五個方面都已經介紹了，不管是從釋出階段、執行時階段、監控階段，都是有一定優勢的。

但是使用容器會帶來一系列的挑戰，這個挑戰包括人員的培養，你的開發人員的技能和運維人員的技能，以前可能沒有容器的背景，他要去重新學習新的背景。

第二點，使用容器以後，很有可能你的業務單元就變成從一個單體式的應用變成一個分散式的應用，那麼你要引入一些分散式應用的複雜度，這個是需要你的平臺具備分散式應用運維的這些能力，你再去上容器。

最後是選擇合適的容器平臺，其實是可以幫助我們快速的實現DevOps。其實一個好的容器平臺，它應該具備剛才我們看到的所有的功能，這些功能現階段在各個企業裡面都有對應的工具或者是指令碼在做，但是最大的問題什麼，就是不夠標準化，一個應用會有一套這樣的指令碼和工具。

現在我們都在講微服務，你將來一個企業內部可能會有幾十個上百個微服務，你每一個服務都要做這麼一組的指令碼和工具，那麼它的可擴充套件性就會受到限制。

回到最初我們講到的，很多客戶在問，我到底有沒有必要上這個容器，我一般這麼告訴他們，假如說你企業內部的IT系統已經穩定了，在可預期的未來你也不會做任何的增長和業務的變化，其實你沒有必要上容器。
但是我們都知道，在這個時代，沒有哪個公司的業務可以長時間不變化、不新增，當你新增業務或者服務的時候，你又要有新的人去做重複的工作。

我們做IT的人最討厭的就是重複的工作，最有動力的就是把以前一些人工的事情給自動化，變成可複用的。一個好的容器平臺它就可以極大的節省你的這些精力，把一些以前要重複的勞動變成自動化的工作。

這就是我今天介紹的主要內容，謝謝大家！

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