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

導(dǎo)讀：DevOps 是一種軟件開發(fā)人員和 IT人員之間的合作過程，目標(biāo)是高效地自動執(zhí)行軟件交付和基礎(chǔ)架構(gòu)更改流程。在云原生時代，企業(yè)又如何借助 DevOps 實現(xiàn)產(chǎn)品快速、穩(wěn)定、高效和安全地迭代，釋放業(yè)務(wù)價值呢？

什么是云原生

為了解決傳統(tǒng)應(yīng)用升級緩慢、架構(gòu)臃腫、不能快速迭代、故障不能快速定位、問題無法快速解決等問題，云原生這一概念橫空出世。

Pivotal 是云原生應(yīng)用的提出者，并推出了 Pivotal Cloud Foundry 云原生應(yīng)用平臺和 Spring 開源 Java 開發(fā)框架，成為云原生應(yīng)用架構(gòu)中先驅(qū)者和探路者。

早在 2015 年 Pivotal 公司的 Matt Stine 就寫了一本叫做遷移到云原生應(yīng)用架構(gòu)的小冊子，其中探討了云原生應(yīng)用架構(gòu)的幾個主要特征：

• 符合 12 因素應(yīng)用

• 面向微服務(wù)架構(gòu)

• 自服務(wù)敏捷架構(gòu)

• 基于 API 的協(xié)作

• 抗脆弱性

后來 Pivotal 對云原生的定義做過幾次更新， 最新的 Pivotal 官網(wǎng)上對云原生應(yīng)用的最新介紹是關(guān)注以下四點(diǎn)：

• 集成 DevOps

• 持續(xù)交付

• 微服務(wù)

• 容器化

• DevOps 是軟件開發(fā)人員和 IT 運(yùn)營之間的合作，目標(biāo)是自動執(zhí)行軟件交付和基礎(chǔ)架構(gòu)更改流程。它創(chuàng)造了一種文化和環(huán)境，可在其中快速、頻繁且更可靠地構(gòu)建、測試和發(fā)布軟件；

• 持續(xù)交付使得單個應(yīng)用更改在準(zhǔn)備就緒后即可發(fā)布，而不必等待與其它更改捆綁發(fā)布或等待維護(hù)窗口期等事件。持續(xù)交付讓發(fā)布行為變得平淡可靠，因此企業(yè)可以以更低的風(fēng)險頻繁交付，并更快地獲得最終用戶的反饋，直到部署成為業(yè)務(wù)流程和企業(yè)競爭力必不可少的組成部分；

• 微服務(wù)是將應(yīng)用作為小型服務(wù)集合進(jìn)行開發(fā)的架構(gòu)方法，其中每個服務(wù)都可實施業(yè)務(wù)功能，在自己的流程中運(yùn)行并通過 HTTP API 進(jìn)行通信。每個微服務(wù)都可以獨(dú)立于應(yīng)用中的其他服務(wù)進(jìn)行部署、升級、擴(kuò)展和重新啟動，通常作為自動化系統(tǒng)的一部分運(yùn)行，可以在不影響最終客戶的情況下頻繁更新正在使用中的應(yīng)用；

• 與標(biāo)準(zhǔn)虛擬機(jī)相比，容器能同時提供效率和速度。單個操作系統(tǒng)實例使用操作系統(tǒng) 級的虛擬化，在一個或多個隔離容器之間進(jìn)行動態(tài)劃分，每個容器都具有唯一的可寫文件系統(tǒng)和資源配額。創(chuàng)建和破壞容器的開銷較低，再加上單個虛擬機(jī)中的高包裝密度，使容器成為部署各個微服務(wù)的完美計算工具。

Google 主導(dǎo)成立了云原生計算基金會（CNCF），對云原生的定義為：

“云原生（Cloud Native）技術(shù)幫助企業(yè)和機(jī)構(gòu)在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、 服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API；這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段，云原生技術(shù)可以使開發(fā)者輕松地對系統(tǒng)進(jìn)行頻繁并可預(yù)測的重大變更 。”

目前云原生背后最大的推手就是 CNCF，關(guān)鍵技術(shù)包括容器、微服務(wù)、服務(wù)網(wǎng)格、devops，聲明式的 API 等等。

云原生應(yīng)用與傳統(tǒng)應(yīng)用的對比，云原生應(yīng)用可以充分利用云的優(yōu)勢，靈活地在各個云廠商分發(fā)應(yīng)用，釋放企業(yè)生產(chǎn)力，聚焦到業(yè)務(wù)創(chuàng)新上，而不是花費(fèi)更多的時間在適配和擴(kuò)展不同的基礎(chǔ)設(shè)施平臺上。

云原生時代的 DevOps 新挑戰(zhàn)

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

• 唯快不破。這里的快可以解讀出來兩層含義，一是業(yè)務(wù)應(yīng)用快速上線，有利于搶占市場先機(jī)，第二層意思就是在你的業(yè)務(wù)有爆炸式增長的時候，你如何在計算資源上給以充分的保證，這個時候其實追加巨額的 IT 投資購買軟硬件也未必能跟得上業(yè)務(wù)的快速發(fā)展。這個其實就是企業(yè)研發(fā)效能的問題；

• 穩(wěn)中求變。業(yè)務(wù)或者應(yīng)用的穩(wěn)定性永遠(yuǎn)都是第一位的，如何既保證業(yè)務(wù)的“穩(wěn)態(tài)”又要滿足快捷商業(yè)的“敏態(tài)”需求，比如新業(yè)務(wù)的上線、應(yīng)用的變更等。這個是企業(yè) IT 架構(gòu)的問題；

• 節(jié)省資源，如何節(jié)省計算資源，根據(jù)業(yè)務(wù)是否高峰自動擴(kuò)容縮容，這個是云平臺建設(shè)的問題；

• 開拓創(chuàng)新，開發(fā)運(yùn)維一體化、微服務(wù)架構(gòu)。

DevOps 最初的出現(xiàn)打破了開發(fā)人員和運(yùn)維人員之間歷來存在的壁壘和溝鴻，加強(qiáng)了開發(fā)、運(yùn)營和質(zhì)量保證人員之間的溝通、協(xié)作與整合。在后 DevOps 時代，我們可以借助容器技術(shù)更快地對應(yīng)用進(jìn)行迭代上線。

下面是應(yīng)用發(fā)布的一般過程，開發(fā)者 push 代碼，觸發(fā)構(gòu)建，構(gòu)建過程是拉取源碼，應(yīng)用打包，容器鏡像推送，部署。

這個模型其實已經(jīng)有很多地方充分利用了云原生的優(yōu)勢，比如容器技術(shù)、Kubernetes、動態(tài)分配 slave pod 等。但還有一些挑戰(zhàn)。

• 如何應(yīng)用在環(huán)境棧之間的安全推進(jìn)發(fā)布

• 如何管理應(yīng)用發(fā)布的權(quán)限和安全審批

• 如何提高應(yīng)用的平均部署時間和平均恢復(fù)時間

• 如何迅速對線上應(yīng)用進(jìn)行故障定位、復(fù)現(xiàn)和回滾

云原生時代下的 DevOps 之道

首先我們要充分利用云原生技術(shù)的優(yōu)勢，云原生可以改進(jìn)應(yīng)用開發(fā)的效率，改變企業(yè)的組織結(jié)構(gòu)，甚至?xí)谖幕瘜用嫔现苯佑绊懸粋€公司的決策。在容器領(lǐng)域內(nèi)，Kubernetes 已經(jīng)成為了容器編排和管理的社區(qū)標(biāo)準(zhǔn)。它通過把應(yīng)用服務(wù)抽象成多種資源類型，比如 Deployment、Service 等，提供了一個云原生應(yīng)用通用的可移植模型。

在這樣的背景下，我們?nèi)绾卧谠圃沫h(huán)境下實踐更高效的 DevOps 來達(dá)到更有生產(chǎn)力的表現(xiàn)就成為了一個新的課題和訴求。

下面是一個企業(yè)應(yīng)用平臺的建設(shè)目標(biāo)：

在此 PaaS 平臺的基礎(chǔ)上，我們設(shè)計了 GitOps 安全發(fā)布模型來解決前面我們提到的一些挑戰(zhàn)。

在設(shè)計 GitOps 發(fā)布模型的時候是有以下這些核心訴求的：

• 版本管理。我們希望每一個發(fā)布的應(yīng)用的版本號都能跟 git commit id 關(guān)聯(lián)，這樣的好處就是每一個變更都有歷史記錄查詢、可以更快進(jìn)行故障定位和修復(fù)；

• 基線管理。便于問題復(fù)現(xiàn)和快速回滾；

• 安全發(fā)布。包括發(fā)布權(quán)限管理以及安全審批的內(nèi)容；

• 快速反饋。提高研發(fā)效能。

GitOps 發(fā)布模型有以下特性：

• Git 倉庫是任何 CICD 過程的唯一輸入源

• 聲明式的應(yīng)用編排、構(gòu)建部署模型

• 應(yīng)用在環(huán)境棧之間的無差別、自動化推進(jìn)

• PR/MR 觸發(fā)的拉取式流水線過程

• 快速反饋機(jī)制

下面是使用 GitOps 管理應(yīng)用發(fā)布到不同 Kubernetes 集群的架構(gòu)圖。

首先是應(yīng)用源碼與構(gòu)建源碼分離，我們可以看到橙色框起來的這兩個源碼項目，一個是我們的應(yīng)用源碼項目 application-java-demo， 左側(cè)的這個源碼項目是用來存放構(gòu)建源碼的，比如 preview pipeline 的 Jenkinsfile， staging pipeline 的 Jenkinsfile，production pipeline 的 Jenkinsfile， 除了 Jenkinsfile 之外，可能還有一些關(guān)于動態(tài)創(chuàng)建測試環(huán)境、連接預(yù)發(fā)環(huán)境或者生產(chǎn)環(huán)境的敏感信息，這些敏感信息也可以存放在數(shù)據(jù)庫里，然后這里保存數(shù)據(jù)庫的連接信息。

這個普通應(yīng)用 application-java-demo 在 Git 倉庫里是有不同的分支的，每個分支跟 Kubernetes 集群環(huán)境都有一定的對應(yīng)關(guān)系，比如我們這里的設(shè)定，master 分支對應(yīng)的是生產(chǎn)環(huán)境，latest 分支對應(yīng)的是預(yù)發(fā)環(huán)境，其他開發(fā)分支對應(yīng)的是測試環(huán)境，測試環(huán)境的動態(tài)創(chuàng)建和銷毀、應(yīng)用再測試環(huán)境的部署發(fā)布是開發(fā)測試人員自助的服務(wù)，但應(yīng)用想要部署到預(yù)發(fā)環(huán)境和生產(chǎn)環(huán)境中的話是需要經(jīng)過管理員安全審批的。

普通開發(fā)者的權(quán)限只有創(chuàng)建新代碼分支和創(chuàng)建合并請求的權(quán)限，除此之外，剩下其他的部分都是管理員才有權(quán)限做的，綠色區(qū)域是 Jenkins 的流水線任務(wù)，當(dāng)然你也可以是使用其他 cicd 引擎來做這個流水線任務(wù)的構(gòu)建。普通開發(fā)者沒有 Jenkins 環(huán)境的創(chuàng)建 Job 和構(gòu)建 Job 的權(quán)限，也沒有更改配置的權(quán)限，他有的只是構(gòu)建 Job 的日志查看權(quán)限。

最后是一個時序圖，演示一個應(yīng)用從開發(fā)測試到業(yè)務(wù)上線迭代的一個完整流程：

開發(fā)者提交新的功能分支 feature；

開發(fā)者創(chuàng)建請求合并代碼到 latest 分支的 Merge Request；

開發(fā)者創(chuàng)建 Merge Request 的動作自動觸發(fā)名為 preview-pipeline 的 Jenkins 流水線任務(wù)的構(gòu)建；

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

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

管理員接受 Merge Request 合并的動作會自動觸發(fā) Jenkins 流水線任務(wù) staging-pipeline 的構(gòu)建；

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

Staging 環(huán)境中的應(yīng)用服務(wù)在通過測試和驗證后，管理員可以合并 latest 分支到 master 分支；

管理員合并 latest 分支到 master 分支后，會自動觸發(fā) Jenkins 流水線任務(wù) production-pipeline 的構(gòu)建；

production-pipeline 流水線任務(wù)從 Git 服務(wù)器拉取 production-pipeline 源碼項目，并按照項目中 Jenkinsfile 文件中的聲明式腳本運(yùn)行源碼編譯、測試、容器鏡像構(gòu)建和推送、應(yīng)用部署到 Production 的容器集群、釘釘通知的流程。

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

后面，我們會單獨(dú)實戰(zhàn)演示 GitOps 安全發(fā)布模型的工作過程。

參考文獻(xiàn)：

• https://pivotal.io/cn/cloud-native

——?The End?——

大家在看：

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

• 見微知著，構(gòu)“見”未來
  

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

• 當(dāng)當(dāng)年中慶典，力度超前，花120買300的硬核書
  

---

中生代技術(shù)社區(qū)提供內(nèi)推服務(wù)，對應(yīng)BAT，網(wǎng)易，頭條等大廠對接到用人部門，

有需求請?zhí)砑尤汉匣锶?strong>大白的微信

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

? ?END ? ?? #接力技術(shù)，鏈接價值#

新人創(chuàng)作打卡挑戰(zhàn)賽發(fā)博客就能抽獎！定制產(chǎn)品紅包拿不停！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。