作者 | 郝樹偉（流生）阿里云高級研發工程師

導讀：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 的日志查看權限。

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

開發者提交新的功能分支 feature；

開發者創建請求合并代碼到 latest 分支的 Merge Request；

開發者創建 Merge Request 的動作自動觸發名為 preview-pipeline 的 Jenkins 流水線任務的構建；

preview-pipeline 流水線任務從 Git 服務器拉取 preview-pipeline 源碼項目，并按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Preview 的容器集群、釘釘通知的流程；

管理員在 Git 服務器的 Merge Request 頁面查看應用的預覽連接并驗證應用是否可以合并到 latest 分支，如果通過驗證則接受 Merge Request 的合并，觸發步驟 6， 如果不通過則通知開發者進行代碼更新和提交，退回步驟 1；

管理員接受 Merge Request 合并的動作會自動觸發 Jenkins 流水線任務 staging-pipeline 的構建；

staging-pipeline 流水線任務從 Git 服務器拉取 staging-pipeline 源碼項目，并按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Staging 的容器集群、釘釘通知的流程；

Staging 環境中的應用服務在通過測試和驗證后，管理員可以合并 latest 分支到 master 分支；

管理員合并 latest 分支到 master 分支后，會自動觸發 Jenkins 流水線任務 production-pipeline 的構建；

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

——?The End?——

大家在看：

• 豆瓣9.0，35萬讀者“搜不到信息”的JVM大牛，我們幫你找到了
  

• 見微知著，構“見”未來
  

• 新炬首架梁銘圖：從70萬字SRE神作提煉出7千字精華與君共勉
  

• 當當年中慶典，力度超前，花120買300的硬核書
  

---

中生代技術社區提供內推服務，對應BAT，網易，頭條等大廠對接到用人部門，

有需求請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）通過后溝通需求！

? ?END ? ?? #接力技術，鏈接價值#

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的阿里高工流生 | 云原生时代的 DevOps 之道的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。