更多深度文章，請關注雲計算頻道：https://yq.aliyun.com/cloud
在雲棲大會開源專場，來自阿里雲的高級開發工程師莫源為現場聽眾帶來了題為《Dev Oops ? No , DevOps！》的分享。在分享中，莫源從持續交付之禪、持續交付系統JenKins以及Derrick助力開發者輕鬆容器化三個方面由淺入深地講述了DevOps是如何通過選擇合適的工具降低等待和技術成本，提高企業自動化。
以下內容根據現場分享和幻燈片整理而成。
DevOps的趨勢
DevOps越發被開發者所提及，尤其在與Docker相關的領域，DevOps被認為是開發者快速部署的最佳實踐。從2016年統計結果來看，74%的開發者已經開始使用DevOps，而這一數據在15年只有66%；企業界已有81%的企業已採用DevOps，而這一數據在15年只有70%。然而，統計數據表明62%的開發者在使用DevOps時需要他人指導；44%的開發者仍處於調研和測試DevOps的初級階段。由此可見，DecOps是一種勢不可擋的趨勢，但同時也是“屍橫遍野”的戰場。
大家口中的DevOps
為了更好地瞭解DevOps，下面分別來看一下兩個常見的最簡化持續交付流程——傳統應用的持續交付流程和容器化應用持續交付流程。
傳統應用的持續交付流程是從代碼開發提交代碼到代碼倉庫；代碼倉庫觸發構建後，由持續集成系統測試、預發並正式環境部署。
容器化應用持續交付流程如上圖所示，相比於傳統應用的持續交付流程，容器化應用在持續集成系統中新增了鏡像構建與推送，之後再通過分發編排模板完成部署。
很多開發者從各類演講或者社區中拿到上述類似的方案後就回到公司開始進行DevOps實踐。然而，在企業實現過程中，DevOps的實施變得越加複雜，有的企業在實施DevOps時引入了新的架構、新的部署環境（PaaS、Docker、Serverless）；有的企業引入了新的工具鏈、新的流程以及新的“職位”。這新引入的一切給企業帶來了更多生產運營的成本。但這並不是DevOps想要的結果！
DevOps不是讓你成為全能忍者（既懂開發又懂運維，還能兼顧測試），而是消除“等待”與“浪費”。在傳統的服務流開發模式中，從前期的需求分析、設計、實現、驗證到後期的運維部署，每一個流程都是由不同的角色負責，例如產品經理負責需求分析和設計、開發工程師負責實現、驗證是由測試工程師負責，而後期的維護是運維工程師的職責。因此，也就產生了“等待”與“浪費”，“等待”與“浪費”出現在項目流轉過程中，不同角色交替職責時，比如說等待基礎架構的設計、等待應用程序部署、等待其他團隊的反饋，甚至有時需要等待漫長的審核流程。
那麼DevOps是怎樣消除這些“等待”造成的“浪費”呢？首先一點是消除不必要的流程；第二消除不必要的特性；第三消除不必要的人工；第四消除不必要的返工。
DevOps之禪
那麼DevOps到底是怎麼解決上述提到的等待和浪費呢？答案就是分而治之，將大的目標分成不同的、小的目標，每一個子類目標可以進行快速的設計、開發、測試和交付。利用分而治之分方式讓每一個步驟可驗證、可交付。先分而治之，讓一個大的開發週期變成小的開發週期再進行快速開發是DevOps之禪，一味地追求自動化部署反而違背了持續交付的初心。
DevOps熱門的領域
DevOps最近幾年的熱門領域主要是Cloud Native、Microservices、Docker和Serverless，這四個領域經常和DevOps結合在一起。DevOps的本身並不是一個技術問題（而是業務問題），但是技術的變革需要DevOps來填平帶來的技術成本。DevOps實現是一個適配器，封裝了本地開發與遠程交付之間的實現。
近年來，DevOps的工具鏈變得越發繁多和複雜。因此，選擇適合企業業務的工具鏈尤為重要。傳統應用和容器化應用交付的過程中，其核心都是持續集成服務器。換句話說，持續集成服務器是DevOps最重要的一環，是交付流程的發動機。在開源領域，持續集成服務器最為有名的是Jenkins，也是最適合的持續集成產品。
Jenkins
Jenkins可以在非常多的場景中和其他的持續交付工具進行集成。
上圖展現了Jenkins的幾大特性，首先Jenkins具有非常強大的插件支持，目前大概有1000左右的插件可用；第二，可以與100多個DevOps工具無縫集合使用；第三，它還可以和DevOps的工具鏈集成；最後，它還可以和DevOps的Pipeline集成，上圖也給出了不同階段下，Jenkins可以集成的工具。
Jenkins固然很好，但其也存在自身的問題。大家對Jenkins1.0有所詬病，主要是Jenkins1.0其老派的設計和功能。
而在今年新發布的Jenkins2.0版本中，我們可以看到如下5個方面的更新：
（1）UI 更新，新版的UI界面如上圖所示。
（2）Pipeline as code (Pausable,Durable)
（3）Servlet3.1 and WebSocket
（4）Docker Support in Pipeline
（5）Blue Ocean beta
為了讓開發者更好地使用Jenkins，阿里雲在在Jenkins相關的領域做了一系列的增強：
（1）目前，阿里雲提供一鍵部署Jenkins及Slaves的能力:
·提供Go、Java、Python、PHP、Node.js的slave鏡像；
·基於docker-compose一鍵部署master與slave集群；
·基於容器服務的運行時管理，可以動態生成任務構建容器。
（2）提供更多針對阿里雲環境的部署插件（容器服務）：
·阿里雲容器服務插件。
（3）提供Jenkins基於阿里雲場景的DevOps方案（ECS、容器服務）：
·惠及雲計算的能力，實現CloudOps、ContainerOpS；
·藍綠無宕機發布、彈性擴容應對尖峰流量等。
Jenkins容器服務解決方案
阿里雲結合雲服務的管理能力、Docker的標準化交付能力與Jenkins的強大的插件系統與任務分發引擎，為開發者提供雲原生的Jenkins ContainerOps解決方案。
DevOps改造例子
下面分享一個客戶利用DevOps改造Docker的真實案例。
該客戶原來的結構分為本地開發、測試環境測試、集成環境、預發部署測試、線上部署、運維與報警。其中前兩個過程是開發感知，中間兩個過程是測試感知，最後兩個過程是運維感知，而整體過程是由架構師感知。
當其進行DevOps改造之後，中間的步驟基本都採用自動化的方式，自動化整體設計是由架構師負責完善地。改造完成之後，DevOps節約了大量時間和成本，讓架構師更多的感知架構的改造；讓開發專注在本地的開發上；運維更專注於線上運維與部署。
基於Docker的DevOps的難點從來不是如何搭建持續集成服務器，也不是如何通過容器管理平臺進行運維。而是Docker帶來的學習成本（Dockerfile是第一大門檻）。從四個角色來講，運維工程師和架構師是不可能不感知Docker的，那麼我們是否可以讓開發者儘量少的感知Docker的存在？
答案是必須的——Derrick！
Derrick主要解決的就是讓開發者專注本地開發，降低Docker的學習成本；它通過獨特的機制自動生成Dockerfile，讓開發者無感知Docker的情況下在本地調試容器化的應用；此外，Derrick現已支持Node.js、Python、Java等多種語言，並將於近期開源，敬請期待。
相關推薦
