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

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

關注“阿里巴巴雲原生”公眾號，回覆 **“217”**，即可獲取對應直播回放連結及 PPT 下載連結。

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

## 什麼是雲原生

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

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/ee13b18973874b26b43744119ca0f5a8.png)

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

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

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

- 整合 DevOps
- 持續交付
- 微服務
- 容器化

![2.png](https://ucc.alicdn.com/pic/developer-ecology/43fd4a77182b4d4d9b532f0fb5866be3.png)

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

- 持續交付使得單個應用更改在準備就緒後即可釋出，而不必等待與其它更改捆綁釋出或等待維護視窗期等事件。持續交付讓釋出行為變得平淡可靠，因此企業可以以更低的風險頻繁交付，並更快地獲得終端使用者的反饋，直到部署成為業務流程和企業競爭力必不可少的組成部分；

- 微服務是將應用作為小型服務集合進行開發的架構方法，其中每個服務都可實施業務功能，在自己的流程中執行並透過 HTTP API 進行通訊。每個微服務都可以獨立於應用中的其他服務進行部署、升級、擴充套件和重新啟動，通常作為自動化系統的一部分執行，可以在不影響最終客戶的情況下頻繁更新正在使用中的應用；

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

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

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/613f5bb0c80e42f0a2622e40799ca23d.png)

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/18a0a1bbfe9140d5b5811480635f199f.png)

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

## 雲原生時代的 DevOps 新挑戰

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/3d865df9001f48cea60e074ba148c80d.png)

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

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

![6.png](https://ucc.alicdn.com/pic/developer-ecology/36613f5a373a4ab39f259fadd7544c09.png)

下面是應用釋出的一般過程，開發者 push 程式碼，觸發構建，構建過程是拉取原始碼，應用打包，容器映象推送，部署。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/4aed098c173243b89ab5f6d1123895a4.png)

這個模型其實已經有很多地方充分利用了雲原生的優勢，比如容器技術、Kubernetes、動態分配 slave pod 等。但還有一些挑戰。
![8.png](https://ucc.alicdn.com/pic/developer-ecology/ad505c9cdc7b447290dc89e1684ac2e4.png)

- 如何應用在環境棧之間的安全推進發布
- 如何管理應用釋出的許可權和安全審批
- 如何提高應用的平均部署時間和平均恢復時間
- 如何迅速對線上應用進行故障定位、復現和回滾

## 雲原生時代下的 DevOps 之道

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

在這樣的背景下，我們如何在雲原生的環境下實踐更高效的 DevOps 來達到更有生產力的表現就成為了一個新的課題和訴求。
![9.png](https://ucc.alicdn.com/pic/developer-ecology/1635562f4c1e49b88ff7b24a78922493.png)

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

![10.png](https://ucc.alicdn.com/pic/developer-ecology/972e7a71cd1f4ce1a34c0fe791820c88.png)

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

在設計 GitOps 釋出模型的時候是有以下這些核心訴求的：

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

![11.png](https://ucc.alicdn.com/pic/developer-ecology/39bd60fc9fc444b4888b36d723c6e620.png)

GitOps 釋出模型有以下特性：

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

下面是使用 GitOps 管理應用釋出到不同 Kubernetes 叢集的架構圖。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/25d1a82007d1456d91ae56ba7975995b.png)

首先是應用原始碼與構建原始碼分離，我們可以看到橙色框起來的這兩個原始碼專案，一個是我們的應用原始碼專案 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 的日誌檢視許可權。

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

![13.png](https://ucc.alicdn.com/pic/developer-ecology/f3a9c386884f49fabfb43a8ae8ade125.png)

1. 開發者提交新的功能分支 feature；
1. 開發者建立請求合併程式碼到 latest 分支的 Merge Request；
1. 開發者建立 Merge Request 的動作自動觸發名為 preview-pipeline 的 Jenkins 流水線任務的構建；
1. preview-pipeline 流水線任務從 Git 伺服器拉取 preview-pipeline 原始碼專案，並按照專案中 Jenkinsfile 檔案中的宣告式指令碼執行原始碼編譯、測試、容器映象構建和推送、應用部署到 Preview 的容器叢集、釘釘通知的流程；
1. 管理員在 Git 伺服器的 Merge Request 頁面檢視應用的預覽連線並驗證應用是否可以合併到 latest 分支，如果透過驗證則接受 Merge Request 的合併，觸發步驟 6， 如果不透過則通知開發者進行程式碼更新和提交，退回步驟 1；
1. 管理員接受 Merge Request 合併的動作會自動觸發 Jenkins 流水線任務 staging-pipeline 的構建；
1. staging-pipeline 流水線任務從 Git 伺服器拉取 staging-pipeline 原始碼專案，並按照專案中 Jenkinsfile 檔案中的宣告式指令碼執行原始碼編譯、測試、容器映象構建和推送、應用部署到 Staging 的容器叢集、釘釘通知的流程；
1. Staging 環境中的應用服務在透過測試和驗證後，管理員可以合併 latest 分支到 master 分支；
1. 管理員合併 latest 分支到 master 分支後，會自動觸發 Jenkins 流水線任務 production-pipeline 的構建；
1. production-pipeline 流水線任務從 Git 伺服器拉取 production-pipeline 原始碼專案，並按照專案中 Jenkinsfile 檔案中的宣告式指令碼執行原始碼編譯、測試、容器映象構建和推送、應用部署到 Production 的容器叢集、釘釘通知的流程。

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

![14.png](https://ucc.alicdn.com/pic/developer-ecology/185f3957ab58482b83e396a9a988998b.png)

後面，我們會單獨實戰演示 GitOps 安全釋出模型的工作過程。

參考文獻：[https://pivotal.io/cn/cloud-native](https://pivotal.io/cn/cloud-native)

![直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/7566f96a5c5b405fa822f1f42e1ce62b.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

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

相關文章