近年來(lái)，互聯(lián)網(wǎng)極速發(fā)展，為了跟進(jìn)業(yè)務(wù)快速增長(zhǎng)的發(fā)展步伐，新的技術(shù)如雨后春筍般不斷的涌現(xiàn)，一眼望去，漫天星光，群星爭(zhēng)艷。以容器為核心的云原生技術(shù)成長(zhǎng)迅速，其中 Kubernetes 作為新的基礎(chǔ)設(shè)施，容器編排事實(shí)上的標(biāo)準(zhǔn)，無(wú)疑是最耀眼的那顆星。

然而，Kubernetes 雖然很好的解決了大規(guī)模應(yīng)用部署，資源管理及調(diào)度的問(wèn)題，但是其對(duì)業(yè)務(wù)交付并不友好，Kubernetes 自身的部署也比較復(fù)雜，在不斷涌現(xiàn)的圍繞 Kubernetes 生態(tài)的應(yīng)用中，始終缺少了可以將業(yè)務(wù)、中間件、集群整合起來(lái)一體化交付的應(yīng)用。

在當(dāng)下，由阿里云智能云原生應(yīng)用平臺(tái)團(tuán)隊(duì)發(fā)起，政采云、諧云科技合作共建的 sealer 開源項(xiàng)目補(bǔ)充了 Kubernetes 在一體化交付領(lǐng)域的短板，sealer 以非常優(yōu)雅的設(shè)計(jì)方案考慮了集群 + 分布式應(yīng)用的整體交付。而政采云作為政府采購(gòu)行業(yè)的代表，已成功的利用 sealer 完成了大型分布式應(yīng)用的整體私有化交付，交付的實(shí)踐充分證明了：sealer 具備靈活，強(qiáng)大的一體化交付能力。

背景

政采云的私有化交付客戶為政企場(chǎng)景，需交付業(yè)務(wù)規(guī)模較大：300+ 業(yè)務(wù)組件， 20+ 中間件，交付目標(biāo)的基礎(chǔ)設(shè)施不同構(gòu)且不可控，網(wǎng)絡(luò)限制嚴(yán)格，一些敏感的場(chǎng)景甚至是完全隔離的網(wǎng)絡(luò)，在這種背景下，業(yè)務(wù)交付的最大痛點(diǎn)就是部署依賴的處理以及交付一致性的問(wèn)題。雖然業(yè)務(wù)統(tǒng)一基于 Kubernetes 進(jìn)行交付實(shí)現(xiàn)了運(yùn)行環(huán)境的一致，但是如何解決部署過(guò)程中所依賴的所有鏡像、各種包的統(tǒng)一處理以及交付系統(tǒng)自身的一致性等一系列問(wèn)題，亟需解決。

如上圖所示政采云本地化交付的流程中，主要分為：用戶需求確認(rèn)-> 提出資源需求給用戶 -> 獲得用戶所提供的資源清單 -> 根據(jù)資源清單生成準(zhǔn)備配置 -> 準(zhǔn)備部署腳本及依賴 -> 實(shí)際交付六個(gè)步驟。前置準(zhǔn)備和實(shí)際交付時(shí)，需要消耗大量的人力和時(shí)間來(lái)準(zhǔn)備和進(jìn)行部署。

私有化交付的痛

云原生時(shí)代，docker 的出現(xiàn)解決了單個(gè)應(yīng)用的環(huán)境一致性和打包問(wèn)題，業(yè)務(wù)的交付不再像傳統(tǒng)的交付那樣花費(fèi)大量的時(shí)間在部署環(huán)境依賴上。而后 Kubernetes 等容器編排系統(tǒng)的出現(xiàn)解決了對(duì)底層資源進(jìn)行統(tǒng)一的調(diào)度，對(duì)應(yīng)用運(yùn)行時(shí)進(jìn)行統(tǒng)一的編排的問(wèn)題，然而一個(gè)復(fù)雜的業(yè)務(wù)，其交付的本身就是一個(gè)工程浩大的問(wèn)題，以政采云的場(chǎng)景為例：各種 helm chart、RBAC， istio gateway，cni，中間件等各種資源對(duì)象的部署和配置，再加上 300 余業(yè)務(wù)組件的交付，每一次私有化交付帶來(lái)的都是大量人力和時(shí)間成本的消耗。

政采云正處于業(yè)務(wù)高速發(fā)展的時(shí)期，私有化部署項(xiàng)目的需求不斷新增，高成本的交付方式越來(lái)越難以支撐實(shí)際的需要，如何降低交付成本，并保障交付的一致性是運(yùn)維團(tuán)隊(duì)最迫切的需要解決的問(wèn)題。

發(fā)現(xiàn) sealer

在早期，政采云使用 ansible 來(lái)進(jìn)行業(yè)務(wù)的交付，ansible 方案實(shí)現(xiàn)了一定程度的自動(dòng)化并降低了交付成本但是存在如下幾個(gè)問(wèn)題：

1、ansible 只解決部署過(guò)程問(wèn)題，需要單獨(dú)準(zhǔn)備部署所需的依賴，依賴的準(zhǔn)備和可用性驗(yàn)證產(chǎn)生了額外的成本，且政采云的本地化場(chǎng)景基本都會(huì)嚴(yán)格限制外部網(wǎng)絡(luò)。直接從外網(wǎng)獲取依賴的方式也不可行。

2、使用 ansible 應(yīng)對(duì)差異化的需求會(huì)非常累，政采云的私有化交付場(chǎng)景中，各個(gè)用戶的需求不一，業(yè)務(wù)的依賴不一，每一次的交付重新編輯 ansible playbook 都要花費(fèi)不少的時(shí)間進(jìn)行調(diào)試。

3、涉及到復(fù)雜的控制邏輯時(shí)，ansible 的聲明語(yǔ)言比較乏力。

4、部署交付之前需要先準(zhǔn)備 ansible 的運(yùn)行環(huán)境。無(wú)法做到交付的0依賴。

ansible 更多的是在做一些粘合的事情，更適合邏輯比較簡(jiǎn)單的運(yùn)維工作。隨著本地化項(xiàng)目不斷新增， ansible 交付的弊端開始顯現(xiàn)，每個(gè)本地化項(xiàng)目都需要大量的時(shí)間投入，政采云運(yùn)維團(tuán)隊(duì)開始探索和思考交付體系的優(yōu)化方向。我們調(diào)研了很多的技術(shù)方案，但是已有的 Kubernetes 的交付工具都專注于集群本身的交付而不考慮業(yè)務(wù)層交付。雖然可以基于集群部署工具進(jìn)行封裝，但是這種方案和使用 ansible 進(jìn)行集群部署后再去部署上層業(yè)務(wù)并沒(méi)有本質(zhì)的區(qū)別。

比較幸運(yùn)的是，我們發(fā)現(xiàn)了 sealer 項(xiàng)目, sealer 是一套分布式應(yīng)用打包交付的解決方案，通過(guò)把分布式應(yīng)用及其依賴一起打包以解決復(fù)雜應(yīng)用的交付問(wèn)題。其設(shè)計(jì)理念非常優(yōu)雅，可以以容器鏡像的生態(tài)來(lái)管理整個(gè)集群的打包交付。

在使用 Docker 的時(shí)候，我們通過(guò) Dockerfile 來(lái)定義單個(gè)應(yīng)用的運(yùn)行環(huán)境和打包，相應(yīng)的，sealer 的技術(shù)原理可以通過(guò)類比 Docker 來(lái)進(jìn)行解釋，把整個(gè)集群當(dāng)做一臺(tái)機(jī)器，把 Kubernetes 定義為操作系統(tǒng)，通過(guò) Kubefile 來(lái)定義這個(gè)"操作系統(tǒng)"里面的應(yīng)用并最終打包成鏡像，然后像 Docker run 交付單個(gè)應(yīng)用一樣，sealer run 就可以將整個(gè)集群及應(yīng)用交付出去。

發(fā)現(xiàn) sealer 的驚喜之余，我們邀請(qǐng)了社區(qū)的伙伴來(lái)公司進(jìn)行了交流，sealer 還是一個(gè)新項(xiàng)目，年輕到只誕生了幾個(gè)月的時(shí)間，在實(shí)際的體驗(yàn)中我們遇到了不少問(wèn)題，也踩了不少的坑，落地嘗試時(shí)，也發(fā)現(xiàn)了挺多不滿足需求的地方，但是我們并沒(méi)有放棄，因?yàn)槲覀儗?duì) sealer 的設(shè)計(jì)模式抱有很大的期望和信心，我們選擇了與社區(qū)一起協(xié)作共建，共同成長(zhǎng)。而最終成功的落地實(shí)踐也證明了，我們的選擇非常正確！

社區(qū)協(xié)作

在決定與社區(qū)合作之初，我們對(duì) sealer 進(jìn)行了全面的測(cè)試評(píng)估，結(jié)合我們的需求場(chǎng)景，主要存在如下幾個(gè)問(wèn)題：

1、鏡像緩存成本太高，最初 sealer 只提供 cloud build 的方式，即打包 sealer 集群鏡像的前提是需要先基于云資源拉起一個(gè)集群，我們認(rèn)為這種方式成本太高，基于這個(gè)需求我們提案并且貢獻(xiàn)了 lite build 的構(gòu)建方式，支持通過(guò)解析 helm、資源定義 yaml、鏡像清單的方式解析鏡像并直接緩存。lite build 是成本最低的 build 方式，無(wú)需拉起集群，只需一臺(tái)要能夠運(yùn)行 sealer 的主機(jī)即可完成 build。

2、業(yè)務(wù)交付完之后，缺少 check 機(jī)制，需要手工去檢查 Kubernetes 集群的各個(gè)組件狀態(tài)，然后，我們貢獻(xiàn)了集群及組件狀態(tài)的 check 功能。

3、早期 sealer 的一些配置是固化在 rootfs 中的，例如 registry 的部署主機(jī)是固定在第一個(gè) master 節(jié)點(diǎn)上的，在實(shí)際的場(chǎng)景中我們有自定義的需求，于是我們貢獻(xiàn)了自定義 registry 配置的功能。

4、基于 sealer 部署完集群后，還會(huì)有向集群中添加節(jié)點(diǎn)的需求，因此我們貢獻(xiàn)了 sealer join 的功能。

此外，還有必要說(shuō)一下我們落地時(shí)幾個(gè)很實(shí)用，很強(qiáng)大的 sealer 特性：

1、必須提到的一點(diǎn)是 sealer 構(gòu)建產(chǎn)出的集群鏡像完全可以直接 push 到私有的 docker 鏡像倉(cāng)庫(kù)例如 harbor 中。然后像 docker 鏡像一樣，可以基于已有鏡像的基礎(chǔ)上擴(kuò)充功能并再次 build。

2、sealer 社區(qū)優(yōu)化了 registry 和 docker，使其支持多源，多域名的代理緩存，這是一個(gè)非常實(shí)用的功能，在處理鏡像依賴的時(shí)候，我們緩存一個(gè)鏡像需要變動(dòng)鏡像的地址，例如需要把一個(gè)公共鏡像緩存到私有鏡像中，對(duì)應(yīng)的資源對(duì)象引用的鏡像地址也需要同步變更為私有鏡像倉(cāng)庫(kù)的地址，但 sealer 內(nèi)置的 registry 經(jīng)過(guò)優(yōu)化實(shí)現(xiàn)了不需要修改鏡像地址也能匹配緩存的功能。此外， sealer 中內(nèi)置的 registry 作為 proxy 時(shí)，可以代理多個(gè)私有化的鏡像倉(cāng)庫(kù)，在具有多個(gè)私有倉(cāng)庫(kù)的場(chǎng)景中，是很實(shí)用的功能。

落地實(shí)踐

使用 sealer 我們重新定義了交付流程，通過(guò) Kubefile 將業(yè)務(wù)組件、容器化中間件的交付、鏡像緩存等組件的交付直接使用 sealer 來(lái)完成。利用 sealer lite build 模式，自動(dòng)化的完成依賴鏡像的解析及緩存內(nèi)置。

利用 sealer 屏蔽了大量應(yīng)用交付的復(fù)雜過(guò)程邏輯，和依賴處理邏輯，使實(shí)施難度極大的簡(jiǎn)化。實(shí)施邏輯的持續(xù)簡(jiǎn)化，使得規(guī)?；桓冻蔀榭赡?。在我們的實(shí)踐場(chǎng)景中，使用新的交付系統(tǒng)，交付周期從 15天/人縮短至 2天/人，實(shí)現(xiàn)了包含 20G 業(yè)務(wù)鏡像緩存， 2000G+內(nèi)存 800+核心 CPU 規(guī)模集群的成功交付。下一步我們計(jì)劃通過(guò)持續(xù)的簡(jiǎn)化交付過(guò)程，使一個(gè)新手只需要簡(jiǎn)單的培訓(xùn)即可完成整個(gè)項(xiàng)目的交付。

未來(lái)展望

落地的成功，收獲的不僅僅是交付系統(tǒng)的成果，更體現(xiàn)了開源的力量，探索出了與社區(qū)合作共建的新模式。在未來(lái)，政采云將繼續(xù)支持并參與 sealer 社區(qū)的建設(shè)，結(jié)合實(shí)際的業(yè)務(wù)場(chǎng)景，為社區(qū)提供更多的貢獻(xiàn)。

作為一個(gè)新的開源項(xiàng)目，sealer 的現(xiàn)在并不完美，還存在一些待解決和優(yōu)化的問(wèn)題，還有更多的需求和業(yè)務(wù)場(chǎng)景等待我們?nèi)?shí)現(xiàn)，希望通過(guò)持續(xù)的貢獻(xiàn)，讓 sealer 可以服務(wù)于更多的用戶場(chǎng)景，同時(shí)也希望有更多的合作伙伴能夠參與社區(qū)建設(shè)，讓 sealer 這顆星，更加的璀璨奪目！

政采云基于 sealer 的私有化業(yè)務(wù)交付實(shí)踐

背景

私有化交付的痛

發(fā)現(xiàn) sealer

社區(qū)協(xié)作

落地實(shí)踐

未來(lái)展望