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

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

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

滿漢全席

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

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

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

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

包羅萬象的容器

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

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

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

跟著工作流走

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

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

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

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

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

通用容器格式不可能解決管理不同云基礎設施定義而遇到的所有問題，但它肯定會讓各廠商之間，如Azure和AWS之間，或者OpenStack和谷歌云之間的轉移服務變得更加容易。同樣地，利用Puppet或Chef所描述的基礎設施，或者Git庫所管理的基礎設施，我們就可能開發(fā)出一個轉換層，為應用生成通用的虛機和網絡描述，為各個云廠商提供適當的編排功能。

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