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

嘉賓介紹：張春源

公司職務：希雲技術總監

大會演講速記

大家好，我來自希雲cSphere，今天給大家分享的主題:“容器是DevOps的必由之路”——“標準化帶來DevOps”。

談到DevOps話題特別大，我從容器的角度給大家分享一下，為什麼容器是DevOps的必有之路。

首先簡單介紹我自己，我比較遵守“恪守契約精神，務實開放合作”的精神，同時這也是希雲cSphere的公司文化。我從2013年開始接觸到Docker技術，並且有幸加入到希雲cSphere這家專門為企業客戶提供容器雲平臺的公司。在近3年時間，我一直在為企業提供容器雲解決方案。

今天我和大家分享一下什麼是創造力，提到這個詞大家會想到飄忽不定。人的大腦思維狀態大致有兩種：一種是專注狀態，這種狀態下的大腦模式被稱為“ExecutiveNetwork”，執行網路，,簡稱EN。另一種是放空狀態，相應開啟的是“DefaultNetwork”，預設網路，簡稱DN。

專注模式我們比較熟悉，我們在學校接受教育主要訓練的就是EN，它是大腦中靠近前側頭蓋骨的區域，能助你專注和完成任務。但是光靠EN是不能產生創造力的，還需要一個能幫助我們放空的網路DN，它是我們突破性想法的聚集地，但是很多時候我們並意識不到它的存在。

那麼一個偉大的創造中，EN和DN如何協同工作？根據神經研究表明，如果說EN幫助你專注和完成一件事，那DN則是幫助你從更高的角度縱觀事情的複雜程度，透視全域性。所有我們需要同時具備開啟兩種模式的能力，而且能在它們之間自由切換。

我之所以和大家分享什麼是創造力，主要是想說明現在隨著企業業務的迅速發展，IT系統也要能及時響應業務的需求。我們需要一種全新的思維、全新的方法來構建企業的IT系統。

DevOps主要用於開發、測試以及運維之間的協作管理，並且通過自動化流程，更加快捷、頻繁、易重複且可靠的構建軟體、測試及釋出部署。

在容器沒有出現之前也有DevOps，並且發展了這麼多年，企業常用的做法是通過自動化指令碼去實現配置引擎，例如：Puppet、Chef、Ansible等工具。基於以上工具來實踐DevOps，為什麼沒有使得DevOps發展起來，而且在企業中落地艱難。

其中第一個原因包括是指令碼缺陷。主要體現在：人員強依賴：比如這個指令碼是我寫的，另外一同事不一定能把這個指令碼用起來；不具備收斂：發現問題，首先要使問題收斂，目前使用的方法是不具備收斂的；非標準：不同人指令碼的寫法是不一樣的，但實現的結果都一樣；不具備回退：沒有做版本管理。

講到版本管理，我們的程式碼都有版本管理，但是我們的程式碼的執行環境，這個環境是沒有做過版本管理的，所以回退操作難度高；第二個原因是配置引擎的缺陷，像DSL語言，使用門檻太高。解耦也不夠，特定的人去特定的事，如果這個人因為生病了或者請假了，這個釋出就會終止。這些問題都導致了DevOps無法在企業落地。

給大家分享一個客戶實踐DevOps失敗後的案例這位客戶是個國企。對於國企來說，招人難度很高，很難招到技術特別高的人才，而且他們也想要通過DevOps這個技術實現增長，難度也就比較大。

另外開發和運營分裂，系統開發是第三方廠商，真正運營的時候是自己在運營。兩團隊不在同一個公司，要讓開發掌握這些工具，難度更大。而且開發根本不關心底層的機器是什麼，他們說盡可能不讓我們看到機器最好，這他們真正的訴求。

說白了，為什麼DevOps這麼難落地，就是在企業中很難形成從開發到測試再到生產的統一的一致性的流水線工作。

接下來給大家說說容器是什麼，在這裡我可以肯定地告訴大家，容器不是虛擬機器。大家可以從PPT上看到容器、虛擬機器、物理機的對比。

第二張圖，物理機之上執行虛擬機器，然後容器執行在虛擬機器之上，這種架構，我們看到它有兩個OS，一個OS是物理機的，一個是虛擬機器的，然後上面才是容器；第三張圖，不知道大家有沒有想過，容器就是一個程序，對於KVM虛擬機器其實在容器來看，它也只是一個程序而已，所以可以把一個虛機跑到一個容器裡。

重點說一下第三張圖，容器執行在虛擬機器下層，容器是直接跑到裸機裡的。說到這裡大家會問，容器到底跑虛機好還是跑裸機好，回答這個問題主要從2個方面來考慮，因為容器技術也有限制。

比如我們的業務系統，多個系統之間對安全性沒有特別強的需求，此時可以跑裸機裡面；如果隔離性是強需求，那麼推薦執行到虛擬機器中，使用虛擬機器來做徹底地隔離，容器是沒法實現多租戶的。

容器是增強版的程序，我們來看傳統的Linux，如我們去裝系統或者裝軟體，都通過RPM包，容器是使用映象來安裝，yum-yinstall後會安裝很多包，包與包之間的依賴關係複雜，很難一眼看出是誰依賴誰。

對於傳統的Linux是一個普通的程序，所有的程式、所有的程序是在同一個平面上，通過容器相當於給每個程序都做了一個”箱子”，雖然“容器”都是執行在作業系統中，但彼此之間相互做了隔離。

容器映象的一個機制-COW，大家比較熟，我就不多說了。

大家比較關注的是容器的效能，這個測試報表是基於IBM伺服器機器做的，可以看到物理機和容器效能之間是基本一致，無損耗，但虛擬機器損耗大約在50%，損耗比較大。

為什麼說容器技術恰恰能克服這些阻力呢。第一，開發使用簡單，因為在開發的時候不需要關注這個機器還有執行環境是什麼，而能更加清晰的規劃開發和運維的介面。

第二、抽象層次足夠高，解耦徹底，而且容器是行業通用的標準，DevOps發展那麼多年，為什麼說它沒有流行起來，比如說剛才提到實現DevOpsd平臺多種技術多種工具，這些工具的標準搬到其他的公司它未必適用，不同公司的文化也不一樣。容器標準的生命力特別強，容器可以讓DevOps普及發展以及流行，並且走出陰霾，證明DevOps的先進性，也確實是可以落地的。

那麼容器在開發領域是怎麼樣的流程呢。

如果是銀行的朋友就會知道服務目錄，我們稱作應用商店，開發可以從應用商店中選擇所需的環境。通過編排做交付，容器編排功能決定是不是可以把非常複雜的系統編排起來，實現整體交付。

前不久我們給客戶做POC的時候，客戶給了一個微服務，27個服務整個編排僅用了2個小時左右，而且無需對映象做修改，就實現了一鍵部署。環境部署完後，開發就可以專心寫程式碼了，程式碼提交到程式碼倉庫，觸發Jenkins構建，構建完成後自動部署應用。

對於測試來說也特別簡單，可以基於版本庫進行一鍵部署，應用模板加映象包括了程式碼、執行環境、和配置資訊，測試環境同樣是整體交付。

大家從PPT上可以看到基於容器建設的整個DevOps的流程，包括從提交程式碼到Jenkins構建映象，再到應用部署。有容器可以不安裝JenkinsSalve節點，只要這臺機器裝了Docker就可以作為構建機器。實踐推薦可以專門找兩臺主機做構建，構建完後上傳到映象倉庫，構建任務多的話，多配置幾臺伺服器就行。

多環境之間交付，如：測試環境、生產環境、UAT環境，每個環境之間會有不同，不同是指配置引數的值不同，而底層環境和程式碼版本要一致，保證多環境之間的一致性，這也是容器的價值。

為什麼說其他技術路線為什麼會必然失敗。剛才我提到了，之前的標準都是小標準，個別企業的標準不一定代表著行業的標準。

PPT中的這張圖是一個快遞的箱子，收快遞的人很難判斷我是騎個車還是開個貨車去呢？很難統一做考量。另外，小標準的生命力非常弱，難推廣。現在通過容器，就像集裝箱，我們可以知道原先的碼頭有好多人力在去背麻袋，在裝貨、卸貨，但是發現這種效率是極低的，而且出問題也比較多。集裝箱出現後整個運輸行業做到了標準化、自動化。

DevOps有一個很強的需求，更小、更頻繁的變更。

沒有容器的話，應用變更很難，如：

1.構建環境不確定，比如我這一次的構建也許會用了上一次構建失敗的庫，所以導致這一次構建也失敗。

2.DSL語言編寫起來特別麻煩，在2015年的時候遇到一個銀行的客戶，問我Puppet如果升級的話有沒有什麼風險，市面上是否有Puppet的大牛能做技術顧問。

3.釋出結果不一致，在不同的時間點，因為網路的因素或者其他因素，要麼是全部失敗，要麼是全部成功。4.回滾週期長。

有容器的話，
1.構建環境首先是確定的，因為容器是一個集裝箱，把所有東西都包起來了。

2.視覺化操作，門檻特別低。

3.釋出結果一致，就好比把上海的集裝箱拉到北京，只要箱子在，裡面的東西就自然會在。

4.週期短、秒級回滾。

DevOps的又一個需求，讓開發人員儘可能的去控制生產環境，當然這個控制是有限度的控制，包括視覺化的操作，要有操作審計功能等，任何一個人做了什麼操作，實現的結果，都會有記錄，最後是視覺化的查詢。

沒有容器怎麼來控制，控制力度難控制，命令列操作，依賴外部系統，系管理系統分散，有些其他的運維平臺是隻監不控，對企業來說，其實維護這麼多系統也非常麻煩，同樣希望能一套系統又可以監控又可以管理。

使用容器的優點，細力度的授權，可以開放給開發，全都是視覺化的操作，簡化了開發使用的門檻。精密審計，記錄了增刪改等操作。高度整合，一套平臺可以做到監控和管控。

以應用程式為中心，來理解基礎設施。程式碼會依賴配置檔案、依賴作業系統、依賴其他的外部系統等。

依賴程式非常難管，開發人員手動修改，但是沒有及時記錄到文件或者是其他系統中；配置管理與程式碼是分離的，尤其是配置檔案；依賴的修改會比較複雜，速度比較慢即使是虛擬機器或puppet。基礎設施管理複雜度比較高，經常的變更會導致系統已經不一樣了，還要同時管理不同版本的作業系統。

容器作為應用的基礎設施，首先有一個概念“映象”，映象包含了應用程式碼以及依賴的執行環境，可通過Dockerfile檔案進行描述，同程式碼一起管理。

變更更快速，pull映象start容器，主機上只要執行一個容器引擎就可以了，基本上不用做變更，而且對作業系統是弱依依賴的。

定義簡單明瞭的流程。以前的方案流程複雜，不同型別應用的程式、專案組的專案，都會有不同的部署、升級回滾流程，這個複雜度是比較高的。

開發人員對程式碼、架構的調整，都會導致運維人員做出很多相應配置變更的工作。這是一個博弈的過程，開發要求變化，運維追求的是穩定。

接下來分享一個基於容器實踐DevOps的案例。

總目標有2個，第一個如何用容器克服第三方開發商和企業IT管理之間的協作，系統開發涉及到開發廠商，包括北京的研發和廣州的研發，不改變已有開發習慣，程式碼寫完後提交到GitLab就可以。

Jenkins構建出來的映象都push到中央映象倉庫，基於cSphere平臺的應用編排，將壽險業務編排起來，實現業務的部署、升級及版本回退。

基於容器建設整個DevOps流水線，我們已經在不同行業，不同客戶的IT環境中實踐過了，這幾年以來，為什麼能在企業中基於容器實踐DevOps能成功，很重要的一點就是容器是行業標準，並且結合希雲cSphere容器平臺降低了使用門檻，和推廣難度。

最後我們看一下客戶效果收益，標準化第三方開發商交付物，所有的人員都必須通過映象來作為交付物，對於中英運營人員標準統一進行部署和管理。2個月完成2個應用的開發、測試、上線。伺服器資源提升70%、交付時間縮短60%以上，整體工作效率提升80%，包括第三方開發廠商還有甲方。

我今天分享的主題是容器是DevOps的必由之路，根據近幾年專案實踐，我相信，未來容器是DevOps的必由之路。

今天時間有限，就不與大家一一交流了，如有其它問題可以隨時與我聯絡，謝謝大家。

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