梁岸川 上汽通用五菱汽車股份有限公司 凌以靜 上汽通用五菱汽車股份有限公司

引言

當(dāng)前云計(jì)算在軟件公司中獲得了極大的普及。市場(chǎng)上已經(jīng)有多個(gè)云服務(wù)巨頭：亞馬遜云服務(wù)(AWS)，微軟azure，阿里云和谷歌云。與此同時(shí)，中型企業(yè)也開始進(jìn)入這個(gè)市場(chǎng)。所有這些吸引力都源于云計(jì)算帶來(lái)的好處。例如，云中的后端服務(wù)允許公司不構(gòu)建自己的基礎(chǔ)設(shè)施，而且安全性和備份也由云提供商負(fù)責(zé)。此外，kubernetes 可擴(kuò)展的開源平臺(tái)在當(dāng)今得到了廣泛的應(yīng)用，它提供了創(chuàng)建自己的平臺(tái)解決方案的可能性，這些平臺(tái)解決方案可以執(zhí)行容器化的應(yīng)用程序。

應(yīng)用程序的開發(fā)包括不同的階段：設(shè)計(jì)、編碼、測(cè)試、構(gòu)建、發(fā)布等等。主要目標(biāo)是滿足客戶的需求。為了實(shí)現(xiàn)這一目標(biāo)，公司應(yīng)該盡可能頻繁地迭代、發(fā)布產(chǎn)品。目的是為了更快地部署新功能和修復(fù)BUG。持續(xù)集成實(shí)踐有助于實(shí)現(xiàn)這些需求。

本文的目標(biāo)是研究持續(xù)集成持續(xù)部署的最佳實(shí)踐，并構(gòu)建一個(gè)自動(dòng)化流水線。關(guān)鍵價(jià)值在于實(shí)現(xiàn)所有階段的流程自動(dòng)化。

首先會(huì)回顧本課題項(xiàng)目研究的理論背景和技術(shù)背景，包括微服務(wù)、K8S，CICD 等。

最后將介紹具體持續(xù)集成的實(shí)現(xiàn)方法。要實(shí)現(xiàn)最終目標(biāo)，需要通過多個(gè)實(shí)施步驟。

1 理論背景

1.1 微服務(wù)

應(yīng)用程序市場(chǎng)正在不斷增長(zhǎng)。最終用戶希望獲得更優(yōu)質(zhì)的服務(wù)，包括具有豐富的功能，現(xiàn)代化、可感知的設(shè)計(jì)和全天候可用性。為了滿足這些需求，軟件公司需要盡可能頻繁地推出更新，更快速地迭代產(chǎn)品。

微服務(wù)架構(gòu)包含多個(gè)松耦合的小組件。每個(gè)模塊都只執(zhí)行自己的任務(wù)，并獨(dú)立于其他模塊。模塊之間通過 REST API 接口進(jìn)行通信。微服務(wù)架構(gòu)可以加快測(cè)試和部署速度。

1.1.1 微服務(wù)的特性

為了更好地理解微服務(wù)架構(gòu)風(fēng)格，需要回顧幾個(gè)特征。

代碼庫(kù)

特定微服務(wù)組件的代碼量相對(duì)較小，其功能應(yīng)該僅限于完成特定的任務(wù)。在這種情況下，團(tuán)隊(duì)中的新加入的開發(fā)人員更容易讀懂代碼邏輯以及貢獻(xiàn)新的代碼。此外，使用更小的模塊構(gòu)建和運(yùn)行應(yīng)用程序的開發(fā)效率要快得多。

在傳統(tǒng)單體架構(gòu)中，即使是很小的變化也需要構(gòu)建整個(gè)項(xiàng)目。這可能會(huì)導(dǎo)致應(yīng)用程序有很少的發(fā)行版本，卻有大量的更改。在微服務(wù)開發(fā)中，鼓勵(lì)更快更頻繁地發(fā)布。獨(dú)立部署服務(wù)時(shí)，更容易跟蹤故障，如果出現(xiàn)問題，則回滾到之前的穩(wěn)定版本不會(huì)花費(fèi)太多時(shí)間。

可擴(kuò)展性

通常，為了擴(kuò)展大型單體應(yīng)用程序的高可用或負(fù)載均衡節(jié)點(diǎn)，則需要完整地部署整個(gè)系統(tǒng)。如果只是某些功能需要更多實(shí)例資源，同樣需要完整地部署多套系統(tǒng)，因此，擴(kuò)展此類應(yīng)用需要大量資源，很明顯，復(fù)制大型單體應(yīng)用系統(tǒng)的效率并不高。相比之下，每個(gè)微服務(wù)可以具有不同數(shù)量的副本，這將提高應(yīng)用程序的性能和資源的利用率。

1.1.2 微服務(wù)的挑戰(zhàn)

與單體應(yīng)用相比，微服務(wù)架構(gòu)具有許多優(yōu)點(diǎn)，易于部署，擴(kuò)展，修復(fù)等等。盡管如此，微服務(wù)架構(gòu)還是存在一些挑戰(zhàn)。每個(gè)微服務(wù)組件都是一個(gè)獨(dú)立的模塊，它與其它獨(dú)立組件打包在一起工作，因此，處理服務(wù)之間的通信變得復(fù)雜。需要為微服務(wù)間的API 接口編寫良好的文檔，管理這些接口的工作成為重中之重。

測(cè)試

與單體架構(gòu)相比，測(cè)試小型獨(dú)立組件更容易。然而，總體上測(cè)試系統(tǒng)變得更具挑戰(zhàn)性。需進(jìn)行大量的集成測(cè)試，以驗(yàn)證系統(tǒng)是否正常工作。此外，還需要更多資源來(lái)測(cè)試系統(tǒng)。在這種情況下，設(shè)計(jì)良好的pipline 是必須的。

代碼

微服務(wù)架構(gòu)允許開發(fā)人員為他們需要實(shí)現(xiàn)的模塊選擇不同的技術(shù)，框架和庫(kù)。在特定模塊上工作的團(tuán)隊(duì)的規(guī)模可能相對(duì)較小，因此如果一個(gè)成員離開公司，另一個(gè)團(tuán)隊(duì)的開發(fā)人員必須學(xué)習(xí)新的工具才能接手這個(gè)模塊的工作。

安全

模塊可以被其它服務(wù)重用。模塊化使黑客有更多的入口點(diǎn)可以滲透到系統(tǒng)中。在處理用戶數(shù)據(jù)時(shí)，安全性是必須要考慮的，應(yīng)該投入大量精力來(lái)處理微服務(wù)架構(gòu)中的安全風(fēng)險(xiǎn)。

1.2 Kubernetes

需要了解容器才能更好地掌握kubernetes。以前，應(yīng)用程序部署在主機(jī)系統(tǒng)上，這會(huì)導(dǎo)致應(yīng)用程序配置，生命周期和主機(jī)操作系統(tǒng)之間有較高的耦合度。

容器是打包應(yīng)用程序和在不同環(huán)境中部署應(yīng)用程序的方法。如何管理、擴(kuò)展和恢復(fù)這些資源仍然是一個(gè)問題。Kubernetes 的出現(xiàn)是為了解決這些問題。

Kubernetes 源于谷歌內(nèi)部的Borg 系統(tǒng)，提供了面向應(yīng)用的容器集群部署和管理系統(tǒng)。Kubernetes 的目標(biāo)旨在消除編排物理/虛擬計(jì)算，網(wǎng)絡(luò)和存儲(chǔ)基礎(chǔ)設(shè)施的負(fù)擔(dān)，并使應(yīng)用程序運(yùn)營(yíng)商和開發(fā)人員完全將重點(diǎn)放在以容器為中心的原語(yǔ)上進(jìn)行自助運(yùn)營(yíng)。

Kubernetes 用戶可以通過編寫yaml 或者json 格式的配置文件，通過直接請(qǐng)求Kubernetes API 創(chuàng)建應(yīng)用，該配置文件中包含了用戶想要應(yīng)用程序保持的狀態(tài)，就算整個(gè)Kubernetes 集群中的個(gè)別主機(jī)發(fā)生異常，都會(huì)保持用戶所期望的應(yīng)用程序的狀態(tài)，這一切都由kubernetes 自動(dòng)完成。

Kubernetes 集群是一組計(jì)算節(jié)點(diǎn)組成的一個(gè)資源集合。它由兩種類型的節(jié)點(diǎn)組成：主節(jié)點(diǎn)和從節(jié)點(diǎn)。Master 是管理節(jié)點(diǎn)，負(fù)責(zé)集群資源的調(diào)度、擴(kuò)展、終止以及更新應(yīng)用程序。從節(jié)點(diǎn)負(fù)責(zé)運(yùn)行應(yīng)用程序。圖1 展示了kubernetes 集群。

圖1.Kubernetes 集群架構(gòu)

每個(gè)工作節(jié)點(diǎn)都有kubelet 組件，它負(fù)責(zé)與管理節(jié)點(diǎn)進(jìn)行通訊。此外，從節(jié)點(diǎn)需要這些組件來(lái)創(chuàng)建、運(yùn)行和刪除容器應(yīng)用程序。它可以是docker、rkt 或LXD。Master 節(jié)點(diǎn)的API 是集群的入口。可以使用Deployment 在kubernetes 集群中部署容器化應(yīng)用程序。在kubernetes 中，Deployment 配置描述了如何更新和創(chuàng)建應(yīng)用程序。當(dāng)創(chuàng)建Deployment 時(shí)，kubernetes 會(huì)生成Pod，它是一種抽象概念，用于表示應(yīng)用程序的一個(gè)實(shí)例以及與之相關(guān)的一組資源集合，通常包含一個(gè)或多個(gè)容器。當(dāng)創(chuàng)建Pod時(shí)，它駐留在某個(gè)節(jié)點(diǎn)上，直到它被終止。如果Pod 所在的節(jié)點(diǎn)發(fā)生故障，則Kubernetes 集群會(huì)自動(dòng)在另外一個(gè)健康節(jié)點(diǎn)生成同樣配置的Pod，這個(gè)新的Pod 對(duì)外提供與原Pod一模一樣的功能，對(duì)外部用戶來(lái)說(shuō)，他們并不需要關(guān)心這些Pod 所支撐的服務(wù)運(yùn)行在哪個(gè)節(jié)點(diǎn)之上。

圖2.kubernetes 集群中Pod 和Service 的關(guān)系示例[3]

kubernetes集群的主要優(yōu)勢(shì)是可以輕松實(shí)現(xiàn)對(duì)Pod擴(kuò)容和縮容。通過更改Pod 的副本數(shù)量可以輕松實(shí)現(xiàn)。當(dāng)Master 節(jié)點(diǎn)擴(kuò)展應(yīng)用程序時(shí)，它會(huì)自動(dòng)選擇在其中一個(gè)擁有足夠多資源的節(jié)點(diǎn)中創(chuàng)建Pod 副本。運(yùn)行一個(gè)Pod 的多個(gè)副本需要相應(yīng)的機(jī)制來(lái)分配流量。這由與該應(yīng)用程序關(guān)聯(lián)的Service 負(fù)責(zé)，Servcie 內(nèi)部實(shí)現(xiàn)了負(fù)載均衡[圖2]。

2 持續(xù)集成的實(shí)踐

2.1 CI 和CD （持續(xù)集成和持續(xù)交付）

市場(chǎng)的高度競(jìng)爭(zhēng)迫使企業(yè)分配大量的人力和計(jì)算資源來(lái)實(shí)現(xiàn)CI、CD。這些實(shí)踐為軟件開發(fā)帶來(lái)了很多好處。從頻繁的發(fā)布開始。這改善了用戶體驗(yàn)，因?yàn)樾鹿δ芙桓兜酶臁?/p>

持續(xù)集成是一種軟件開發(fā)實(shí)踐，開發(fā)人員通常在日常工作中提交代碼。每次集成都由自動(dòng)測(cè)試系統(tǒng)進(jìn)行檢查，以便在早期階段捕獲問題。

持續(xù)交付是持續(xù)集成過程的延伸，它提供了一種可持續(xù)的產(chǎn)品發(fā)布方式。這意味著不僅測(cè)試過程、構(gòu)建過程應(yīng)該是自動(dòng)化的，發(fā)布過程也應(yīng)該是自動(dòng)化的。為了開始開發(fā)這個(gè)過程，需要有穩(wěn)定可靠的持續(xù)集成。這個(gè)過程有一個(gè)將產(chǎn)品部署到生產(chǎn)的手動(dòng)步驟，但是部署應(yīng)該是自動(dòng)化的。持續(xù)交付的好處是你可以頻繁地進(jìn)行小版本發(fā)布，在快速地交付小功能的同時(shí)也可以更快地修復(fù)bug。

常用的CI 工具有Jenkins、Travis 、Circle 等等，本文將介紹基于Jenkins 的CI 方法。Jenkins 是一個(gè)開源的、提供友好操作界面的持續(xù)集成(CI)工具，起源于Hudson（商業(yè)產(chǎn)品），主要用于持續(xù)、自動(dòng)地構(gòu)建、測(cè)試軟件項(xiàng)目，監(jiān)控外部任務(wù)的運(yùn)行。

2.2 持續(xù)集成的實(shí)踐

在上一章中，我們回顧了微服務(wù)、k8s 等關(guān)鍵技術(shù)背景，微服務(wù)應(yīng)用架構(gòu)在當(dāng)下非常流行，有著易于部署、擴(kuò)展、修復(fù)等諸多優(yōu)點(diǎn)，以docker 為代表的容器技術(shù)成為微服務(wù)架構(gòu)應(yīng)用的交付標(biāo)準(zhǔn)，而Kubernetes 又是當(dāng)今容器編排技術(shù)的事實(shí)標(biāo)準(zhǔn)，將應(yīng)用部署在云供應(yīng)商提供的基礎(chǔ)設(shè)施所構(gòu)建的Kubernetes 集群中，可同時(shí)獲得k8s以及云計(jì)算帶來(lái)的諸多好處，又可以避免被云供應(yīng)商綁定。

Kubernetes 細(xì)化的應(yīng)用程序的分解粒度，同時(shí)將服務(wù)發(fā)現(xiàn)、配置管理、負(fù)載均衡和健康檢查等作為基礎(chǔ)設(shè)施的功能，簡(jiǎn)化了應(yīng)用程序的開發(fā)。而且Kubernetes 這種聲明式配置尤其適合CI/CD 流程。圖1 展示了基于Kubernetes 和jenkins 的CI 過程。

圖3.基于 Kubernetes 和Jenkins 的CI 流程圖

應(yīng)用構(gòu)建和發(fā)布流程：

1.開發(fā)者向Gitlab 提交代碼，代碼中包含構(gòu)建鏡像所需的Dockerfile，以及微服務(wù)應(yīng)用所對(duì)應(yīng)的服務(wù)類型、服務(wù)名稱、資源數(shù)量、實(shí)例個(gè)數(shù)。

2.代碼提交到遠(yuǎn)程Git 倉(cāng)庫(kù)之后，通過webhook 觸發(fā)Jenkins自動(dòng)構(gòu)建。

3.Jenkins 的CI 流水線自動(dòng)編譯代碼并打包成docker 鏡像推送到Harbor 鏡像倉(cāng)庫(kù)

4.Jenkins 的CI 流水線中包括了自定義腳本，根據(jù)我們已準(zhǔn)備好的kubernetes 的YAML 模板，將其中的變量替換成用戶輸入的選項(xiàng)

5.生成微服務(wù)應(yīng)用的kubernetes yaml 配置文件

6.更新Ingress 的配置，根據(jù)新部署的應(yīng)用的名稱，在ingress的配置文件中增加一條路由信息

7.Jenkins 調(diào)用kubernetes 的API，部署應(yīng)用。

以上的構(gòu)建均在開發(fā)者提交Gitlab 之后全自動(dòng)完成。

3 總結(jié)

持續(xù)集成的目的，就是讓應(yīng)用產(chǎn)品可以更快速地迭代，以適應(yīng)不斷變化的業(yè)務(wù)需求。持續(xù)集成的關(guān)鍵不是集成，而是持續(xù)。所謂持續(xù)，就需要自動(dòng)化。代碼的每次合并都會(huì)觸發(fā)持續(xù)集成服務(wù)器進(jìn)行自動(dòng)構(gòu)建，這個(gè)過程包括了編譯、單元測(cè)試、集成、集成測(cè)試、質(zhì)量分析、性能測(cè)試等步驟。在本文中，我們介紹了當(dāng)今熱門的微服務(wù)架構(gòu)以及容器編排工具Kubernetes，并且展示了基于Jenkins 和Kubernetes 的持續(xù)集成方案。