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

DevOps 是什么

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

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

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

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

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

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

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

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

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

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

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

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

從敏捷開發(fā)到 DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOps 工作流展示

常用 DevOps 工具介紹

Kubernetes 集群：包含 Docker 和 Kubernetes

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

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

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

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

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

Kubernetes 集群

在 Kubernetes 集群中創(chuàng)建三個(gè) Namespace：cicd、dev、stage。其中 cicd Namespace 存放的是 DevOps 相關(guān)工具鏈。dev、stage 是模擬開發(fā)和生產(chǎn)兩個(gè)環(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 工作流分析

整個(gè) Devops 的流程，通過 Jenkins 的 Pipeline 串接起來。在 Jenkins 中，我們可以通過編寫 Jenkins File，或者通過 Jenkins 瀏覽器頁面的操作來完成 Pipeline 的定制。兩者的實(shí)現(xiàn)效果是一樣的，本文以書寫 Jenkins File 方式展現(xiàn)。通過一個(gè) Jenkins File，打通整個(gè) 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)行測(cè)試。

清單 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” } }}

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

清單 4. Pipeline 第四階段

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

第五步，Pipeline 會(huì)將構(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 先將這個(gè) 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。

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

Pipeline 的第一個(gè)階段是 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. 測(cè)試成功的日志

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

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

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

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

總結(jié)

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

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

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

編輯：jq