在線公開課 | 雲原生下的DevOps與持續交付

課程概要
2009年，一場演講在O’Reilly Velocity大會上一炮而紅，演講中有一句話深得人心：「因爲開發和運維須要在Flickr（一個圖片存儲和視頻託管網站）上合做，這致使開發者天天至少得進行十次部署。」演講結束後，「DevOps之父」Patrick Debois受該演講啓發，在比利時發起一場名爲DevOps之日的運動，號召開發和運維們，應該破除對立、走向合做。

DevOps是一個合成詞，由開發（Developments）和運維（Operations）兩個單詞組成，其主要目的是拆斷不一樣部門之間隔離的牆。 簡而言之，DevOps可讓公司的流程更快、更有效，而且更可靠。那麼，持續交付和DevOps到底有什麼關係？爲何要放到一塊兒說？

4月1日，京東雲與AI雲產品研發部架構師井亮亮，講授了《六週玩轉雲原生》第三講：雲原生下的DevOps與持續交付，讓咱們來回顧一下精華內容吧！

關於雲原生的解釋有不少種，這張PPT裏列了常見的兩種說法，大致意思是雲原生是持續交付+DevOps+微服務+容器化。

六週玩轉雲原生

雲原生下的DevOps與持續交付

— 京東智聯雲 井亮亮—

概念與簡介

關於雲原生的解釋有不少種，這張PPT裏列了常見的兩種說法，大致意思是雲原生是持續交付+DevOps+微服務+容器化。

也就是說，雲原生是一個概念集合，既包含微服務、容器，也包含更多的管理方法，好比持續交付、DevOps和重組等。

那麼如何定義雲原生？下面這張圖是CNCF官網對於雲原生的定義，也是相對來講比較靠譜的定義。而想了解雲原生，就得先了解K8S，由於它是雲原生的基石。

- K8S

K8S是CNCF的第一個項目，雲原生整個生態都是依靠K8S構建出來的。雲原生的表明技術包括容器、微服務、服務網格、不可變基礎設施和聲明式API等。

- DevOps

每當你們提起DevOps，總把它比做盲人摸象，不少公司的叫法也不同。有的企業會把內部上線平臺說成這是本身構建的DevOps。

但咱們先看維基百科的定義：即透過自動化「軟件交付」和「構建變動」的流程，來使得構建、測試、發佈軟件可以更加快捷、頻繁和可靠。

-持續集成、持續交付和持續部署

持續交付可讓軟件交付變得更快更頻繁，即隨時均可以發佈，它的目標是讓軟件的構建、測試與發佈變得更快、更頻繁。要確保效率，就只能交付得更快，但交付更快的前提是確保質量。提及持續交付，不少人還聽過持續集成、持續部署。以下圖所示，這三者之間存在着必定差異。

在傳統軟件開發中，開發者在項目結束後都須要作集成，這一過程少則幾星期、多則幾個月。軟件開發在中早期時，須要頻繁地進行集成，頻繁集成的好處就是，避免到最後環節才發現問題。

不少人可能會說，咱們團隊早就集成了，那麼大家多久構建一次？是否是每次發佈時才走構建流程？若是是這樣就要考慮一下持續集成。由於持續集成是持續交付的第一步。

而持續交付就是把前面全部東西集成在一塊去交付給客戶。固然不一樣公司對於這個階段的叫法也有所不一樣，有些叫「測試-生產」，有些叫「測試-準生產」或者「上線」等等。

持續部署的意思是，全部環節都是自動化的，開發者提交完代碼以後，能夠自動化部署到生產環境裏。持續部署跟持續交付惟一的區別就是，開發者可否把產品自動化地發佈到生產環境裏。

近年來，技術名詞更新很是快。關於此，在基礎設施方面體現得最爲明顯，幾年前發佈一個應用去部署時通常有以下幾種選擇：最好最根本的辦法就是建機房，但全部的硬件、網絡、水電等問題都得考慮進去；其次是搞服務器、裝操做系統，最後再部署或者虛擬化一下。

再後來，咱們會作相似VMware的虛擬機，即在上面虛擬化一下部署方式，直接寫一些腳本執行一下就能跑起來。再日後，你們都開始搞相似OpenStack一類的私有云技術。

不管方法如何變化，也不管你用什麼基礎設施，最後都會演變成混合雲或者多雲的方式，你的交付不只要支持這些模式、更要支持容器包。當前這個過程也變得愈來愈自動化，且愈來愈能知足業務訴求。好比，咱們會用彈性伸縮技術，來知足業務需求和成本訴求。

持續交付-流水線？

持續交付須要一系列的過程，在這一系列的環境中，不管是測試、預發、生產，越日後就越接近客戶的環境。儘管每一個階段關注的問題都不同，但你會發現，每個過程和環境都須要作發佈作驗證。

而經過流水線的方式，就能很好地把這一系列過程自動化起來，開發者構建的效率和發佈的質量也會藉此提升。

- 軟件交付的挑戰和問題

上圖是2016年一個DevOps的調查報告截圖。你們都知道，軟件交付的過程自己，意味着線上變動，變動就意味着有風險。交付最大的挑戰是上線過程當中遇到失敗，失敗的話確定會引起線上故障。

2016年的調查報告顯示，81%的團隊能將失敗比例控制在15%之內，可是能把失敗比例控制在5%的團隊只有35%。這意味着發佈100次就有50次故障。因此，變動對於軟件交付的質量至關重要。

既然質量這麼重要，那該如何選擇交付工具？下面這張圖，供你們參考。

- 流水線

世界上的第一條流水線，由福特汽車提出並上線。在當時，流水線極大地提升了汽車生產效率。而開發者在提交完代碼後，把軟件交付到客戶手裏，一樣也會經歷一系列的過程。那麼這個過程怎麼去建模和運行？

這時就得結合流水線的目標來推動，流水線的目標是快速集成、快速交付，能夠說流水線其實就是個管道，它並無一個標準的流程，咱們徹底能夠根據業務去定製。

好比說，當你要構建一個流水線，你可能須要代碼掃描、代碼測試、測試部署再預發等等一系列過程。可是你怎麼確保本身作的流水線能夠很好地運行？

這個問題並不難，作到如下三點就能夠：

第一，必定要作自動化構建。不少開發者以爲已經作了自動化了、已經持續集成了。可是若是你在構建上不夠自動化、也不夠及時，那就談不上測試或者集成。

第二，必定要作自動化測試。構建完以後產生的產物確定要測試，不管是功能測試、性能測試、仍是壓力測試。這個測試過程是爲了達到預期質量，但也要根據狀況去作自動化，由於只有自動化才能提升效率。

第三，持續集成。流水線只有重複、快速、頻繁地運行，才能發現問題、解決問題。

在整個軟件行業，起碼作到以上三點，才能達到持續交付的目標。世界上的第一條流水線，由福特汽車提出並上線。在當時，流水線極大地提升了汽車生產效率。而開發者在提交完代碼後，把軟件交付到客戶手裏，一樣也會經歷一系列的過程。那麼這個過程怎麼去建模和運行？

- 最基本的部署流水線

上圖雖然是最基本的流水線，可是你們能夠看到，它涵蓋整個環節，包括源代碼環節、提交環節構建、測試和代碼分析等等，到了後面就是驗收、UAT測試生產環境、製品發佈到生產環境。

- 一些流水線實踐

上圖是一些流水線的實踐，具體能夠分爲三方面：

- 二進制包只構建一次

二進制包只構建一次的意思是，開發者在每次寫完代碼後再構建一次，從而生成一個二進制包，而後再去進行後面的流程。這樣不只能夠避免浪費時間、還能提高效率。

但即使是這樣，仍然出現兩次構建的結果不一樣的狀況，這是由於雖然你的代碼和ID沒變，可是你的包可能會產生變化。

- 要採用同一部署方式在不一樣環境裏

在發佈部署時，全部部署的方式和環境，例如測試、預發和生產都採用同一種方式部署，而不是部署到測試環境時用Jenkins作持續集成，生產環境要發佈時卻經過另一套工具去部署。部署工具不同就有可能致使最終交付的產物不同。

在線上生產環境時，無論用物理機、雲主機仍是虛擬化物理機，都要確保它的高可用性能。這時就須要堆一堆資源，來保障線上用戶的可用性。

- 流水線管道要靈活

流水線存在的意義，是爲了提高效率和確保質量，可是開發者的業務可能有Java的、可能有Go的。所以你的流水線，要知足各類各樣的訴求。

好比說，有些團隊一套測試環境就夠了，另一個項目可能以爲該項目要提供給別的團隊作聯調，這時就要確保測試環境的穩定性，好比構建兩套測試環境，A環境能夠團隊本身拿來作工程驗證，B環境則能夠提供給第三方去聯調。

最後須要作的，是驗證整個流水線的落地，不能說你把整個流水線構建起來了，而後就按照這種方式去走。真正落地時，要考慮到每次代碼提交完成後 ，是否完成了自動化觸發測試的流程。

京東智聯雲在持續交付的實踐

每一個企業作持續交付的經驗，都是一步一步趟出來的。

京東最先的固定上線日是週二和週四，爲了確保穩定性，研發人員不能去操做線上環境，那麼就得運維上線去操做。這時產品經理們就會在運維後面排隊，可是排隊的效率比較低，而且那時尚未上線工具，自動化能力也特別差，線上故障的修復也沒法獲得保障。直到後來，纔開始想辦法填平。

- 兩條交付的流程

在京東早期的兩條交付流程中，第一條交付流程從開發、編譯構建、代碼分析、抽包到整個上線都有涵蓋到。

在工具上，私服用的是商業版Artifactory、構建用的是Jenkins、代碼掃描用的是SonarQube、對象存儲用的是內部一個私有云，發佈用的是rsync。

在第二條交付流程中，最大的變化是咱們把rsync替換成ANSIBLE了，這的確極大提高了效率，而且解決了排隊問題。

因此在發佈過程當中，咱們原來是抽包模式，後來所有改爲全量包的方式。另一塊是提測，原來咱們只作功能測試，後來安全測試也作，原來只是對接靜態代碼掃描，後來也作安全漏洞的篩查。這兩條流水線有一個共性問題，即每條流水線都會有一條測試包、一條生產包。

目前京東智聯雲的實踐，基本分爲三套環境，一套測試、一套預發、一套生產，測試、預發、生產與網絡之間又是相互隔離的。

如上圖所示，京東智聯雲的流水線會從源代碼、構建、代碼檢查、測試依次進行，預發環節和生產環節基本都有涵蓋到，假如核心功能自動化這塊失敗了，開發者得確保部署到測試環境後可以作到自動化驗證測試環境的功能，最起碼確保測試環境的核心功能沒有問題。

從設計角度來講，整個流水線自己就是一個管道，管道里面每個原子的功能都是獨立的，像安全代碼檢測確定是安全團隊更專業，京東智聯雲在這一塊就是安全團隊去作的，他們提供安全機制，確保原子能力建設，咱們經過流水線把它接過來。

- 持續交付最核心的就是規範

能夠說，持續交付就是一個編排，你們都知道Jenkins特別流行，那爲何京東智聯雲的持續交付不能直接用Jenkins呢？由於持續交付最核心的一塊就是規範。部署平臺比如在大草原上放羊，必定得有牧羊犬管理羊羣。

- 京東智聯雲如何作規範

京東智聯雲全部線上的操做都以同一套上線平臺控制系統去作，這樣的好處首先是減小風險，另外是統一控制系統可以作到秒級回滾。

其次，部署平臺要用統一的賬號去作發佈，出問題後好操做。而統一規範的實例部署路徑、日誌路徑，都是按照必定目錄去作，目錄若是出問題，很快可以經過日誌平臺或者京東智聯雲內部平臺「門神」去快速找到問題。

此外，京東智聯雲內部有整套DevOps平臺，該DevOps平臺涵蓋各個方向，目標就是解決軟件全生命週期的問題，包括開發、測試、運維，讓開發者經過工具更好地工做。整個工具層面包含項目協做部分、開發工具和測試部分。

在配置管理方面，京東智聯雲的配置管理不只涵蓋應用層面的一些服務管理，好比人員角色的權限等。當把這些東西做爲基礎數據的核心，那後面的業務邏輯，包括監控、發佈、日誌等全部的服務基礎數據都已經有了。

京東智聯雲是按照App的維度，向上是整個組織結構，向下會把整個模塊和機器的信息管理起來，這時就不須要考慮發佈機器的狀況，只須要考慮發佈哪一個App，以什麼流量切換的方式去發佈它。持續交付真正的核心是靠流水線把整個環節去打通，京東智聯雲的監控是一個比較全鏈路的監控，不只僅包括技術層面的監控、底層基礎設施、容器、物理機，還支持混合雲。

如今的企業通常不可能只用一種雲或者只用本身構建的私有云，公有云也可能不會只用一家的，可能有A家的、有B家的，這種模式的話，無論是交付仍是監控，都要作到支持基礎設施混合雲的模式。這樣的話，就得在上層作到統一調度，全部監控部署的Agent也要作統一管控。此外，以下圖所示，在這方面京東智聯雲也會對外輸出本身的經驗。

- 如何落地方案

在企業裏面實施DevOps，很大一部分狀況是企業已經用了一些東西，而後想用Jenkins提升一些能力。這時就要考慮爲何要作改變，而且說服你的老闆或同事去作內部DevOps工具鏈條的改變。

這裏有兩種改變的方式，一種是國家信通院跟DevOps社區出具了一個DevOps標準，這個標準是上百個專家力量一塊兒寫的，你們能夠參考一下。

雲原生下持續交付

京東智聯雲上的工具鏈條比較多，目前咱們正在作公測的過程當中，將來會把內部項目管理的實踐，以原生的方式開放給你們。

Ops部分則包含日誌服務、監控、雲撥測、雲事件、運維的堡壘機能力，這一塊也是咱們內部自研的一款叫作「門神」的產品，這款產品已經支撐京東內部好幾年了，0故障。當下，京東智聯雲以雲原生的方式，進行的開發，預計會在下一步開源出去。

另外，京東智聯雲也支持Terraform和Packer能力，能夠幫助開發者快速構建基礎設施。整個京東智聯雲是以原生的方式，把工具以各類原生作法提供各類API，其目的就是但願幫助你們在原生雲下構建屬於本身的能力。

TIPS：在這樣一頓操做以後，不少參加課程的小夥伴都紛紛表示咱們這個系列的課程「幫助小白走近雲原生的大門」，並對下次課程充滿期待！

這裏提醒你們一下，《六週玩轉雲原生》的第四期課程走近監控與日誌，雲原生基石探祕即將和你相見！

小夥伴們千萬不要錯過！掃碼關注社區，追蹤更多課程信息吧

雲原生的時代已來，而你，也將成爲這個新時代的構建者之一！

歡迎點擊「更多」觀看視頻回顧。