近兩年，隨著容器、Kubernetes 等技術(shù)的興起，DevOps 這個概念被廣泛提及并被大量使用。本文將會從DevOps的產(chǎn)生、DevOps 與容器/Kubernetes 之間的關(guān)系、DevOps 的技術(shù)實現(xiàn)方式幾個方面，結(jié)合實驗展現(xiàn)的方式，讓讀者真正理解 DevOps 的含義。

DevOps 是什么

DevOps 中的 Dev 指的 Development，Ops 指的是的 Operations，用一句話來說 DevOps 就是打通開發(fā)運維的壁壘，實現(xiàn)開發(fā)運維一體化。

從瀑布式開發(fā)到敏捷開發(fā)

談到 DevOps 的發(fā)展史，我們需要先談一下敏捷開發(fā)。

首先，敏捷開發(fā)是面向軟件的，而軟件依賴于計算硬件。我們知道，世界上第一臺計算機(jī)是在 1946 年出現(xiàn)的。因此，軟件開發(fā)相對于人類歷史而言，時間并不長。相對于軟件開發(fā)方法論的掌握，人們更擅長于工程學(xué)，如蓋樓、造橋等。為了推動軟件開發(fā)，1968 年，人們將工程學(xué)的方法應(yīng)用到軟件領(lǐng)域，由此產(chǎn)生了軟件工程。

軟件工程的方式有其優(yōu)點，但帶來了不少問題。最關(guān)鍵一點是：軟件不同于工程。通過工程學(xué)建造的大橋、高樓在竣工后，人們通常不會對大橋高樓的主體有大量使用需求的變更；但軟件卻不同。對于面向最終用戶的軟件，人們對于軟件功能的需求是會不斷變化的。在瀑布式開發(fā)的模式下，當(dāng)客戶對應(yīng)用有變化的需求時，軟件廠商得重新開發(fā)軟件。這將會使企業(yè)的競爭力大幅下降。

傳統(tǒng)的軟件開發(fā)流程是：產(chǎn)品經(jīng)理收集一線業(yè)務(wù)部門和客戶的需求，這些需求可能是新功能需求，也可能是對產(chǎn)品現(xiàn)有功能做變更的需求。然后進(jìn)行評估、分析，將這些需求制定為產(chǎn)品的路線圖，并且分配相應(yīng)的資源進(jìn)行相關(guān)工作。

接下來，產(chǎn)品經(jīng)理將需求輸出給開發(fā)部門，開發(fā)工程師寫代碼。寫好以后，就由不同的部門的人員進(jìn)行后續(xù)的代碼構(gòu)建、質(zhì)量檢驗、集成測試、用戶驗收測試，最后給生產(chǎn)部門。這樣帶來的問題是，開發(fā)周期比較長，并且如果有任何變更，都要重新走一遍開發(fā)流程，在商場如戰(zhàn)場的今天，軟件一個版本推遲發(fā)布，可能到發(fā)布時這個版本在市場上就已經(jīng)過時了；而競爭對手很可能由于在新軟件發(fā)布上快了一步，而迅速搶占了客戶和市場。

正是由于商業(yè)環(huán)境的壓力，軟件廠商需要改進(jìn)開發(fā)方式。

2001 年初，在美國滑雪勝地 snowbird，17 位專家聚集在一起，概括了一些可以讓軟件開發(fā)團(tuán)隊更具有快速工作、相應(yīng)變化的能力的價值觀原則。他們稱自己為“敏捷聯(lián)盟”。

有了敏捷聯(lián)盟，有了敏捷開發(fā)價值觀，必然會產(chǎn)生開發(fā)的流派。主要的敏捷開發(fā)流派有：

極限編程（XP）、Scrum、水晶方法等。

至此，敏捷開發(fā)有理念、有方法、有實踐。隨著云計算概念的興起，云計算的不斷落地，敏捷開發(fā)不僅實現(xiàn)了工具化，也得到了升華。

從敏捷開發(fā)到 DevOps

談到了敏捷開發(fā)，那么敏捷開發(fā)和 DevOps 有什么關(guān)系呢？

敏捷開發(fā)是開發(fā)域里的概念，在敏捷開發(fā)基礎(chǔ)之上，有如下階段：

敏捷開發(fā)-》持續(xù)集成-》持續(xù)交付-》持續(xù)部署-》DevOps。

從敏捷開發(fā)到 DevOps，前一個階段都是后一個階段的基礎(chǔ)；隨著階段的推進(jìn)，每個階段概念覆蓋的流程越來越多；最終 DevOps 涵蓋了整個開發(fā)和運維階段。正式由于每個階段涉及的范圍不同，因此所以每個概念所提供的工具也是不一樣的。

持續(xù)集成（Continuous Integration）指的是：代碼集成到主干之前，必須全部通過自動化測試；只要有一個測試用例失敗，就不能集成。持續(xù)集成的要實現(xiàn)的目標(biāo)是：在保持高質(zhì)量的基礎(chǔ)上，讓產(chǎn)品可以快速迭代。

持續(xù)交付（Continuous Delivery）指的是：開發(fā)人員頻繁地將軟件的新版本，交付給質(zhì)量團(tuán)隊或者用戶，以供評審。如果評審?fù)ㄟ^，代碼就被發(fā)布。如果評審不通過，那么需要開發(fā)進(jìn)行變更后再提交。

持續(xù)部署（Continuous Deployment）指的是：代碼通過評審并發(fā)布后，自動部署，以交付使用。

DevOps 是一組完整的實踐，可以自動化軟件開發(fā)和 IT 團(tuán)隊之間的流程，以便他們可以更快、更可靠地構(gòu)建、測試和發(fā)布軟件。

DevOps 的技術(shù)實現(xiàn)

DevOps 的技術(shù)實現(xiàn)，需要三個方面：標(biāo)準(zhǔn)交付物、容器調(diào)度平臺、DevOps 工具鏈。接下來，我們詳細(xì)看一下這個三個方面的內(nèi)容。

DevOps 的技術(shù)實現(xiàn) 1：標(biāo)準(zhǔn)交付物

DevOps 的目的在于讓開發(fā)和運維一體化、讓開發(fā)和運維相互之間的溝通更加順暢、迅捷，從而使企業(yè)更能適應(yīng)市場的變化。

當(dāng)然，真正實現(xiàn)開發(fā)運維一體化，并非只是讓開發(fā)和運維的人坐在一起那么簡單。從技術(shù)角度，DevOps 首先需要有一個包含了“操作系統(tǒng)+Runtime+應(yīng)用”的標(biāo)準(zhǔn)交付物。除此之外，還需要通過整個 DevOps 流程來打通。

在 IT 早期，廠商硬件和系統(tǒng)平臺的差異化過大，在不同硬件和系統(tǒng)平臺進(jìn)行應(yīng)用的無縫遷移幾乎是不可想象的。隨著 X86 服務(wù)器以及 vSphere 等虛擬化技術(shù)的普及，操作系統(tǒng)（包括操作系統(tǒng)上的應(yīng)用）可以在不同 X86 服務(wù)器廠商的硬件平臺上在線無縫遷移。硬件差異化不斷縮小甚至消失，軟件的重要性不斷提升，IT 界真正進(jìn)入軟件定義一切的時代。在這個背景下，業(yè)務(wù)提出了更高的要求，如何將應(yīng)用在不同操作系統(tǒng)之間實現(xiàn)無縫遷移，將開發(fā)和生產(chǎn)統(tǒng)一，做到”構(gòu)建一次，到處運行”。

容器技術(shù)的概念最初出現(xiàn)在 2000 年，當(dāng)時稱為 FreeBSD jail，這種技術(shù)可將 FreeBSD 系統(tǒng)分區(qū)為多個子系統(tǒng)。

但直到 Docker 的出現(xiàn)（2008 年），容器才真正具備了較好的可操作性和實用性。因為 Docker 提供了容器的鏡像構(gòu)建、打包等技術(shù)，使容器具備了一次打包，到處運行的能力。

對于客戶而言，Docker 只能在一個 Linux 上運行，是“單機(jī)版”，很難符合企業(yè)對高可用的需求。此外，docker 也缺乏和持久存儲、虛擬網(wǎng)絡(luò)相關(guān)的功能。

DevOps 的技術(shù)實現(xiàn) 2：容器調(diào)度平臺

2014 年 Kubernetes 的出現(xiàn)，奠定了今天容器調(diào)度平臺的事實標(biāo)準(zhǔn)的基礎(chǔ)。

因為通過 Kubernetes，我們不僅實現(xiàn)了容器在多個計算節(jié)點上的統(tǒng)一調(diào)度，還可以將容器對接持久存儲、對接虛擬網(wǎng)絡(luò)等。換句話說，Kubernetes 使容器具備企業(yè)級的功能。

DevOps 的技術(shù)實現(xiàn) 3：DevOps 工具鏈

在有了容器和 Kubernetes 以后，我們還需要相關(guān)的 DevOps 工具鏈。

目前在 IT 界，DevOps 相關(guān)的工具很多，其中大多數(shù)是開源的工具。

在后面的文章中，我們會選擇幾種常用的 DevOps 工具，然后進(jìn)行試驗展現(xiàn)。

總結(jié)：DevOps 與容器和 Kubernetes 的關(guān)系

PaaS、DevOps 的概念，在容器和 Kubernetes 普及之前就存在了。廣義上的 PaaS、DevOps 的建設(shè)，會包含：人、流程、工具等多方面內(nèi)容。IT 廠商提供的 PaaS、DevOps 以指工具層面的落地為主、以流程咨詢?yōu)檩o。

在 Kubernetes 和容器普及之前，我們通過虛擬機(jī)也可以實現(xiàn) PaaS、CI/CD，只是相對速度較慢，因此普及性不高（想象一下通過 X86 虛擬化來實現(xiàn)中間件集群彈性伸縮的效率）。

而正是容器的出現(xiàn)，為 PaaS、DevOps 工具層面的落地提供非常好的承載平臺，使得這兩年容器云風(fēng)生水起。這就好比 4G（2014 年出現(xiàn)）和微信（2011 年出現(xiàn)）之間的關(guān)系：在手機(jī)網(wǎng)速 3G 時代，流量按照兆收費的時候，（即使有）大家對于微信語音聊天、微信視頻也不會太感興趣。

所以說， Docker 使容器具備了較好的可操作性、可移植性，Kubernetes 使容器具備企業(yè)級使用的條件。而 IT 界眾多基于 Kubernetes 和 Docker 企業(yè)級的容器平臺，又成為了 Devops 工具落地的新一代基礎(chǔ)架構(gòu)。

DevOps 工作流展示

常用 DevOps 工具介紹

Kubernetes 集群：包含 Docker 和 Kubernetes

Gogs： 通過 Go 編寫的本地代碼倉庫，功能與 github 類似。

Jenkins/Jenkins Slave Pods：持續(xù)集成工具

Nexus ：工件管理器，能夠解決本地緩存構(gòu)建依賴項。

SonarQube：開源代碼分析工具，它可以分析常見編程錯誤的源代碼

以上的 DevOps 工具，都可以以容器方式部署到 Kubernetes 集群中。在實驗環(huán)境中，有一個兩個節(jié)點的 Kubernetes 集群，用于進(jìn)行實驗展現(xiàn)。

Kubernetes 集群

在 Kubernetes 集群中創(chuàng)建三個 Namespace：cicd、dev、stage。其中 cicd Namespace 存放的是 DevOps 相關(guān)工具鏈。dev、stage 是模擬開發(fā)和生產(chǎn)兩個環(huán)境。

Kubernetes 集群的 Namespaces

接下來，我們看一下在 cicd Namespace 中部署的 DevOps 工具鏈：

Kubernetes 集群中部署的 DevOps 工具

在工具鏈部署成功以后，我們分別登錄工具的 UI 界面進(jìn)行查看。

Nexus 用于存放構(gòu)建成功、并經(jīng)過 Code Review 的 war 包，我們查看 Nexus 的界面：

SonarQube 負(fù)責(zé) Code review：

Jenkins Pipeline 工作流分析

整個 Devops 的流程，通過 Jenkins 的 Pipeline 串接起來。在 Jenkins 中，我們可以通過編寫 Jenkins File，或者通過 Jenkins 瀏覽器頁面的操作來完成 Pipeline 的定制。兩者的實現(xiàn)效果是一樣的，本文以書寫 Jenkins File 方式展現(xiàn)。通過一個 Jenkins File，打通整個 DevOps 流程。

我們查看 Jenkins File 的內(nèi)容并進(jìn)行解釋。

第一步，從 Gogs 拉取源代碼，然后調(diào)用 maven 進(jìn)行代碼編譯：

清單 1. Pipeline 第一階段

pipeline { agent { label ‘maven’} stages { stage（‘Build App’） { steps { git branch： ‘eap-7’， url： ‘http://gogs:3000/gogs/openshift-tasks.git’ script {def pom = readMavenPom file： ‘pom.xml’ version = pom.version } sh “${mvnCmd} install -DskipTests=true” }

第二步，構(gòu)建成功以后，調(diào)用 mvn 進(jìn)行測試。

清單 2. Pipeline 第二階段

stage（‘Test’） { steps { sh “${mvnCmd} test” step（［$class： ‘JUnitResultArchiver’， testResults： ‘**/target/surefire-reports/TEST-*.xml’］） } }

第三步，調(diào)用 SonarQube 進(jìn)行代碼 review。

清單 3. Pipeline 第三階段

stage（‘Code Analysis’） { steps { script { sh “${mvnCmd} sonar:sonar -Dsonar.host.url=http://sonarqube:9000 -DskipTests=true” } }}

第四步，將測試成功的代碼存檔到 Nexus：

清單 4. Pipeline 第四階段

stage（‘Archive App’） { steps { sh “${mvnCmd} deploy -DskipTests=true -P nexus3” } }

第五步，Pipeline 會將構(gòu)建成功的 war 包，以二進(jìn)制的方式注入到 JBoss EAP 的 docker image 中。

清單 5. Pipeline 第五階段

stage（‘Build Image’） { steps { sh “rm -rf oc-build && mkdir -p oc-build/deployments” sh “cp target/tasks.war oc-build/deployments/ROOT.war”

接下來，Pileline 先將這個 docker image 部署到 dev 環(huán)境，然后引入審批工作流，批準(zhǔn)后部署到生產(chǎn)。

清單 6. Pipeline 中的審批流

tage（‘Promote to STAGE？’） { steps { timeout（time:15， unit：‘MINUTES’） { input message： “Promote to STAGE？”， ok： “Promote” }

DevOps 工具鏈演示

首先，登錄到 Jenkins 上，查看已經(jīng)創(chuàng)建好的 Pipeline。

點擊“開始構(gòu)建”，觸發(fā)工作流（工作流也可以通過提交代碼自動觸發(fā)）；

Pipeline 的第一個階段是 Build App。

Build App 成功的 logs 如下，我們可以看到生成了 war 包：

清單 7. 構(gòu)建應(yīng)用成功的日志

［INFO］ Installing /tmp/workspace/cicd-monolith-f138/cicd-monolith-f138-tasks-pipeline/target/tasks.war to /home/jenkins/.m2/repository/org/jboss/quickstarts/eap/jboss-tasks-rs/7.0.0-SNAPSHOT/jboss-tasks-rs-7.0.0-SNAPSHOT.war［INFO］ Installing /tmp/workspace/cicd-monolith-f138/cicd-monolith-f138-tasks-pipeline/pom.xml to /home/jenkins/.m2/repository/or

Pipeline 繼續(xù)執(zhí)行，在 Test 成功以后，開始進(jìn)行 Code Analysis：

Test 階段執(zhí)行成功的 log：

清單 8. 測試成功的日志

------------------------------------------------------- T E S T S-------------------------------------------------------Running org.jboss.as.quickstarts.tasksrs.service.UserResourceTestTests run： 1， Failures： 0， Errors： 0， Skipped： 1， Time elapsed： 1.798 sec - in org.jboss.as.quickstarts.tasksrs.service.UserResourceTestRunning org.jboss.as.quickstarts.tasksrs.service.TaskResourceTestTests run： 3， Failures： 0， Errors： 0， Skipped： 0， Time elapsed： 0.604 sec - in org.jboss.as.quickstarts.tasksrs.service.TaskResourceTestResults ：Tests run： 4， Failures： 0， Errors： 0， Skipped： 1

Code Analysis 階段執(zhí)行成功的日志，我們看到日志顯示代碼分析成功，并建議通過瀏覽器訪問 SonarQube：

清單 9. 代碼分析成功的日志

［INFO］ ANALYSIS SUCCESSFUL， you can browse http://sonarqube:9000/dashboard/index/org.jboss.quickstarts.eap:jboss-tasks-rs［INFO］ Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report［INFO］ More about the report processing at http://sonarqube:9000/api/ce/task？id=AWc_R_EGIPI_jn5vc3mt［INFO］ Task total time： 18.918 s

我們登錄 SonarQube，查看結(jié)果；

接下來，Pilepine 進(jìn)入到 Create Image Builder 階段，其關(guān)鍵的步驟是將構(gòu)建成功的 war 包以二進(jìn)制的方式注入到 docker image 中：

清單 10. 構(gòu)建鏡像的日志

［cicd-monolith-f138-tasks-pipeline］ Running shell script+ rm -rf oc-build+ mkdir -p oc-build/deployments［Pipeline］ sh［cicd-monolith-f138-tasks-pipeline］ Running shell script+ cp target/tasks.war oc-build/deployments/ROOT.war

Create Image Builder 執(zhí)行成功以后，會生成包含應(yīng)用的 docker image。接下來是 Create Dev 和 Deploy Dev，即在 dev 環(huán)境部署包含應(yīng)用的 docker image。當(dāng) Deploy Dev 成功以后，會引入工作流，提示是否批準(zhǔn)將應(yīng)用部署到 Stage。

選擇 Promote，應(yīng)用會部署到 Stage，Pipeline 流程走完。

最后，通過瀏覽器訪問成功部署到 Dev/Stage Namespace 中的應(yīng)用。

至此，您可以看到應(yīng)用訪問結(jié)果，說明 DevOps 全流程已經(jīng)打通。

總結(jié)

通過本文，相信讀者對 DevOps 的概念和工具鏈已經(jīng)有了大致的了解。也對通過 Kubernetes 集群和容器實現(xiàn) DevOps 有了一定的理解。

文章轉(zhuǎn)載：twt企業(yè)IT社區(qū)

（版權(quán)歸原作者所有，侵刪）

編輯：jq