架構師成長系列 | 雲原生時代的 DevOps 之道

做者 | 郝樹偉(花名：流生)  阿里雲高級研發工程師

本文整理自架構師成長系列 2 月17 日直播課程。

關注「阿里巴巴雲原生」公衆號，回覆 「217」，便可獲取對應直播回放連接及 PPT 下載連接。

導讀：DevOps 是一種軟件開發人員和 IT人員之間的合做過程，目標是高效地自動執行軟件交付和基礎架構更改流程。在雲原生時代，企業又如何藉助 DevOps 實現產品快速、穩定、高效和安全地迭代，釋放業務價值呢？

什麼是雲原生

爲了解決傳統應用升級緩慢、架構臃腫、不能快速迭代、故障不能快速定位、問題沒法快速解決等問題，雲原生這一律念橫空出世。

Pivotal 是雲原生應用的提出者，並推出了 Pivotal Cloud Foundry 雲原生應用平臺和 Spring 開源 Java 開發框架，成爲雲原生應用架構中先驅者和探路者。

早在 2015 年 Pivotal 公司的 Matt Stine 就寫了一本叫作遷移到雲原生應用架構的小冊子，其中探討了雲原生應用架構的幾個主要特徵：

• 符合 12 因素應用
• 面向微服務架構
• 自服務敏捷架構
• 基於 API 的協做
• 抗脆弱性

後來 Pivotal 對雲原生的定義作過幾回更新， 最新的 Pivotal 官網上對雲原生應用的最新介紹是關注如下四點：

• 集成 DevOps
• 持續交付
• 微服務
• 容器化

• DevOps 是軟件開發人員和 IT 運營之間的合做，目標是自動執行軟件交付和基礎架構更改流程。它創造了一種文化和環境，可在其中快速、頻繁且更可靠地構建、測試和發佈軟件；

• 持續交付使得單個應用更改在準備就緒後便可發佈，而沒必要等待與其它更改捆綁發佈或等待維護窗口期等事件。持續交付讓發佈行爲變得平淡可靠，所以企業能夠以更低的風險頻繁交付，並更快地得到最終用戶的反饋，直到部署成爲業務流程和企業競爭力必不可少的組成部分；

• 微服務是將應用做爲小型服務集合進行開發的架構方法，其中每一個服務均可實施業務功能，在本身的流程中運行並經過 HTTP API 進行通訊。每一個微服務均可以獨立於應用中的其餘服務進行部署、升級、擴展和從新啓動，一般做爲自動化系統的一部分運行，能夠在不影響最終客戶的狀況下頻繁更新正在使用中的應用；

• 與標準虛擬機相比，容器能同時提供效率和速度。單個操做系統實例使用操做系統 級的虛擬化，在一個或多個隔離容器之間進行動態劃分，每一個容器都具備惟一的可寫文件系統和資源配額。建立和破壞容器的開銷較低，再加上單個虛擬機中的高包裝密度，使容器成爲部署各個微服務的完美計算工具。

Google 主導成立了雲原生計算基金會（CNCF），對雲原生的定義爲：

「雲原生（Cloud Native）技技術幫助企業和機構在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的表明技術包括容器、 服務網格、微服務、不可變基礎設施和聲明式 API；這些技術可以構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術可使開發者輕鬆地對系統進行頻 繁並可預測的重大變動 。」

目前雲原生背後最大的推手就是 CNCF，關鍵技術包括容器、微服務、服務網格、devops，聲明式的 API 等等。

雲原生應用與傳統應用的對比，雲原生應用能夠充分利用雲的優點，靈活地在各個雲廠商分發應用，釋放企業生產力，聚焦到業務創新上，而不是花費更多的時間在適配和擴展不一樣的基礎設施平臺上。

雲原生時代的 DevOps 新挑戰

首先咱們要清楚地知道， 站在企業的角度來看，在這樣一個快捷商業的時代，企業最須要什麼？

• 惟快不破。這裏的快能夠解讀出來兩層含義，一是業務應用快速上線，有利於搶佔市場先機，第二層意思就是在你的業務有爆炸式增加的時候，你如何在計算資源上給以充分的保證，這個時候其實追加鉅額的 IT 投資購買軟硬件也未必能跟得上業務的快速發展。這個其實就是企業研發效能的問題；
• 穩中求變。業務或者應用的穩定性永遠都是第一位的，如何既保證業務的「穩態」又要知足快捷商業的「敏態」需求，好比新業務的上線、應用的變動等。這個是企業 IT 架構的問題；
• 節省資源，如何節省計算資源，根據業務是否高峯自動擴容縮容，這個是雲平臺建設的問題；
• 開拓創新，開發運維一體化、微服務架構。

DevOps 最初的出現打破了開發人員和運維人員之間從來存在的壁壘和溝鴻，增強了開發、運營和質量保證人員之間的溝通、協做與整合。在後 DevOps 時代，咱們能夠藉助容器技術更快地對應用進行迭代上線。

下面是應用發佈的通常過程，開發者 push 代碼，觸發構建，構建過程是拉取源碼，應用打包，容器鏡像推送，部署。

這個模型其實已經有不少地方充分利用了雲原生的優點，好比容器技術、Kubernetes、動態分配 slave pod 等。但還有一些挑戰。

• 如何應用在環境棧之間的安全推動發佈
• 如何管理應用發佈的權限和安全審批
• 如何提升應用的平均部署時間和平均恢復時間
• 如何迅速對線上應用進行故障定位、復現和回滾

雲原生時代下的 DevOps 之道

首先咱們要充分利用雲原生技術的優點，雲原生能夠改進應用開發的效率，改變企業的組織結構，甚至會在文化層面上直接影響一個公司的決策。在容器領域內，Kubernetes 已經成爲了容器編排和管理的社區標準。它經過把應用服務抽象成多種資源類型，好比 Deployment、Service 等，提供了一個雲原生應用通用的可移植模型。

在這樣的背景下，咱們如何在雲原生的環境下實踐更高效的 DevOps 來達到更有生產力的表現就成爲了一個新的課題和訴求。

下面是一個企業應用平臺的建設目標：

在此 PaaS 平臺的基礎上，咱們設計了 GitOps 安全發佈模型來解決前面咱們提到的一些挑戰。

在設計 GitOps 發佈模型的時候是有如下這些核心訴求的：

• 版本管理。咱們但願每個發佈的應用的版本號都能跟 git commit id 關聯，這樣的好處就是每個變動都有歷史記錄查詢、能夠更快進行故障定位和修復；
• 基線管理。便於問題復現和快速回滾；
• 安全發佈。包括髮布權限管理以及安全審批的內容；
• 快速反饋。提升研發效能。

GitOps 發佈模型有如下特性：

• Git 倉庫是任何 CICD 過程的惟一輸入源
• 聲明式的應用編排、構建部署模型
• 應用在環境棧之間的無差異、自動化推動
• PR/MR 觸發的拉取式流水線過程
• 快速反饋機制

下面是使用 GitOps 管理應用發佈到不一樣 Kubernetes 集羣的架構圖。

首先是應用源碼與構建源碼分離，咱們能夠看到橙色框起來的這兩個源碼項目，一個是咱們的應用源碼項目 application-java-demo， 左側的這個源碼項目是用來存放構建源碼的，好比 preview pipeline 的 Jenkinsfile， staging pipeline 的 Jenkinsfile，production pipeline 的 Jenkinsfile， 除了 Jenkinsfile 以外，可能還有一些關於動態建立測試環境、鏈接預發環境或者生產環境的敏感信息，這些敏感信息也能夠存放在數據庫裏，而後這裏保存數據庫的鏈接信息。

這個普通應用 application-java-demo 在 Git 倉庫裏是有不一樣的分支的，每一個分支跟 Kubernetes 集羣環境都有必定的對應關係，好比咱們這裏的設定，master 分支對應的是生產環境，latest 分支對應的是預發環境，其餘開發分支對應的是測試環境，測試環境的動態建立和銷燬、應用再測試環境的部署發佈是開發測試人員自助的服務，但應用想要部署到預發環境和生產環境中的話是須要通過管理員安全審批的。

普通開發者的權限只有建立新代碼分支和建立合併請求的權限，除此以外，剩下其餘的部分都是管理員纔有權限作的，綠色區域是 Jenkins 的流水線任務，固然你也能夠是使用其餘 cicd 引擎來作這個流水線任務的構建。普通開發者沒有 Jenkins 環境的建立 Job 和構建 Job 的權限，也沒有更改配置的權限，他有的只是構建 Job 的日誌查看權限。

最後是一個時序圖，演示一個應用從開發測試到業務上線迭代的一個完整流程：

1. 開發者提交新的功能分支 feature；
2. 開發者建立請求合併代碼到 latest 分支的 Merge Request；
3. 開發者建立 Merge Request 的動做自動觸發名爲 preview-pipeline 的 Jenkins 流水線任務的構建；
4. preview-pipeline 流水線任務從 Git 服務器拉取 preview-pipeline 源碼項目，並按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Preview 的容器集羣、釘釘通知的流程；
5. 管理員在 Git 服務器的 Merge Request 頁面查看應用的預覽鏈接並驗證應用是否能夠合併到 latest 分支，若是經過驗證則接受 Merge Request 的合併，觸發步驟 6， 若是不經過則通知開發者進行代碼更新和提交，退回步驟 1；
6. 管理員接受 Merge Request 合併的動做會自動觸發 Jenkins 流水線任務 staging-pipeline 的構建；
7. staging-pipeline 流水線任務從 Git 服務器拉取 staging-pipeline 源碼項目，並按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Staging 的容器集羣、釘釘通知的流程；
8. Staging 環境中的應用服務在經過測試和驗證後，管理員能夠合併 latest 分支到 master 分支；
9. 管理員合併 latest 分支到 master 分支後，會自動觸發 Jenkins 流水線任務 production-pipeline 的構建；
10. production-pipeline 流水線任務從 Git 服務器拉取 production-pipeline 源碼項目，並按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Production 的容器集羣、釘釘通知的流程。

GitOps 是一套方法論，因此實際上是有多種實踐的方式的，會有多種多樣的好用的工具，好比使用 draft 能夠幫助完成應用編排模板的自動化生成，skaffold 用來簡化應用構建部署流程，kaniko 能夠實現不依賴 docker daemon 的鏡像構建和推送，helm 用做應用的包管理工具，還有其餘 cicd 引擎像 jenkins，tekton，argo 以及爲雲原生而生的 jenkinsx 等等。

後面，咱們會單獨實戰演示 GitOps 安全發佈模型的工做過程。

參考文獻：https://pivotal.io/cn/cloud-native

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」