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

DevOps 是什么

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

從瀑布式開發到敏捷開發

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

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

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

傳統的軟件開發流程是：產品經理收集一線業務部門和客戶的需求，這些需求可能是新功能需求，也可能是對產品現有功能做變更的需求。然后進行評估、分析，將這些需求制定為產品的路線圖，并且分配相應的資源進行相關工作。

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

正是由于商業環境的壓力，軟件廠商需要改進開發方式。

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

有了敏捷聯盟，有了敏捷開發價值觀，必然會產生開發的流派。主要的敏捷開發流派有：

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

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

從敏捷開發到 DevOps

談到了敏捷開發，那么敏捷開發和 DevOps 有什么關系呢？

敏捷開發是開發域里的概念，在敏捷開發基礎之上，有如下階段：

敏捷開發-》持續集成-》持續交付-》持續部署-》DevOps。

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

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

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

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

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

DevOps 的技術實現

DevOps 的技術實現，需要三個方面：標準交付物、容器調度平臺、DevOps 工具鏈。接下來，我們詳細看一下這個三個方面的內容。

DevOps 的技術實現 1：標準交付物

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

當然，真正實現開發運維一體化，并非只是讓開發和運維的人坐在一起那么簡單。從技術角度，DevOps 首先需要有一個包含了“操作系統+Runtime+應用”的標準交付物。除此之外，還需要通過整個 DevOps 流程來打通。

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

容器技術的概念最初出現在 2000 年，當時稱為 FreeBSD jail，這種技術可將 FreeBSD 系統分區為多個子系統。

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

對于客戶而言，Docker 只能在一個 Linux 上運行，是“單機版”，很難符合企業對高可用的需求。此外，docker 也缺乏和持久存儲、虛擬網絡相關的功能。

DevOps 的技術實現 2：容器調度平臺

2014 年 Kubernetes 的出現，奠定了今天容器調度平臺的事實標準的基礎。

因為通過 Kubernetes，我們不僅實現了容器在多個計算節點上的統一調度，還可以將容器對接持久存儲、對接虛擬網絡等。換句話說，Kubernetes 使容器具備企業級的功能。

DevOps 的技術實現 3：DevOps 工具鏈

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

目前在 IT 界，DevOps 相關的工具很多，其中大多數是開源的工具。

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

總結：DevOps 與容器和 Kubernetes 的關系

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

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

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

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

DevOps 工作流展示

常用 DevOps 工具介紹

Kubernetes 集群：包含 Docker 和 Kubernetes

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

Jenkins/Jenkins Slave Pods：持續集成工具

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

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

以上的 DevOps 工具，都可以以容器方式部署到 Kubernetes 集群中。在實驗環境中，有一個兩個節點的 Kubernetes 集群，用于進行實驗展現。

Kubernetes 集群

在 Kubernetes 集群中創建三個 Namespace：cicd、dev、stage。其中 cicd Namespace 存放的是 DevOps 相關工具鏈。dev、stage 是模擬開發和生產兩個環境。

Kubernetes 集群的 Namespaces

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

Kubernetes 集群中部署的 DevOps 工具

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

Nexus 用于存放構建成功、并經過 Code Review 的 war 包，我們查看 Nexus 的界面：

SonarQube 負責 Code review：

Jenkins Pipeline 工作流分析

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

我們查看 Jenkins File 的內容并進行解釋。

第一步，從 Gogs 拉取源代碼，然后調用 maven 進行代碼編譯：

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

第二步，構建成功以后，調用 mvn 進行測試。

清單 2. Pipeline 第二階段

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

第三步，調用 SonarQube 進行代碼 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 會將構建成功的 war 包，以二進制的方式注入到 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 環境，然后引入審批工作流，批準后部署到生產。

清單 6. Pipeline 中的審批流

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

DevOps 工具鏈演示

首先，登錄到 Jenkins 上，查看已經創建好的 Pipeline。

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

Pipeline 的第一個階段是 Build App。

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

清單 7. 構建應用成功的日志

［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 繼續執行，在 Test 成功以后，開始進行 Code Analysis：

Test 階段執行成功的 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 階段執行成功的日志，我們看到日志顯示代碼分析成功，并建議通過瀏覽器訪問 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，查看結果；

接下來，Pilepine 進入到 Create Image Builder 階段，其關鍵的步驟是將構建成功的 war 包以二進制的方式注入到 docker image 中：

清單 10. 構建鏡像的日志

［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 執行成功以后，會生成包含應用的 docker image。接下來是 Create Dev 和 Deploy Dev，即在 dev 環境部署包含應用的 docker image。當 Deploy Dev 成功以后，會引入工作流，提示是否批準將應用部署到 Stage。

選擇 Promote，應用會部署到 Stage，Pipeline 流程走完。

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

至此，您可以看到應用訪問結果，說明 DevOps 全流程已經打通。

總結

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

文章轉載：twt企業IT社區

（版權歸原作者所有，侵刪）

編輯：jq