容器將改變一切

一旦將容器納入工作流的構(gòu)建過(guò)程中，那么我們多云的未來(lái)就將會(huì)塵埃落定。

現(xiàn)代應(yīng)用的發(fā)展在很大程度上要?dú)w功于DevOps運(yùn)動(dòng)的蓬勃興起，以及該運(yùn)動(dòng)所產(chǎn)生的各種自動(dòng)化工具。和以往只單純編寫(xiě)代碼不同，開(kāi)發(fā)人員如今需要考慮采用哪些工具，以及如何將這些工具組合起來(lái)，以便將最初的設(shè)想轉(zhuǎn)變成活生生的應(yīng)用。

而容器便是這種新工作流程中最重要的新工具之一。像Docker這樣的新技術(shù)可以讓我們捕捉到關(guān)鍵的服務(wù)，并將它們從底層基礎(chǔ)設(shè)施中抽象出來(lái)。利用這種方法，我們可以重新思考如何部署應(yīng)用，如何更好地發(fā)揮云基礎(chǔ)設(shè)施的作用。

滿漢全席

亞馬遜近日在倫敦舉辦了一場(chǎng)用戶大會(huì)，一位AWS用戶描述了他的團(tuán)隊(duì)處理應(yīng)用更新的過(guò)程。他們不再只是簡(jiǎn)單地推送一段修改后的代碼，而是將“完整的基礎(chǔ)設(shè)施”的構(gòu)建過(guò)程輸出給自己的客戶。

一旦基礎(chǔ)設(shè)施部署并測(cè)試完畢后便可在DNS上做切換，使其成為一個(gè)活的系統(tǒng)。而在其他方面，這種方法還可在運(yùn)營(yíng)新系統(tǒng)的頭幾天中將舊的虛擬基礎(chǔ)設(shè)施作成備份，然后再根據(jù)需要?jiǎng)h除之。

這樣一種輸送完整的基礎(chǔ)設(shè)施的想法最初看起來(lái)似乎很荒唐，但是當(dāng)你要考慮云部署的經(jīng)濟(jì)性時(shí)，這種方法顯然要比推送更新更節(jié)約成本。它意味著你正在部署的是一個(gè)已經(jīng)就緒的狀態(tài)，不僅更新的服務(wù)器和服務(wù)可能已經(jīng)運(yùn)行了一段時(shí)間，而且連操作系統(tǒng)或軟件都已自動(dòng)更新了。

這種辦法無(wú)須投資硬件，對(duì)開(kāi)發(fā)、測(cè)試和生產(chǎn)都使用同樣的云平臺(tái)，需要做的只是為每種環(huán)境分配不同的虛擬網(wǎng)絡(luò)，再加上適當(dāng)?shù)脑L問(wèn)控制即可。你甚至可以在開(kāi)發(fā)中使用生產(chǎn)數(shù)據(jù)，在需要清理數(shù)據(jù)時(shí)簡(jiǎn)單地克隆存儲(chǔ)即可。

包羅萬(wàn)象的容器

將應(yīng)用集裝在Docker中會(huì)更便于從基礎(chǔ)設(shè)施中抽象出關(guān)鍵的應(yīng)用元素。用這種方式處理軟件，也能讓DevOps充分發(fā)揮作用，更易于隨著不斷變化的需求對(duì)服務(wù)加以擴(kuò)展。在容器中包裝一個(gè)Node.js/Seneca微服務(wù)啟用，便可在同一臺(tái)主機(jī)或新的虛機(jī)上快速部署新的實(shí)例。

這種方法產(chǎn)生了一種有趣的DevOps模式，即等冪容器（idempotent container）。這種方法不是把一個(gè)應(yīng)用或服務(wù)當(dāng)成構(gòu)建的終點(diǎn)，而是構(gòu)建一個(gè)包含了應(yīng)用、服務(wù)，以及所有相關(guān)聯(lián)要素的容器。任何時(shí)候只要一做出改變，就可構(gòu)建一個(gè)新的容器。測(cè)試和部署容器時(shí)將其視為一個(gè)整體，而不是其中的任何單獨(dú)元素。這種方法非常有意義，因?yàn)樗苊獬粢话汩_(kāi)發(fā)流程的某些弊病。在傳統(tǒng)的開(kāi)發(fā)模式中，我們很容易走捷徑，只測(cè)試變化部分，而不去考慮整體。

一個(gè)容器一旦構(gòu)建并部署完畢，就不會(huì)發(fā)生變化，除非又有新的容器在部署。由于一個(gè)容器就是一個(gè)沙盒，因此要想與其中的內(nèi)容進(jìn)行交互，就得通過(guò)API或者容器自帶的UI，這使得容器成了微服務(wù)的一個(gè)理想的抽象。該服務(wù)的API是唯一的接觸點(diǎn)，最好是將API定義為各DevOps團(tuán)隊(duì)之間的一份合同。如此一來(lái)，在小型服務(wù)器實(shí)例，如CoreOS或微軟新的Nano Server上運(yùn)行的容器就會(huì)成為一種標(biāo)準(zhǔn)的基礎(chǔ)設(shè)施構(gòu)建模塊。

跟著工作流走

綜上所述，當(dāng)我們看到Jenkins構(gòu)建帶有對(duì)Docker支持的管道工具時(shí)就不會(huì)吃驚了。Jenkins已經(jīng)成了很多構(gòu)建流程的標(biāo)準(zhǔn)構(gòu)建工具，其定制化模塊架構(gòu)使其易于對(duì)特定的工作流進(jìn)行調(diào)諧，易于和源代碼控制工具及開(kāi)發(fā)和測(cè)試平臺(tái)進(jìn)行集成。

作為Cloudbees的CTO和Jenkins項(xiàng)目的創(chuàng)始人，Kohsuke Kawaguchi在一次會(huì)議上說(shuō)，給Jenkins增加對(duì)Docker的支持非常合理：“這樣會(huì)促進(jìn)業(yè)界對(duì)Jenkins的需求，將Docker視為一種可執(zhí)行的打包格式。你可以編譯并打包成一個(gè)二進(jìn)制對(duì)象，然后運(yùn)行，不再需要的時(shí)候直接處理掉就行。”

從Kawaguchi的說(shuō)法中我們顯然可以看出，Docker和其他的容器格式很符合Jenkins的Cloudbees版本，“你可將其用于測(cè)試或用于生產(chǎn)，測(cè)試通不過(guò)的話就重構(gòu)一個(gè)容器。可將代碼編譯成一個(gè)模塊，就像Ruby一樣，然后放進(jìn)容器中，發(fā)送給Puppet用于部署。”

此種做法作為整體DevOps戰(zhàn)略的組成部分是有道理的，其中的一切，從基礎(chǔ)設(shè)施往下都是代碼。正如Kawaguchi所言，一切都是代碼，“而Git和Jenkins就是砸代碼釘子的錘子?！?/p>

雖然Docker的文件格式對(duì)于容器圈來(lái)說(shuō)幾乎已成了通用格式，但我們最好還是要觀察一下Linux基金會(huì)所贊助的一個(gè)通用、開(kāi)放的容器格式的進(jìn)展。這一倡議把很多容器開(kāi)發(fā)人員和廠商（包括微軟等）聚攏到了一起。一旦一種通用格式獲得業(yè)界的廣泛支持，我們便能向多個(gè)云廠商（公有云和私有云）提供容器了。

通用容器格式不可能解決管理不同云基礎(chǔ)設(shè)施定義而遇到的所有問(wèn)題，但它肯定會(huì)讓各廠商之間，如Azure和AWS之間，或者OpenStack和谷歌云之間的轉(zhuǎn)移服務(wù)變得更加容易。同樣地，利用Puppet或Chef所描述的基礎(chǔ)設(shè)施，或者Git庫(kù)所管理的基礎(chǔ)設(shè)施，我們就可能開(kāi)發(fā)出一個(gè)轉(zhuǎn)換層，為應(yīng)用生成通用的虛機(jī)和網(wǎng)絡(luò)描述，為各個(gè)云廠商提供適當(dāng)?shù)木幣殴δ堋?/p>

認(rèn)為一切都不過(guò)是代碼，這種想法并不新鮮，但將其納入DevOps，則有可能使其成為現(xiàn)實(shí)。利用如Docker和Jenkins之類(lèi)的工具一起協(xié)同工作，我們就能看到實(shí)現(xiàn)這一現(xiàn)實(shí)的曙光。