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

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

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

滿漢全席

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

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

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

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

包羅萬象的容器

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

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

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

跟著工作流走

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

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

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

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

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

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

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