虛擬化和容器化是項(xiàng)目云化不可避免的兩個(gè)問(wèn)題。虛擬化由于是純平臺(tái)操作，一個(gè)運(yùn)行于linux操作系統(tǒng)的項(xiàng)目幾乎不需要做任何改造就可以支持虛擬化。而項(xiàng)目如果要支持容器化則需要做許多細(xì)致的改造工作。容器化相對(duì)于虛擬化的優(yōu)勢(shì)也相當(dāng)明顯，運(yùn)行于裸機(jī)性能高，秒級(jí)啟停容器，更不用說(shuō)開(kāi)發(fā)、測(cè)試、布署一致的環(huán)境(DevOps理念)，以及上篇提到的微服務(wù)的能力。大家還可以找到各種文章來(lái)介紹容器化（Docker）的知識(shí)，這里我們就不一一贅述。下面我們會(huì)根據(jù)項(xiàng)目的實(shí)際情況，介紹下容器化改造會(huì)面臨的問(wèn)題和解決方案。

一個(gè)幾十萬(wàn)行c++代碼、大幾十個(gè)應(yīng)用程序的大型項(xiàng)目進(jìn)行容器化。如何對(duì)原來(lái)的代碼改造最小，甚至代碼都不需要修改。如何靜悄悄的，甚至不讓業(yè)務(wù)程序員發(fā)覺(jué)。如何將業(yè)務(wù)鏡像的體積做到最小。如何快速地制作一個(gè)業(yè)務(wù)鏡像。這些一直是困擾我們多時(shí)的問(wèn)題。容器分類的時(shí)候，如果需要對(duì)代碼組織方式和架構(gòu)進(jìn)行調(diào)整，對(duì)于幾十萬(wàn)行的項(xiàng)目將會(huì)是一個(gè)災(zāi)難。容化改造完后，如果開(kāi)發(fā)模式變化太劇烈，無(wú)可避免會(huì)面臨幾十個(gè)、上百個(gè)業(yè)務(wù)程序員重新學(xué)習(xí)適應(yīng)的過(guò)程，成本驚人。業(yè)務(wù)鏡像的大小直接影響對(duì)現(xiàn)場(chǎng)更新容器方便與否的問(wèn)題，特別是當(dāng)項(xiàng)目在海外，網(wǎng)絡(luò)速度不是很快的情況下。自動(dòng)化、快速的鏡像制作是能否進(jìn)行敏捷開(kāi)發(fā)的關(guān)鍵。

一、如何開(kāi)始

如何將一個(gè)運(yùn)行于linux的項(xiàng)目挪到容器里面去運(yùn)行通常是遇到的第一個(gè)問(wèn)題。網(wǎng)上找一個(gè)帶gcc編譯器和linux操作系統(tǒng)的基礎(chǔ)鏡像，基于這個(gè)鏡像可以先制作一個(gè)編譯和CI檢查（代碼檢查、運(yùn)行單元測(cè)試等等）的構(gòu)建鏡像。利用構(gòu)建鏡像進(jìn)行編譯和CI檢查，然后基于基礎(chǔ)鏡像制作運(yùn)行鏡像，將編譯好的庫(kù)和可執(zhí)行程序拷貝進(jìn)去（通過(guò)Dockerfile）。這樣一個(gè)最簡(jiǎn)單鏡像就制作好了。

上面方法做出來(lái)的業(yè)務(wù)鏡像可以運(yùn)行，但有兩個(gè)問(wèn)題，制作的時(shí)間特別長(zhǎng)（我們項(xiàng)目需要一個(gè)小時(shí)）、鏡像的業(yè)務(wù)層特別大（我們項(xiàng)目有1個(gè)G）。兩個(gè)問(wèn)題不是特別嚴(yán)重，但如果項(xiàng)目拿去商用就是一個(gè)很麻煩的問(wèn)題。

二、容器分層

容器分層的概念是Docker的核心概念，就是支持每個(gè)容器可以“繼承”自另外一個(gè)容器。這里的繼承跟面向?qū)ο罄锏睦^承應(yīng)該是同一個(gè)概念。這樣除了可以帶來(lái)“繼承”特性的好處，底層鏡像變動(dòng)時(shí)，不需要去更新上層的鏡像，這樣就可以少更新很多東西。的確很妙，面向?qū)ο蟮睦^承我都沒(méi)覺(jué)得有這么好用！受這個(gè)特性影響，我們將項(xiàng)目用到的第三方庫(kù)單獨(dú)提出來(lái)做成一層。制作的流程也相應(yīng)地變成下圖所示。

雖然過(guò)程多了一步，但效果也是立竿見(jiàn)影的，業(yè)務(wù)層的制作時(shí)間從原來(lái)1個(gè)小時(shí)縮短為12分鐘，大小也變?yōu)?00M左右。

三、業(yè)務(wù)容器分類

在Docker最佳實(shí)踐的建議里面，建議一個(gè)容器最好只跑一種程序，或者一類程序。像原來(lái)那樣，一個(gè)容器跑幾十個(gè)進(jìn)程一定是不合適的。分類清晰的容器也便于管理和進(jìn)行各種操作。同時(shí)，在微服務(wù)的最佳實(shí)踐里面，建議將項(xiàng)目的代碼分割成一個(gè)個(gè)的微服務(wù)。每個(gè)微服務(wù)的代碼由不同的團(tuán)隊(duì)維護(hù)，各自獨(dú)立。我們先暫時(shí)不討論這種方式的優(yōu)缺點(diǎn)。原先的項(xiàng)目是一個(gè)幾十萬(wàn)行、幾十個(gè)程序的大項(xiàng)目，有幾十個(gè)人開(kāi)發(fā)人員，有無(wú)數(shù)的公共模塊，每個(gè)模塊間相互引用也很普遍，每個(gè)程序由數(shù)量不等的模塊來(lái)組成。如果按上面的建議來(lái)進(jìn)行Docker的業(yè)務(wù)分類，無(wú)疑會(huì)給項(xiàng)目帶來(lái)巨變，并且涉及組織架構(gòu)的大調(diào)整，幾乎是一個(gè)不可能的任務(wù)。那么如何做既可以對(duì)容器進(jìn)行分類，又保持原有的開(kāi)發(fā)模式不變。有時(shí)候察覺(jué)不到改變才是推進(jìn)一項(xiàng)新技術(shù)的最佳方式。

方法其實(shí)也很簡(jiǎn)單，容器里面有一個(gè)叫docker-entrypoint.sh的角本，管理容器啟動(dòng)后要啟動(dòng)哪些進(jìn)程。上面我們已經(jīng)制作了一個(gè)項(xiàng)目統(tǒng)一的鏡像，在分類的時(shí)候，我們只要根據(jù)不同類型容器，修改不同的docker-entrypoint.sh來(lái)啟動(dòng)不同類型的進(jìn)程就可以了。要配合設(shè)置不同的環(huán)境變量，不同的配置文件等等。當(dāng)然，這一切都很容易！

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

最新評(píng)論