本篇內(nèi)容主要講解“基于Jenkins和Kubernetes的CI工作流怎么實(shí)現(xiàn)”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“基于Jenkins和Kubernetes的CI工作流怎么實(shí)現(xiàn)”吧!

創(chuàng)新互聯(lián)專注于饒陽企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城開發(fā)。饒陽網(wǎng)站建設(shè)公司,為饒陽等地區(qū)提供建站服務(wù)。全流程按需制作網(wǎng)站，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

摘要

Jenkins作為最為流行的持續(xù)集成工具，在結(jié)合使用容器技術(shù)，Kubernetes 集群的基礎(chǔ)上，該如何發(fā)揮出新的能力， 在應(yīng)用微服務(wù)化的基礎(chǔ)上，提供更好的CI方式，值得我們每一個(gè)開發(fā)人員去持續(xù)不斷的摸索。 

Jenkins 和 Kubernetes

Jenkins作為最流行的持續(xù)集成工具，有著豐富的用戶群、強(qiáng)大的擴(kuò)展能力、豐富的插件，是開發(fā)人員最為常見的CI工具。在Jenkins 加強(qiáng)其Pipeline功能后，更是可以通過豐富的step庫，實(shí)現(xiàn)各種復(fù)雜的流程。同時(shí)隨著Docker的流行，Jenkins內(nèi)也增加了對Docker的支持，可以實(shí)現(xiàn)容器內(nèi)流程的執(zhí)行。

而Kubernetes隨著版本迭代的速度越來越快，在容器圈內(nèi)的熱度也越來越高，同時(shí)每次版本發(fā)布，所新增的功能也不斷增加。做為當(dāng)前主流的容器管理平臺，其強(qiáng)大的能力無需在此多做介紹。

應(yīng)用容器化和應(yīng)用微服務(wù)化設(shè)計(jì)思考

容器化不意味著微服務(wù)化，傳統(tǒng)單體應(yīng)用也可以容器化，但是很難享受到容器化后帶來的好處。微服務(wù)化也不是一定要容器化，應(yīng)用拆解為微服務(wù)后，一樣可以不利用容器而是通過傳統(tǒng)的運(yùn)維來完成系統(tǒng)構(gòu)建和部署。當(dāng)微服務(wù)化和容器化相結(jié)合之后，就能充分利用各方優(yōu)勢，帶來了彈性伸縮，簡化部署，易于擴(kuò)展，技術(shù)兼容等優(yōu)點(diǎn)。

我們在針對應(yīng)用進(jìn)行微服務(wù)化拆分的過程中，主要先考慮到的是功能點(diǎn)、控制對象、開發(fā)組的人員配置安排，產(chǎn)品路線圖規(guī)劃等。例如，針對現(xiàn)有開發(fā)組人員人數(shù)、分配和各自的技能熟練程度，就可以考慮到服務(wù)模塊數(shù)量的控制，安排好服務(wù)模塊開發(fā)小組；針對功能點(diǎn)和中遠(yuǎn)期產(chǎn)品規(guī)劃，就可以將特定功能歸納到一個(gè)服務(wù)模塊中，并在版本開發(fā)迭代的過程中，通過擴(kuò)展這個(gè)服務(wù)模塊的能力，來完成產(chǎn)品功能的開發(fā)，或者暫時(shí)將部分功能整合在一個(gè)模塊中，隨著功能增加或迭代開發(fā)，再進(jìn)行進(jìn)一步的模塊拆分或拆解。

對于模塊開發(fā)的要求，由于使用了容器技術(shù)，對于開發(fā)語言或特定框架的選型，可以交給具體的模塊開發(fā)人員。在團(tuán)隊(duì)內(nèi)，我們不做強(qiáng)制要求，但是做建議要求，避免出現(xiàn)過多的技術(shù)棧，導(dǎo)致后期的維護(hù)困難。在我們團(tuán)隊(duì)內(nèi)，就只集中在兩種后端開發(fā)語言的使用，相應(yīng)的框架或主要的開發(fā)庫，也都有相應(yīng)而且明確的選擇。對于模塊的API接口，使用REST，并且至少按照成熟度模型LEVEL2提供API。

容器環(huán)境下的編譯和單元測試

我們整個(gè)CI工作流的驅(qū)動(dòng)，都是由Jenkins完成，并且使用了Jenkins Pipeline。第一，Pipeline可以更好的組合job內(nèi)的Stage，重復(fù)利用模塊間相同的部分，并且隨著開發(fā)復(fù)雜度的增加來逐步增加擴(kuò)展stage，實(shí)現(xiàn)更多所需的功能；第二，將Pipeline Groovy腳本來源設(shè)置為源代碼內(nèi)，可以根據(jù)源代碼功能點(diǎn)來控制流程，同時(shí)也完成了對腳本的版本管理。

由于有容器這么個(gè)工具，我們各個(gè)模塊的編譯環(huán)境，單元測試環(huán)境，也都放到了容器中。各個(gè)模塊均可以安裝自身模塊的運(yùn)行特性或環(huán)境要求，準(zhǔn)備自身的編譯環(huán)境、單元測試環(huán)境、運(yùn)行環(huán)境，因此，代碼庫內(nèi)會分別留存相應(yīng)的Dockerfile，通過不同的Dockerfile完成不同環(huán)境鏡像的準(zhǔn)備。

同時(shí)，jenkins現(xiàn)在也可以通過Docker Pipeline插件，支持在容器內(nèi)運(yùn)行Step，因此我們利用其功能完成的實(shí)際的編譯和測試流程是這樣的：

1. 使用編譯環(huán)境的Dockerfile構(gòu)建編譯環(huán)境鏡像。

2. 使用編譯環(huán)境鏡像啟動(dòng)容器并在容器內(nèi)完成編譯，完成編譯的中間產(chǎn)物也暫存在Workspace中。

3. 使用測試環(huán)境的Dockerfile構(gòu)件單元測試環(huán)境鏡像。

4. 使用單元測試環(huán)境鏡像啟動(dòng)容器并在容器內(nèi)運(yùn)行單元測試，單元測試腳本來源于代碼庫，同時(shí)也使用到編譯時(shí)生成的中間產(chǎn)物。

5. 使用發(fā)布Dockerfile構(gòu)建實(shí)際發(fā)布鏡像并上傳鏡像庫。

其中由于編譯環(huán)境和單元測試環(huán)境不是經(jīng)常變更，也可以抽出編譯環(huán)境鏡像準(zhǔn)備和單元測試環(huán)境鏡像準(zhǔn)備兩個(gè)步驟放到獨(dú)立的CI job中去，需要時(shí)手工觸發(fā)即可。

服務(wù)部署和升級

對于CI流程，在完成編譯和打包后，需要做的就是服務(wù)啟動(dòng)和測試了。我們利用的是Kubernetes Deployment和Service，在每次CI流程完成編譯和打包后，通過拿到Build號，作為鏡像的Tag，完成鏡像的上傳歸檔；同時(shí)利用Tag，修改Kubernetes中已經(jīng)創(chuàng)建的Deployment，利用Deployment的Rolling Update，完成升級。

對kubernetes服務(wù)模版和服務(wù)配置的擴(kuò)展 

我們在實(shí)際使用Kubernetes Deployment 升級的方式進(jìn)行服務(wù)部署的過程中，發(fā)現(xiàn)其中還是存在很多不方便的地方。例如：Kubernetes內(nèi)的同名問題，Kubernetes Deployment升級時(shí)的鏡像tag變更問題，等等各處需要隨著CI流程可能存在變更的地方。例如在有相同名字的Deployment存在的情況下，后來的Deployment會無法創(chuàng)建，這導(dǎo)致如果想以啟動(dòng)新的Deployment的方式來測試某個(gè)版本，需要修改名稱，對于與Deployment相關(guān)的Service也一樣，在啟動(dòng)新的命名后的Deployment，也需要啟動(dòng)與其對應(yīng)的Service用于暴露服務(wù)。對于Deployment升級所需的鏡像Tag修改，需要每次隨著CI生成了新的鏡像Tag而做變更，因而每次需要修改相應(yīng)Yaml文件內(nèi)的鏡像Tag，修改為實(shí)際CI流程中生成的值，然后再使用升級功能完成服務(wù)升級。

針對這些問題，我們使用了一套文本模板引擎，部署或升級用的Yaml文件本身寫成為模板，可能有變化或者需要根據(jù)CI流程變化的位置，使用模板標(biāo)識占位，而具體的模板數(shù)據(jù)內(nèi)容，則或者通過Jenkins的CI流程獲取，或者使用特定的配置文件讀取，或者從具體的輸入?yún)?shù)來獲??；同時(shí)，模板數(shù)據(jù)內(nèi)容，也會在實(shí)際部署時(shí)，做為Kubernetes的Configmap設(shè)置到系統(tǒng)中，因此數(shù)據(jù)內(nèi)容也可以通過Kubernetes使用Configmap的方式來用到環(huán)境變量或啟動(dòng)命令中。通過文本模板引擎，將模板和數(shù)據(jù)合并后，生成的Yaml文件，再作為后續(xù)Kubernetes操作所使用的內(nèi)容。

通過利用這種方式，我們把需要部署的內(nèi)容分離成了模板和配置；模板一般在服務(wù)架構(gòu)，使用的鏡像名，啟動(dòng)方式或配置參數(shù)沒有大的變化的情況下保持不變，而通過不同配置的靈活使用，完成服務(wù)升級或拉起新部署，完成不同數(shù)據(jù)存儲使用的指向，完成對各模塊內(nèi)部配置的修改。通過利用這種方式，我們的可修改的內(nèi)容，從Configmap本身只能覆蓋到的環(huán)境變量或啟動(dòng)命令這塊，擴(kuò)展到了啟動(dòng)名稱，Label，鏡像等Yaml文件內(nèi)的各個(gè)可填值處，以此來解決同名，鏡像修改，Label增加或變更等各種使用Kubernetes時(shí)碰到的問題。

自動(dòng)化測試

在通過Jenkins拉動(dòng)完成編譯打包和服務(wù)升級部署后，就可以拉動(dòng)自動(dòng)化測試了。測試框架我們選擇了使用Robotframework。測試腳本通過Kubernetes Service獲取到服務(wù)的具體暴露端口，然后再根據(jù)測試腳本依次執(zhí)行針對API的測試。測試腳本的來源，部分是從各模塊代碼庫中，由各模塊開發(fā)人員提交的針對自身模塊的api測試，部分是由測試人員完成撰寫提交的針對跨模塊的測試。針對自動(dòng)化測試這塊，我們的完成度并不是很高，僅僅是搭建起了基本的運(yùn)行框架，能夠與整個(gè)流程對接上。

版本發(fā)布

由于開發(fā)的產(chǎn)品本身就是由若干鏡像構(gòu)成，因此產(chǎn)品發(fā)布，可以歸結(jié)為鏡像的發(fā)布。在測試通過后，可以簡單的利用鏡像復(fù)制能力，將測試通過的相關(guān)鏡像的版本，通過鏡像庫間的復(fù)制，由開發(fā)測試所用的內(nèi)部鏡像庫，復(fù)制到外部發(fā)布鏡像庫，就可以完成版本發(fā)布，同時(shí)可以通過復(fù)制時(shí)的Tag控制，發(fā)布為指定的版本號。

總結(jié)

如上介紹，說明了我們在自身開發(fā)過程中建立CI流程的做法。對于整個(gè)流程的建立，我們并沒有太多需要特殊化處理的地方；對于各項(xiàng)工具的使用，也沒有太多突出之處；我們僅僅根據(jù)自身需求，建立了和開發(fā)過程適配的ci流。在此介紹我們的ci流程的建立，也是希望拋磚引玉，能從更多處獲得交流和向大家學(xué)習(xí)的機(jī)會。

Q&A

Q1：嘉賓分享的內(nèi)容還是概括了些，有沒有具體例子？配圖說明的直觀內(nèi)容？

A：基于K8s的CICD產(chǎn)品即將發(fā)布，會提供對應(yīng)的Demo演示平臺，請及時(shí)關(guān)注，謝謝！

Q2：關(guān)于Jenkins和Docker集成的幾個(gè)插件可以分享一下嗎？

A：Docker Pipeline、Docker Plugin、Docker-build-step 這幾個(gè)插件。

Q3：請問有容云的鏡像復(fù)制大體思路是什么？目前我們是測試、預(yù)發(fā)布、發(fā)布共享一個(gè)倉庫。通過輔助模塊標(biāo)簽實(shí)現(xiàn)的！

A：鏡像復(fù)制功能，簡單來說實(shí)現(xiàn)了不同項(xiàng)目間的鏡像克隆，根據(jù)我們鏡像倉庫的設(shè)計(jì)，對不同階段（開發(fā)，測試，可上線）的鏡像以不同項(xiàng)目分類，基于鏡像復(fù)制功能即可快速實(shí)現(xiàn)不同階段的產(chǎn)品發(fā)布，也就是鏡像發(fā)布，此功能可下載AppHouse版本進(jìn)行試用。

Q4：貴公司同步的嗎？你們的配置文件是通過配置中？你們的配置文件是通過配置中心管理還是鏡像間的環(huán)境變量實(shí)現(xiàn)的?

A：不是實(shí)時(shí)同步的，而是通過了我們公司鏡像庫產(chǎn)品的鏡像復(fù)制能力實(shí)現(xiàn)的。目前開發(fā)流程中的產(chǎn)品運(yùn)行配置是通過自身增強(qiáng)的配置文件能力實(shí)現(xiàn)的，配置會用來修改應(yīng)用部署的Yaml文件，也會生成為Configmap。

Q5：有沒有一個(gè)簡單的Sample？可以上手跟著練習(xí)一下。

A：基于K8s的CICD產(chǎn)品即將發(fā)布，會提供對應(yīng)的Demo演示平臺，請及時(shí)關(guān)注，謝謝！

Q6：此次內(nèi)容的Step by step 示例，能提供一個(gè)Demo嗎？

A：基于K8s的CICD產(chǎn)品即將發(fā)布，會提供對應(yīng)的Demo演示平臺，請及時(shí)關(guān)注，謝謝！

Q7：我的項(xiàng)目的版本二只是修改了幾個(gè)頁面，也是和第一次發(fā)布一樣的流程嗎？

A：是的，流程化就是代表著可重復(fù)和可自動(dòng)化，而無需去關(guān)系具體的修改內(nèi)容。

Q8：你們部署的K8s版本是哪個(gè)？K8s的調(diào)度服務(wù)只能覺得容器起在哪個(gè)節(jié)點(diǎn)上吧，Rc是2的話，構(gòu)建任務(wù)運(yùn)行在哪個(gè)容器中這個(gè)怎么調(diào)度，為什么我的都運(yùn)行在一個(gè)容器里面？

A :我們目前使用的是Kubernetes1.5版本。本身構(gòu)建任務(wù)不是跑在Kubernetes上的，而只是應(yīng)用自身跑在Kubernetes上。

Q9：你們是類似于Openshift那種平臺式的嗎？還是需要開發(fā)人員自己部署？

A :本身講的是我們自身產(chǎn)品開發(fā)的流程，相關(guān)的產(chǎn)品會是類似平臺型產(chǎn)品，需要自行部署，而不是公有云產(chǎn)品。

Q10：兩個(gè)框架是開源的嗎？

A :是的，都是開源的。

Q11：K8s的Yaml的部署文件的模板怎么去替換占位符？舊版本的容器怎么處理？

A :使用了自身開發(fā)的一套文本模板引擎，其實(shí)類似Web框架中的模板引擎，完成模板和配置的合并，通過使用配置中的key-value，替換掉模板中key的占位符。另外由于是使用的K8s Deployment的Rolling Update，升級完成后舊版本的容器/Pod會由Kubernetes自行刪除。

Q12：開發(fā)測試、部署等各個(gè)階段的鏡像，方便共享一下嗎？

A :這些鏡像都是我們自身針對我們各應(yīng)用模塊所準(zhǔn)備的，對其他人并沒有什么用處，編譯環(huán)境用的鏡像不少就是官方鏡像，例如Golang:1.7, Python:2.7。

Q13：傳統(tǒng)單體應(yīng)用如何容器化改造，可否分階段實(shí)施？

A : 可以的，容器化改造或微服務(wù)化改造有很多實(shí)施方法，例如逐漸重構(gòu)拆解，或新增模塊進(jìn)行微服務(wù)化和容器化，或開發(fā)新的模塊替代原有應(yīng)用的功能點(diǎn)，等等。各團(tuán)隊(duì)均可以選擇合適自身的流程來進(jìn)行改造。

Q14：數(shù)據(jù)庫可以容器化嗎？

A :可通過將數(shù)據(jù)卷掛入容器的方式將數(shù)據(jù)庫容器化，但是現(xiàn)在實(shí)際項(xiàng)目中還很少見。

Q15：我們目前也是使用jenkins動(dòng)態(tài)掛載容器來運(yùn)行安卓編譯構(gòu)建作業(yè)，但現(xiàn)在每次使用鏡像生成容器后因?yàn)橐麓a，導(dǎo)致整體編譯時(shí)間比以前使用物理機(jī)方式要延長10多分鐘，我們的鏡像每天自動(dòng)制作和下載，但因?yàn)榇a更新太快及并發(fā)太多，編譯時(shí)需要獨(dú)占物理機(jī)，所以機(jī)器占用也很多，大家有什么建議解決這個(gè)問題，謝謝！

A :容器化編譯就是將編譯環(huán)境封裝起來了，這種情況下一臺物理機(jī)同步跑多個(gè)Job也行，可以看看怎么提高對物理機(jī)的利用率。

Q16：請問項(xiàng)目中存在多個(gè)鏡像，是如何做關(guān)聯(lián)發(fā)布的?

A :我們是使用了Jenkins的Mutil Pipeline，另外由于我們的模塊的微服務(wù)拆解，對應(yīng)同步發(fā)布鏡像的需求并不高。

Q17：有這樣一個(gè)場景，兩個(gè)服務(wù)有依賴關(guān)系，服務(wù)A依賴于服務(wù)B，如何保證服務(wù)A和B的啟動(dòng)順序的？

A :良好的設(shè)計(jì)是使得A服務(wù)啟動(dòng)后自行完成對B服務(wù)的檢測發(fā)現(xiàn)和調(diào)用,而不是強(qiáng)依賴其啟動(dòng)順序。

Q18：Kubernetes的服務(wù)的模板和配置，這個(gè)模板怎么來的，是用戶自己編排？還是自己事先準(zhǔn)備好的？配置數(shù)據(jù)是怎么存儲的？

A : 因?yàn)楫?dāng)前模板和配置只用來啟動(dòng)我們自身開發(fā)的應(yīng)用，因此這個(gè)模板是我們自己為我們的應(yīng)用準(zhǔn)備的。配置數(shù)據(jù)以文件的形式存儲，但同時(shí)在使用文本引擎做模板和配置合并時(shí)，也可以接受參數(shù)作為配置。

Q19：什么是CI和CD？

A : CI更多是偏向應(yīng)用編譯、代碼檢查、單元測試等動(dòng)作，CD是偏向于應(yīng)用部署、運(yùn)行流程，我們的開發(fā)過程在編譯打包完成后，實(shí)際也會將應(yīng)用跑起來用于測試，也可以算是針對測試的CD。

Q20：使用容器打包Jenkins流程的主要收益是什么？

A : 由于不同程序?qū)τ诰幾g環(huán)境的依賴各有不同，原有使用Jenkins方法是在Jenkins Node上完成環(huán)境準(zhǔn)備，現(xiàn)在可以利用容器完成環(huán)境準(zhǔn)備，對于Jenkins Node的依賴可以進(jìn)一步降低。同時(shí)環(huán)境變更也可以由開發(fā)人員自行控制。

Q21：多編譯環(huán)境是用的不同鏡像么？如何處理pipeline處理編譯環(huán)境的問題？

A : 是的。由于我們本身產(chǎn)品開發(fā)各個(gè)模塊有各個(gè)模塊的開發(fā)語言和框架，因此各模塊都要維護(hù)自身的編譯環(huán)境鏡像。使用Pipeline在進(jìn)行編譯時(shí)，是通過使用鏡像運(yùn)行容器然后在容器內(nèi)編譯的方式來使用編譯環(huán)境的。

Q22：產(chǎn)品發(fā)布的產(chǎn)出為鏡像，如果有很多鏡像，最終會在鏡像上打上統(tǒng)一的Tag么代碼上的Tag什么時(shí)機(jī)打呢？

A : 我們是在產(chǎn)品發(fā)布時(shí),進(jìn)行鏡像復(fù)制時(shí)統(tǒng)一打發(fā)布Tag的，這時(shí)候從開發(fā)測試庫會復(fù)制到發(fā)布庫，利用了我們公司自身鏡像庫產(chǎn)品的鏡像復(fù)制能力。

Q23：請問Jenkins 也是部署在Docker里面的嗎？如果Jenkins在Docker里面怎么樣在Docker里面使用Docker執(zhí)行CI？

A : 是的，我們也在摸索將Jenkins本身放到容器中運(yùn)行。在這種情況下，Jenkins容器內(nèi)使用Root權(quán)限，掛載Docker.Sock和Docker數(shù)據(jù)目錄到容器中就可以了。

Q24：使用Pipeline先構(gòu)建編譯環(huán)境鏡像，再編譯，是否會導(dǎo)致整個(gè)流程需要很長時(shí)間？是否有優(yōu)化方案？

A :編譯鏡像由于不會經(jīng)常變動(dòng)，因此這個(gè)鏡像的構(gòu)建通常使用Cache就能直接完成。另外我們也把編譯環(huán)境鏡像打包這個(gè)步驟抽出來單獨(dú)作為Job執(zhí)行了，這樣在實(shí)際編譯流程中就無需再進(jìn)行編譯環(huán)境構(gòu)建。

Q25：直接使用Jenkins的Docker插件和直接調(diào)用腳本，自己寫Docker命令，如何在靈活程度和方便程度上做權(quán)衡？

A :看個(gè)人或開發(fā)團(tuán)隊(duì)的自行權(quán)衡吧，只是開發(fā)團(tuán)隊(duì)內(nèi)最好統(tǒng)一，便于進(jìn)行相應(yīng)維護(hù)。

Q26：Jenkins和Kubernetes的用戶是怎么管理的？我的期望是用戶只能看到自己得資源，別的用戶是沒有權(quán)限的。

A : 我們本身只是使用這兩種工具，在開發(fā)環(huán)境中不對外，所有不存在用戶管理的問題。在我們公司正在開發(fā)的CICD產(chǎn)品中，對這塊有我們自身理解基礎(chǔ)上的設(shè)計(jì)。

Q27：Jenkins的持續(xù)集成是怎么實(shí)現(xiàn)的？比如不同的源碼倉庫的提交觸發(fā)，如Github gitlab,版本號怎么控制的？

A : Jenkins的CI流程觸發(fā)可以有很多種，代碼提交觸發(fā)、定時(shí)觸發(fā)、手動(dòng)觸發(fā)。版本號的控制也可以有很多方案，比如使用Job的編號、使用Git的Commit號、使用時(shí)間戳等等。

Q28：Jerkins 調(diào)用K8s API 用了什么插件么？

A :沒有直接使用Jenkins調(diào)用Kubernetes API。

Q29：Jenkins的Pipeline支持流水線執(zhí)行，一般從頭開始執(zhí)行，可以從流水線中任意一步執(zhí)行嗎？

A : 因?yàn)槲覀儓F(tuán)隊(duì)的Jenkinsfile都是直接放置在代碼庫內(nèi)的，因此每次執(zhí)行都是從頭完成流水線的執(zhí)行。

Q30：容器化后發(fā)布也要通過Jenkins，感覺Docker的發(fā)布沒有Jenkins方便，除了容器化的可移植，還有什么原因值得推進(jìn)項(xiàng)目容器化？

A : 應(yīng)用容器化，其實(shí)更多的是看重應(yīng)用在容器管理平臺上運(yùn)行起來后所獲得的能力，例如在Kubernetes上運(yùn)行后的水平擴(kuò)展，服務(wù)發(fā)現(xiàn)，滾動(dòng)升級，等等。

Q31：K8s Update需要制定新的鏡像才能做滾服更新(升級)，如果只是更新了Configmap，有辦法做滾服更新嗎？

A : 我們的CI流程完成后，各模塊的鏡像Tag會發(fā)生變化，我們利用具體生成的Tag生成配置，然后部署的Yaml文件寫為模板，鏡像的具體Tag會根據(jù)每次CI流程生成的配置不同而組合為不同的Yaml文件，然后使用組合后的Yaml，即Tag已經(jīng)變更為最新版本的Yaml文件進(jìn)行應(yīng)用的滾動(dòng)升級。

Q32：Pipeline采用在鏡像里構(gòu)建的方案，是怎么實(shí)現(xiàn)的？用Jenkins現(xiàn)成的插件 or 用Groovy腳本實(shí)現(xiàn)？

A :使用了Jenkins的Docker插件，同時(shí)使用方式是將相應(yīng)命令寫在Groovy腳本里。

例如：stage('Build'){        docker.image('golang:1.7').inside {             sh './script/build.sh'                  }    }

到此，相信大家對“基于Jenkins和Kubernetes的CI工作流怎么實(shí)現(xiàn)”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！